The syspref text says "[Allow/Don't allow] checkouts of items reserved to someone else via SIP checkout messages. If allowed do not generate RESERVE_WAITING and RESERVED warning. This allows self checkouts for those items. If using the holds queue items with pending holds will be marked as "unavailable" if this set to "Don't allow"." However, setting the syspref to Allow *only* allows sets sip to ignore the RESERVED warning. Items that are currently waiting for hold pickup will still generate a RESERVE_WAITING message and block the checkout. Either the description or the behavior needs to change to make this accurate. In contrast, AllowItemsOnHoldCheckoutSCO also says "If allowed do not generate RESERVE_WAITING and RESERVED warning" and, for the SCO, this is accurate. With AllowItemsOnHoldCheckoutSCO set to allow, items waiting for another patron's hold can be checked out without a warning at the SCO.
To test: 1 - place a hold on Item1 for PatronA, check it in to set the hold to waiting 2 - place a hold on Item2 for PatronA, do not check it in so the hold stays at pending 3 - confirm AllowItemsOnHoldCheckoutSIP is set to Don't allow 4 - attempt to check Item1 out to PatronB via SIP, get an error that the item is on hold for another patron 5 - attempt to check Item2 out to PatronB via SIP, get an error that the item is on hold for another patron 6 - set AllowItemsOnHoldCheckoutSIP to Allow 7 - attempt to check Item1 out to PatronB via SIP again, still get an error that the item is on hold for another patron 8 - attempt to check Item2 out to PatronB via SIP, success!
What version of Koha did you test this on? If not master, can you make sure master exhibits the same behavior? Thanks!
I tested on master and then made Nick look at the code around it, in which he reports it only prevents RESERVE warnings.
The syspref is working as we were looking for, so if you do change this, please leave this functionality as an alternate option for it. I cannot imagine the use case for Patron B to be able to walk up to the self-serve Hold Shelf, take an item held for Patron A, and check it out at a self checkout station without staff intervention/approval. Is that truly the intent of this? If Patron B finds an item on the regular shelf that is on the Holds Queue report for Patron A but staff have not gone out and pulled it yet, then it's "finders keepers" and we want Patron B to be able to check it out. But once an item is trapped and on the Hold Shelf for patron A (and Patron A has been notified to come get it), we don't want anyone other than Patron A to be able to check it out without staff approval.
Looks like it has been caused by commit 338ba1d7692c1f75af7b0fb75eb5aac00a04a3df Bug 25690: Remove duplicated logic in SIP2 checkouts
Hi, the behaviour has been always to prevent waiting holds being checked out via SIP2, the syspref text has been inaccurate. I can send patch.
Created attachment 118366 [details] [review] Bug 27936: Clarify AllowItemsOnHoldCheckoutSIP syspref help text The waiting reserves have always been impossible to checkout via SIP2. There was some confusion whether this is actually true but if you check the commit "Bug 25690: Remove duplicated logic in SIP2 checkouts" (fc1848746da) and the removed code around line $self->screen_msg("Item is on hold for another patron."); you will be sure that it has been impossible to checkout waiting holds.
Regarding the AllowItemsOnHoldCheckoutSCO behaviour being different see https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21572#c3
Created attachment 118367 [details] [review] Bug 27936: Clarify AllowItemsOnHoldCheckoutSIP syspref help text The waiting reserves have always been impossible to checkout via SIP2. There was some confusion whether this is actually true but if you check the commit "Bug 25690: Remove duplicated logic in SIP2 checkouts" (338ba1d769) and the removed code around line $self->screen_msg("Item is on hold for another patron."); you will be sure that it has been impossible to checkout waiting holds.
Created attachment 118455 [details] [review] Bug 27936: Clarify AllowItemsOnHoldCheckoutSIP syspref help text The waiting reserves have always been impossible to checkout via SIP2. There was some confusion whether this is actually true but if you check the commit "Bug 25690: Remove duplicated logic in SIP2 checkouts" (338ba1d769) and the removed code around line $self->screen_msg("Item is on hold for another patron."); you will be sure that it has been impossible to checkout waiting holds.
The syspref description was also in sysprefs.sql which I missed in the earlier revision of the patch. Attached now a new version with the text there also corrected. Ready for Sign-Off.
Created attachment 118458 [details] [review] Bug 27936: Clarify AllowItemsOnHoldCheckoutSIP syspref help text The waiting reserves have always been impossible to checkout via SIP2. There was some confusion whether this is actually true but if you check the commit "Bug 25690: Remove duplicated logic in SIP2 checkouts" (338ba1d769) and the removed code around line $self->screen_msg("Item is on hold for another patron."); you will be sure that it has been impossible to checkout waiting holds. Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Created attachment 118808 [details] [review] Bug 27936: Clarify AllowItemsOnHoldCheckoutSIP syspref help text The waiting reserves have always been impossible to checkout via SIP2. There was some confusion whether this is actually true but if you check the commit "Bug 25690: Remove duplicated logic in SIP2 checkouts" (338ba1d769) and the removed code around line $self->screen_msg("Item is on hold for another patron."); you will be sure that it has been impossible to checkout waiting holds. Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Improved wording.. Passing QA
Pushed to master for 21.05, thanks to everybody involved!
Pushed to 20.11.x for 20.11.05
Pushed to 20.05.x for 20.05.11
Not backported to oldoldstable (19.11.x). Feel free to ask if it's needed.