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.