https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 Kristi Krueger <kkrueger@cuyahogalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kkrueger@cuyahogalibrary.or | |g -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 Andrii Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41282, | |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42945 Assignee|koha-bugs@lists.koha-commun |nugged@gmail.com |ity.org | -- 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=41809 Andrii Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 --- Comment #3 from Andrii Nugged <nugged@gmail.com> --- (In reply to Kristi Krueger from comment #2)

I went through the test plan, and the results are expected according to the test plan.

It seems like the hold on item A is not fulfilled when item B is checked out. That would look confusing with the "Fill other record level holds on record at checkout" setting is marked Yes.

How do others besides me watching this issue feel?

Thank you for testing the patch and raising this question. After reviewing the complete workflow, we think the use case contains two separate events that the current Koha data model treats as one: 1. A patron places a record-level hold. 2. Item A is captured for the hold, moved to the pickup shelf, and the hold becomes Waiting. 3. Before collecting item A, the patron checks out another item from the same record, item B. Before the patch, when “Fill other record level holds on record at checkout” is enabled: 4. Checking out item B fulfills the hold. 5. The hold is moved to the hold history as Fulfilled and linked to item B. 6. Koha therefore loses the actionable connection to item A. 7. Item A remains physically on the pickup shelf, but it no longer appears among waiting holds or cancellation requests. Staff receive no task telling them to remove it. The current patch changes steps 4–7: 4. If the hold is already Waiting on item A, checking out item B does not fulfill it. 5. The hold remains linked to item A and receives a cancellation request. 6. Staff can see the request and remove item A from the pickup shelf. 7. After staff process the request, the hold is recorded as Cancelled rather than Fulfilled by item B. This fixes the operational problem: item A no longer disappears from the staff workflow. However, it also changes the final meaning of the hold. We see two possible directions: Option 1 — cancellation workflow, as implemented by the current patch - Item B is checked out but does not fulfill the waiting hold. - The hold remains linked to item A with a cancellation request. - Staff remove item A, and the hold is eventually recorded as Cancelled. Option 2 — fulfillment plus a separate pickup-shelf cleanup task - Item B fulfills the hold, and the hold is recorded as Fulfilled. - A separate persistent staff task remains attached to item A until it is removed from the pickup shelf. - This requires additional development because the current cancellation request belongs to the active hold and cannot survive independently after the hold is fulfilled. Both options avoid the original broken state, where the hold is fulfilled but item A remains on the pickup shelf without any staff action. We would especially appreciate feedback from librarians: 1. When item B is checked out, should the hold be recorded as Fulfilled or Cancelled? 2. Is it acceptable for the current cancellation workflow to result in a Cancelled hold history? 3. Should Koha always use one of these outcomes, or do different libraries need a circulation-rule option to choose between them? 4. If the hold is fulfilled by item B, where should the remaining task to remove item A be presented to staff: the existing cancellation-requests report or a separate pickup-shelf cleanup queue? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 Andrii Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #204547|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=41809 --- Comment #6 from Andrii Nugged <nugged@gmail.com> --- Created attachment 204738 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204738&action=edit Bug 41809: Preserve waiting hold on other-item checkout When a patron checks out another item from a record with a waiting title-level hold, MoveReserve fills the hold using the checked-out item. This moves the hold to history and detaches the pickup-shelf item, leaving staff without an action to remove it. For a waiting hold, add a cancellation request instead. The hold remains linked to the pickup-shelf item and therefore remains unavailable until staff processes the request. Keep the existing fill behavior for non-waiting title-level holds. Delete cancellation requests in both terminal paths, cancel and fill, before moving the active hold to history. Both cleanups run inside the existing transactions. This covers staff and batch cancellation and the case where a patron later checks out the pickup-shelf item itself. Requests belonging to other holds remain untouched, and a failed fill rolls its cleanup back. The previous waiting-hold assertion was ineffective because it created an item-level hold on another item. Replace it with a captured title-level hold and exercise the real AddIssue path. The regression coverage also verifies availability, HoldsQueue eligibility, sequential idempotence, terminal cleanup, cleanup isolation and rollback, the non-waiting behavior, the disabled rule, item-level and other-patron holds, and multiple-request cleanup. Test plan: Before applying the patch: 1. In Administration > Circulation and fine rules, set "Fill other holds on record" to "Yes" for an item type. 2. Create a record with two available items of that item type. 3. Place a record-level hold for a patron. 4. Open Circulation > Check in, check in item A, and confirm the hold so it becomes Waiting. 5. Open the checkout page for the same patron and check out item B. 6. Confirm the checkout succeeds and names item B. 7. Confirm the waiting hold on item A is no longer shown for the patron. 8. Open Circulation > Holds awaiting pickup. 9. Confirm item A is not under "Holds with cancellation requests". Apply the patch. After applying the patch: 1. Create a fresh record with two available items of the same item type. 2. Place a record-level hold for a patron. 3. Open Circulation > Check in, check in item A, and confirm the hold so it becomes Waiting. 4. Open the checkout page for the same patron and check out item B. 5. Confirm the checkout succeeds and names item B. 6. Confirm the hold remains Waiting and linked to item A. 7. Open Circulation > Holds awaiting pickup. 8. Confirm item A appears once under "Holds with cancellation requests". 9. Confirm item A is not shown as available. 10. Cancel the hold from the report or check in item A. 11. Confirm the request disappears and the hold is Cancelled in history. 12. Repeat steps 1-9 with fresh data, then check out item A to the patron. 13. Confirm the hold is Filled by item A and its request disappears. 14. Place a non-waiting record-level hold, check out another item from that record to the patron, and confirm the hold is filled as before. Automated tests: 1. prove t/db_dependent/Reserves.t 2. prove t/db_dependent/Koha/Hold.t 3. prove t/db_dependent/Koha/Holds.t 4. prove t/db_dependent/SIP/Transaction.t 5. prove t/db_dependent/HoldsQueue.t Co-Authored-By: Loontik <loontik@nugged.team> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 Andrii Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=6921, | |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38650, | |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=22456, | |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=36024, | |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=39820 --- Comment #7 from Andrii Nugged <nugged@gmail.com> --- Thanks for the testing and for the concern raised in comment 2. After a deeper regression and lifecycle review, I am withdrawing the schema-based approach in attachment 204589. It introduced a second source of truth for item availability and would have required every HoldsQueue, holdability, discovery/indexing, staff, SIP, and cleanup path to understand the new state. The current patch did not meet that bar safely. The replacement patch returns to Koha's existing waiting-hold cancellation workflow: 1. Item A is Waiting on the pickup shelf for a record-level hold. 2. The same patron checks out item B from the same record. 3. The checkout of B succeeds. 4. The hold remains Waiting and linked to A, so A remains unavailable and cannot be allocated to another hold. 5. Koha adds one cancellation request, and staff see A under Holds with cancellation requests. 6. When staff cancel the hold from that workflow or check in A, the hold moves to Cancelled history and all of its cancellation-request rows are removed. 7. If the patron instead later checks out item A itself, the hold is Filled by A and all of its cancellation-request rows are removed. Non-waiting record-level holds continue to be filled at checkout as before. Item-level holds, another patron's holds, and the disabled circulation-rule case are unchanged. This deliberately chooses Cancelled history rather than recording the hold as Fulfilled by B. That is the semantic trade-off identified in comments 2 and 3. It avoids creating a separate, partially integrated inventory state while preserving the physical truth that A is still on the pickup shelf and needs staff action. In direct response to comment 2: yes, while the hold is already Waiting, item B does not fulfill it. The "Fill other record level holds on record at checkout" rule continues to fill non-waiting holds, but a Waiting hold now follows the existing cancellation-request workflow because it also represents item A's physical pickup-shelf state. Automated A/B testing used the same regression assertions on unpatched and patched current main: the waiting-hold assertions fail before and pass after. The patched code passed Reserves.t, Koha/Hold.t, Koha/Holds.t, SIP/Transaction.t, and HoldsQueue.t (202 tests), and the exact final commit passes QohA. A real staff-interface A/B run matched the automated result: before the patch, checkout of B removed the Waiting entry and left no cancellation task; after the patch, A remained in Holds waiting and appeared exactly once under Holds with cancellation requests. Cancelling it there moved the hold to Cancelled history and removed the request row. A non-waiting control still filled normally. Please pay particular attention during sign-off to whether the short period in which the hold remains active and Waiting is acceptable for patron-facing discovery, hold limits, reminders, and expiry behavior until staff process the queue. If libraries require Fulfilled history instead, that would justify a separately designed staff-task entity integrated into all availability paths, not the withdrawn nullable-column shortcut. The replacement also links the existing workflow and its closest edge cases: Bug 22456 introduced patron cancellation of waiting holds; Bug 39820 defines the corresponding SIP check-in behavior; and Bug 36024 tracks concurrent duplicate cancellation requests. This patch prevents sequential duplicates, but does not claim to solve the concurrent-creation bug. The historical Bug 6921 and the related title/item-level behavior in Bug 38650 are also added to See Also. Bugs 41282 and 42945 remain linked for the alert/status discussion. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 Benjamin Daeuber <bdaeuber@cityoffargo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bdaeuber@cityoffargo.com --- Comment #8 from Benjamin Daeuber <bdaeuber@cityoffargo.com> --- If I follow the test plan through to cancelling the hold, everything looks OK to me. The item is both checked out and on hold for the patron. Cancelling the hold makes it available again and removes the hold from the patron's pending hold. The patron's hold limits still seemed to be enforced (though I'd want to check that through again). However, if I then look at the patron's holds history, I get an error: Something went wrong when loading the table. 400: Bad Request. If I uncheck "Cancelled" under Past Holds, the error goes away, but it appears something involving loading that table is still unresolved. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA CC| |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=41809 --- Comment #10 from Benjamin Daeuber <bdaeuber@cityoffargo.com> --- (In reply to Andrew Fuerste-Henry from comment #9)

This change will disrupt libraries' reporting of how many holds they fill over time. The patron's hold is moved to the old_reserves table with found='W', giving the impression that the hold was cancelled without the patron ever receiving an item. But in fact this hold was fulfilled, just not with the waiting item.

I really don't know if it was fulfilled. The title was checked out, yes, but not through the holds process. That hold still needed to be handled by a staff person a second time, for one. I'm asking around here, but I tend to lean towards this hold being cancelled, not filled. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 --- Comment #12 from Benjamin Daeuber <bdaeuber@cityoffargo.com> --- (In reply to Andrew Fuerste-Henry from comment #11)

(In reply to Benjamin Daeuber from comment #10)

...

(In reply to Andrew Fuerste-Henry from comment #9)

...

This change will disrupt libraries' reporting of how many holds they fill over time. The patron's hold is moved to the old_reserves table with found='W', giving the impression that the hold was cancelled without the patron ever receiving an item. But in fact this hold was fulfilled, just not with the waiting item.

I really don't know if it was fulfilled. The title was checked out, yes, but not through the holds process. That hold still needed to be handled by a staff person a second time, for one. I'm asking around here, but I tend to lean towards this hold being cancelled, not filled.

The circ rule controlling this behavior is worded "Fill other record level holds on record at checkout." The current behavior, before these patches, is for the hold to be marked filled when another eligible item from the same bib is checked out. The ability to cancel the hold rather than filling it could be a reasonable change, but would need to be optional.

This makes sense. It's certainly not an issue that matters enough to me to hold up a fix for this problem. This is a problem with an outsized service impact and a very small statistical impact so I think either way is fine. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.