https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com --- Comment #1 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Some libraries would prefer that Koha allow the patron to check out the book even though it is meant to be on hold. I think this needs to be an option. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #3 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- And to clarify this a bit more: waiting items cannot be checked out currently with SIP so this would make both of these checkout methods work the same way. Maybe you are thinking of the Reserved state, i.e. patron has placed a hold but it has not been confirmed by the library yet to be available for pickup? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #5 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- (In reply to Andrew Fuerste-Henry from comment #4)

I believe the thinking is that whenever possible the book should go to the patron who has it in-hand. I'm sure the patron who previously got a notice that their hold is available *is* angry when their item isn't there for them, but nonetheless I have known real libraries that do this. I'm not arguing that it's a good idea, just that it's something I've known libraries to do.

Would you be able to check with these libraries if they could just disable the holds completely because there doesn't seem to be any use of placing a hold in that case? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Didier Gautheron <didier.gautheron@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eveal@mckinneytexas.org --- Comment #7 from Didier Gautheron <didier.gautheron@biblibre.com> --- *** Bug 25703 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=7090 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 sbarter@aacpl.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbarter@aacpl.net -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #10 from sbarter@aacpl.net --- I was a bit confused after reading this the first time, so I will clarify. Yes, check outs should be blocked when they are in Waiting or Transit status. The issue is that Koha also blocks checkouts for holds/reserves that have not been found. If reserves.found is NULL the checkout should not be blocked. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #11 from Christopher Brannon <cbrannon@cdalibrary.org> --- I wonder if two things need to be addressed on this topic. I think it is ridiculous to allow just anyone to grab an item off a hold shelf and check it out when the person it is on hold for has been notified. That said: 1) There should be an option in settings to prevent this. If a library decides to just blanket allow this, then they can. 2) There should be a proxy setting for SCO. If a patron plans to have a proxy, the card number of that proxy should be listed in their account. When the proxy checks out the item that is on hold for someone else, it will confirm that they are checking out on behalf of the person it is on hold for, and the item is checked out on the holder's account, with a note that it was checked out by that proxy. This would also put in some ground work for functionality behind practices that libraries already do. Many libraries note that certain people can pick up holds for them. But it is just a note in their account. This would give this practice a little more teeth. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blawlor@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Patch complexity|--- |Medium patch -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #14 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197809 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197809&action=edit Bug 23909: Block waiting holds at SCO checkout AllowItemsOnHoldCheckoutSCO was previously passed through to CanBookBeIssued as the ignore_reserves flag, which skipped the entire holds branch in C4::Circulation and silently allowed checkout of items already waiting on the hold shelf (reserves.found = 'W') or in transit/processing for another patron's hold. With the pref now a 3-value Choice: 0 = don't allow checkout of any held items 1 = allow checkout of items with a pending hold only 2 = allow checkout of items with any hold state sco-main.pl now always calls CanBookBeIssued with ignore_reserves=0 and filters the needsconfirmation keys according to the pref value, mirroring the pattern SIP already uses. RESERVE_WAITING, TRANSFERRED and PROCESSING are added to the error-matching list and to the SCO template so patrons see a specific "on the hold shelf" / "in transit" / "being processed" message instead of falling through to the generic "please see a member of the library staff" line. Test plan: - Enable WebBasedSelfCheck; log in to /cgi-bin/koha/sco/sco-main.pl. - Create an item with a pending hold for another patron (reserves.found IS NULL). - With AllowItemsOnHoldCheckoutSCO = 0, scan the barcode: checkout is refused with "This item is on hold for another patron". - Switch to 1 ("Allow pending holds only"): checkout succeeds. - Set the hold to waiting (reserves.found = 'W') and try again with the pref still at 1: checkout is refused with "This item is waiting on the hold shelf for another patron". - Switch to 2 ("Allow pending and waiting holds"): checkout succeeds. - Repeat with found = 'T' and 'P' at pref = 1 -> refused with the appropriate transit/processing message; at pref = 2 -> allowed. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #16 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197811 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197811&action=edit Bug 23909: Apply hold policy to OPAC REST self-checkout The OPAC REST self-checkout path (guarded by OpacTrustedCheckout) is functionally SCO-over-API, so it should honour the same hold policy as the SCO web interface. Previously _check_availability unconditionally promoted RESERVED, RESERVE_WAITING, TRANSFERRED and PROCESSING from the confirmation hash to the blockers hash for any public caller. This meant the OPAC REST endpoint always refused held items regardless of the librarian's AllowItemsOnHoldCheckoutSCO configuration. With this patch the promotion is gated on AllowItemsOnHoldCheckoutSCO: * 0 - Promote all four hold confirmations to blockers (previous behaviour for pending holds) * 1 - Promote only waiting/transit/processing; silently allow checkout of items with a pending hold * 2 - Promote none; silently allow checkout of items with any hold Remaining hold confirmations are stripped from the response so the caller does not have to resolve a confirmation token for a policy the admin has already granted. Test plan: 1. prove t/db_dependent/api/v1/checkouts.t 2. Enable OpacTrustedCheckout. POST an item with a pending hold for another patron to /api/v1/public/patrons/X/checkouts: - AllowItemsOnHoldCheckoutSCO=0: 403 Checkout not authorized - AllowItemsOnHoldCheckoutSCO=1: 201 Created 3. Place a waiting hold for another patron on an item. Repeat: - AllowItemsOnHoldCheckoutSCO=1: 403 - AllowItemsOnHoldCheckoutSCO=2: 201 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #18 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- The web-based self-check blocked checkout of both pending and waiting holds regardless of how I set AllowItemsOnHoldCheckoutSCO, though the error message given changed. With the syspref set to "Don't allow" I got the message: This item is waiting on the hold shelf for another patron. Please see a member of the library staff. With the syspref set to either "Allow pending holds only" I continued to get this longer error message for waiting holds but for pending holds I received just "Please see a member of the library staff." With the syspref set to "Allow pending and waiting holds" I got the shorter message for both hold types. Using the self-check via OPAC method enabled by OPACTrustedCheckout, pending holds checked out successfully when enabled via AllowItemsOnHoldCheckoutSCO but when waiting holds were also allowed via syspref I received an odd message when trying to check one out: "Message code 'reswaitingdate' with data '2026-04-20'" The SIP options all worked as described. With AllowHoldCheckoutOverride set to Allow, I was able to allow either type of held item to be checked out while logged in as a superlibrarian or as a user with force_checkout permission. With only basic circ permissions, I was not able to check out either type of held item. This is as expected and desired. With AllowHoldCheckoutOverride set to Don't Allow, I was not able to check out either type of held item regardless of user permissions. This is as expected and desired but the message I received was clearly missing intended values, either "Item () has been waiting for () at since ." or "Item () is on hold for () at since ." -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197808|0 |1 is obsolete| | Attachment #197809|0 |1 is obsolete| | Attachment #197810|0 |1 is obsolete| | Attachment #197811|0 |1 is obsolete| | Attachment #197812|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #20 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197839 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197839&action=edit Bug 23909: Block waiting holds at SCO checkout AllowItemsOnHoldCheckoutSCO was previously passed through to CanBookBeIssued as the ignore_reserves flag, which skipped the entire holds branch in C4::Circulation and silently allowed checkout of items already waiting on the hold shelf (reserves.found = 'W') or in transit/processing for another patron's hold. With the pref now a 3-value Choice: 0 = don't allow checkout of any held items 1 = allow checkout of items with a pending hold only 2 = allow checkout of items with any hold state sco-main.pl now always calls CanBookBeIssued with ignore_reserves=0 and filters the needsconfirmation keys according to the pref value, mirroring the pattern SIP already uses. RESERVE_WAITING, TRANSFERRED and PROCESSING are added to the error-matching list and to the SCO template so patrons see a specific "on the hold shelf" / "in transit" / "being processed" message instead of falling through to the generic "please see a member of the library staff" line. Test plan: - Enable WebBasedSelfCheck; log in to /cgi-bin/koha/sco/sco-main.pl. - Create an item with a pending hold for another patron (reserves.found IS NULL). - With AllowItemsOnHoldCheckoutSCO = 0, scan the barcode: checkout is refused with "This item is on hold for another patron". - Switch to 1 ("Allow pending holds only"): checkout succeeds. - Set the hold to waiting (reserves.found = 'W') and try again with the pref still at 1: checkout is refused with "This item is waiting on the hold shelf for another patron". - Switch to 2 ("Allow pending and waiting holds"): checkout succeeds. - Repeat with found = 'T' and 'P' at pref = 1 -> refused with the appropriate transit/processing message; at pref = 2 -> allowed. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #22 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197841 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197841&action=edit Bug 23909: Apply hold policy to OPAC REST self-checkout The OPAC REST self-checkout path (guarded by OpacTrustedCheckout) is functionally SCO-over-API, so it should honour the same hold policy as the SCO web interface. Previously _check_availability unconditionally promoted RESERVED, RESERVE_WAITING, TRANSFERRED and PROCESSING from the confirmation hash to the blockers hash for any public caller. This meant the OPAC REST endpoint always refused held items regardless of the librarian's AllowItemsOnHoldCheckoutSCO configuration. With this patch the promotion is gated on AllowItemsOnHoldCheckoutSCO: * 0 - Promote all four hold confirmations to blockers (previous behaviour for pending holds) * 1 - Promote only waiting/transit/processing; silently allow checkout of items with a pending hold * 2 - Promote none; silently allow checkout of items with any hold Remaining hold confirmations are stripped from the response so the caller does not have to resolve a confirmation token for a policy the admin has already granted. Test plan: 1. prove t/db_dependent/api/v1/checkouts.t 2. Enable OpacTrustedCheckout. POST an item with a pending hold for another patron to /api/v1/public/patrons/X/checkouts: - AllowItemsOnHoldCheckoutSCO=0: 403 Checkout not authorized - AllowItemsOnHoldCheckoutSCO=1: 201 Created 3. Place a waiting hold for another patron on an item. Repeat: - AllowItemsOnHoldCheckoutSCO=1: 403 - AllowItemsOnHoldCheckoutSCO=2: 201 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #24 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- (In reply to Andrew Fuerste-Henry from comment #18)

The web-based self-check blocked checkout of both pending and waiting holds regardless of how I set AllowItemsOnHoldCheckoutSCO, though the error message given changed.

Fixed inline, I missed a step of cleaning out the older needsconfirm attributes when I was promoting them to optional blockers.

Using the self-check via OPAC method enabled by OPACTrustedCheckout, pending holds checked out successfully when enabled via AllowItemsOnHoldCheckoutSCO but when waiting holds were also allowed via syspref I received an odd message when trying to check one out: "Message code 'reswaitingdate' with data '2026-04-20'"

Also fixed inline, some new keys were introduced at some point in AddReturn, but the REST controller hadn't been updated to compensate. Tomas and I are working together to bring this stuff together into one place and DRY out the code in a parallel bug.

The SIP options all worked as described.

Awesome :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #25 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- The atomic update here preserves the value in both AllowItemsOnHoldCheckoutSCO and AllowItemsOnHoldCheckoutSIP, but for AllowItemsOnHoldCheckoutSCO that means a change in behavior. At upgrade, if AllowItemsOnHoldCheckoutSCO was set to Allow (1) the update should change it to Allow pending and waiting holds (2). For AllowItemsOnHoldCheckoutSIP, leaving the value set to 1 maintains the current behavior so no change need be made to the value. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #27 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197921 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197921&action=edit Bug 23909: Preserve SCO behavior on upgrade (value 1 -> 2) The atomicupdate converts AllowItemsOnHoldCheckoutSCO and AllowItemsOnHoldCheckoutSIP from YesNo to Choice (0|1|2), where value 1 now means "Allow pending holds only" and value 2 means "Allow pending and waiting holds". For AllowItemsOnHoldCheckoutSCO, pre-upgrade value 1 meant "allow all on-hold checkouts (pending AND waiting)" at SCO. Post-upgrade, sco-main.pl reads value 1 as "pending only", silently downgrading sites that previously allowed waiting-hold checkouts. Remap SCO value 1 -> 2 at upgrade time to preserve prior behavior. For AllowItemsOnHoldCheckoutSIP, the SIP checkout code was already gated on >= 1 for pending and >= 2 for waiting, so value 1 meant "pending only" in practice even under the old YesNo type. No value migration is needed -- leaving it at 1 preserves current behavior. The value remap lives inside the branch that only runs when the type is not already Choice, so re-running the atomicupdate is safe and will not double-remap. Test plan: 1) On a pre-upgrade DB, set both prefs to YesNo/1: UPDATE systempreferences SET type='YesNo', options=NULL, value='1' WHERE variable IN ('AllowItemsOnHoldCheckoutSCO', 'AllowItemsOnHoldCheckoutSIP'); 2) Run installer/data/mysql/updatedatabase.pl. 3) Verify: SELECT variable, type, options, value FROM systempreferences WHERE variable IN ('AllowItemsOnHoldCheckoutSCO', 'AllowItemsOnHoldCheckoutSIP'); SCO -> type=Choice, options=0|1|2, value=2. SIP -> type=Choice, options=0|1|2, value=1. 4) Re-run updatedatabase.pl; confirm both prefs report "already migrated, skipping" and values are unchanged. 5) Spot-check other starting values: SCO=0 stays 0, SCO=2 stays 2, SIP=0 stays 0. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197838|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197840|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197842|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #28 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 197932 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197932&action=edit Bug 23909: Add syspref values and atomicupdate AllowItemsOnHoldCheckoutSCO and AllowItemsOnHoldCheckoutSIP become Choice (0|1|2) so libraries can distinguish pending from waiting holds: 0 = Don't allow (unchanged) 1 = Allow pending holds only (new semantics; previously "Allow") 2 = Allow pending and waiting holds (preserves old permissive behaviour) A new AllowHoldCheckoutOverride YesNo preference (default 1) follows the existing Allow*Override family and lets libraries block the "check out anyway" override in the staff interface when an item is on hold for another patron. Note: installations that previously had either Allow*CheckoutSCO/SIP set to 1 will migrate to "Allow pending only". Libraries that relied on the previous behaviour (silently allowing checkout of items already waiting on the hold shelf) need to manually switch to 2. Test plan: - Apply the patch and restart Koha. - Run the web installer / updatedatabase.pl. - Confirm no errors and the log mentions the three sysprefs. - Run it a second time; confirm the "already migrated" / "already exists" skip messages appear. - In Administration > System preferences, search for AllowItemsOnHoldCheckoutSCO and AllowItemsOnHoldCheckoutSIP and confirm the dropdown now has three options. - Confirm AllowHoldCheckoutOverride appears in the same section with the Allow/Don't allow choices and defaults to Allow. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #30 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 197934 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197934&action=edit Bug 23909: Extend SIP to distinguish pending vs waiting holds This patch extends the SIP checkout handler to honour the new three-valued AllowItemsOnHoldCheckoutSIP preference: * 0 - Don't allow checkout of any held item * 1 - Allow checkout when the hold is still pending (not attached) * 2 - Also allow checkout when the hold is waiting, in transit or being processed for another patron Previously the preference was a simple YesNo toggle that, when enabled, allowed the checkout regardless of whether the hold was pending or already attached to an item on the hold shelf. Libraries could not block the more disruptive case (checking out a waiting hold destined for another patron) without also blocking pending holds. The existing post-confirmation filter is reworked into a single branch per confirmation type that consults the preference value. Test plan: 1. prove t/db_dependent/SIP/Transaction.t 2. With AllowItemsOnHoldCheckoutSIP=0, place a pending hold for patron A on an item, attempt SIP checkout to patron B: refused. 3. Repeat with the hold marked waiting: refused. 4. Set AllowItemsOnHoldCheckoutSIP=1, pending hold: allowed; waiting hold: refused. 5. Set AllowItemsOnHoldCheckoutSIP=2, waiting hold: allowed. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #32 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 197936 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197936&action=edit Bug 23909: Add AllowHoldCheckoutOverride for staff circulation Introduce a new AllowHoldCheckoutOverride system preference (default 1 to preserve existing behaviour) that lets libraries prevent staff from overriding held-item blockers at the circulation desk. When AllowHoldCheckoutOverride is set to 0, CanBookBeIssued still returns the hold-related keys (RESERVED, RESERVE_WAITING, TRANSFERRED and PROCESSING) in the confirmation hash, but circ/circulation.pl promotes them to the impossible hash before rendering the template. This means no override button appears, and checkout of the held item is refused outright with a clear message explaining which patron the hold is for. Matching entries have been added to the IMPOSSIBLE block of the circulation template so the blocked-checkout message is meaningful. This sits alongside the existing Allow*Override family (AllowTooManyOverride, AllowNotForLoanOverride, AllowHoldPolicyOverride and AllowRenewalOnHoldOverride) and uses the same staff-only semantics. Test plan: 1. Set AllowHoldCheckoutOverride=1 (default). Place a waiting hold for patron A on an item. At /cgi-bin/koha/circ/circulation.pl attempt to check the item out to patron B: a confirmation dialog appears with "Check out anyway" override buttons. 2. Set AllowHoldCheckoutOverride=0. Repeat: checkout is refused with a message stating the item has been waiting for patron A. No override button is offered. 3. Repeat with pending holds (reserves.found IS NULL), items in transit and items being processed: each is refused when the preference is 0 and offered as an overridable confirmation when the preference is 1. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |andrew@bywatersolutions.com |y.org | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197932|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197934|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197936|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #34 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 197938 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197938&action=edit Bug 23909: Add syspref values and atomicupdate AllowItemsOnHoldCheckoutSCO and AllowItemsOnHoldCheckoutSIP become Choice (0|1|2) so libraries can distinguish pending from waiting holds: 0 = Don't allow (unchanged) 1 = Allow pending holds only (new semantics; previously "Allow") 2 = Allow pending and waiting holds (preserves old permissive behaviour) A new AllowHoldCheckoutOverride YesNo preference (default 1) follows the existing Allow*Override family and lets libraries block the "check out anyway" override in the staff interface when an item is on hold for another patron. Note: installations that previously had either Allow*CheckoutSCO/SIP set to 1 will migrate to "Allow pending only". Libraries that relied on the previous behaviour (silently allowing checkout of items already waiting on the hold shelf) need to manually switch to 2. Test plan: - Apply the patch and restart Koha. - Run the web installer / updatedatabase.pl. - Confirm no errors and the log mentions the three sysprefs. - Run it a second time; confirm the "already migrated" / "already exists" skip messages appear. - In Administration > System preferences, search for AllowItemsOnHoldCheckoutSCO and AllowItemsOnHoldCheckoutSIP and confirm the dropdown now has three options. - Confirm AllowHoldCheckoutOverride appears in the same section with the Allow/Don't allow choices and defaults to Allow. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #36 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 197940 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197940&action=edit Bug 23909: Extend SIP to distinguish pending vs waiting holds This patch extends the SIP checkout handler to honour the new three-valued AllowItemsOnHoldCheckoutSIP preference: * 0 - Don't allow checkout of any held item * 1 - Allow checkout when the hold is still pending (not attached) * 2 - Also allow checkout when the hold is waiting, in transit or being processed for another patron Previously the preference was a simple YesNo toggle that, when enabled, allowed the checkout regardless of whether the hold was pending or already attached to an item on the hold shelf. Libraries could not block the more disruptive case (checking out a waiting hold destined for another patron) without also blocking pending holds. The existing post-confirmation filter is reworked into a single branch per confirmation type that consults the preference value. Test plan: 1. prove t/db_dependent/SIP/Transaction.t 2. With AllowItemsOnHoldCheckoutSIP=0, place a pending hold for patron A on an item, attempt SIP checkout to patron B: refused. 3. Repeat with the hold marked waiting: refused. 4. Set AllowItemsOnHoldCheckoutSIP=1, pending hold: allowed; waiting hold: refused. 5. Set AllowItemsOnHoldCheckoutSIP=2, waiting hold: allowed. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #38 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 197942 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197942&action=edit Bug 23909: Add AllowHoldCheckoutOverride for staff circulation Introduce a new AllowHoldCheckoutOverride system preference (default 1 to preserve existing behaviour) that lets libraries prevent staff from overriding held-item blockers at the circulation desk. When AllowHoldCheckoutOverride is set to 0, CanBookBeIssued still returns the hold-related keys (RESERVED, RESERVE_WAITING, TRANSFERRED and PROCESSING) in the confirmation hash, but circ/circulation.pl promotes them to the impossible hash before rendering the template. This means no override button appears, and checkout of the held item is refused outright with a clear message explaining which patron the hold is for. Matching entries have been added to the IMPOSSIBLE block of the circulation template so the blocked-checkout message is meaningful. This sits alongside the existing Allow*Override family (AllowTooManyOverride, AllowNotForLoanOverride, AllowHoldPolicyOverride and AllowRenewalOnHoldOverride) and uses the same staff-only semantics. Test plan: 1. Set AllowHoldCheckoutOverride=1 (default). Place a waiting hold for patron A on an item. At /cgi-bin/koha/circ/circulation.pl attempt to check the item out to patron B: a confirmation dialog appears with "Check out anyway" override buttons. 2. Set AllowHoldCheckoutOverride=0. Repeat: checkout is refused with a message stating the item has been waiting for patron A. No override button is offered. 3. Repeat with pending holds (reserves.found IS NULL), items in transit and items being processed: each is refused when the preference is 0 and offered as an overridable confirmation when the preference is 1. Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |26.05.00 released in| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This enhancement extends release notes| |the options in the system | |preferences | |AllowItemsOnHoldCheckoutSCO | |and | |AllowItemsOnHoldCheckoutSIP | |. When a patron attempts | |via the web-based | |self-checkout or SIP to | |check out an item on which | |another patron has a hold, | |libraries now have the | |option to block all | |checkouts, allow the | |checkout if the hold is | |pending, or allow the | |checkout if the hold is | |pending or waiting. The new | |system preference | |AllowHoldCheckoutOverride | |governs whether or not | |staff with sufficient | |permissions should be able | |to check out on-hold items | |to other patrons via the | |staff client. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 --- Comment #42 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- *** Bug 21572 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.