https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41809
Andrii Nugged <[email protected]> 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 <[email protected]> --- 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. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
