https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@ptfs-europe |ity.org |.com -- 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=28527 --- Comment #1 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Bug 28520 is very specific for the Reserve/Holds case, but does not account for transfers triggered by other means or cancelled by other means. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 --- Comment #2 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 121739 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121739&action=edit Bug 28527: Restore cancellation of transfers from Koha::Hold This aptch restores the cancellation of the transfers in transit when a hold is cancelled. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 --- Comment #4 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 121741 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121741&action=edit Bug 28527: Deal with cancelled in transfer transfers when enqueueing Addeding to the queue should be allowed when the active transfer (in_transit) has been cancelled. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Martin Renvoize <martin.renvoize@ptfs-europe.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=28527 Koha Training Catalyst <koha-training@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |koha-training@catalyst.net. | |nz --- Comment #6 from Koha Training Catalyst <koha-training@catalyst.net.nz> --- Can you please provide a test plan? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|BLOCKED |Failed QA --- Comment #8 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Missing test plan = Failed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Martin Renvoize (ashimema) <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|BLOCKED |Failed QA CC| |lisette@bywatersolutions.co | |m --- Comment #9 from Lisette Scheer <lisette@bywatersolutions.com> --- All the blockers are closed so I'm putting this back to failed QA for no test plan. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 --- Comment #11 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 188298 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=188298&action=edit Bug 28527: Handle cancelled in-transit transfers This patch addresses the issue where items with cancelled in-transit transfers become stuck in an inconsistent state, preventing new transfers from being created and causing confusion at checkin. Problem: -------- When a hold is cancelled while an item is in transit, the transfer is cancelled but remains in an incomplete state (datesent populated, datecancelled populated, datearrived not set). This causes: 1. Items cannot have new transfers created (blocked by cancelled transfer) 2. Checking in items at wrong locations doesn't provide clear messaging 3. No automatic workflow to return items to their original location 4. Cancelled transfers disappear from the system visibility Solution: --------- This patch implements a complete workflow for handling cancelled in-transit transfers: 1. Koha::Item::Transfer->is_cancelled() - New method to check if a transfer has been cancelled 2. Koha::Item::Transfer->in_transit() - Modified to return true even for cancelled transfers (now only checks datesent and datearrived) 3. Koha::Item->get_transfers() - Modified to include cancelled transfers in the result set, making them visible in the system 4. Koha::Item->get_transfer() - Modified to skip over cancelled transfers and return the first active transfer 5. Koha::Hold->cancel() - When cancelling a hold, now automatically cancels the associated in-transit transfer with reason 'CancelReserve' 6. C4::Circulation::AddReturn() - Modified to loop through and receive all cancelled transfers at checkin, track the original holding branch, and set new 'TransferCancelled' message 7. circ/returns.pl - Added handler for TransferCancelled message that automatically creates a reverse transfer to return the item to its original holding branch using reason 'TransferCancellation' 8. returns.tt - Updated checkin modal to display appropriate messages for both wrong transfers and cancelled transfers Test plan: ---------- 1. Setup - Create three library branches: BranchA, BranchB, BranchC 2. Test hold cancellation cancels transfer: a) Create an item at BranchA b) Create a patron at BranchB c) Place a hold on the item for the patron d) At BranchA, check out the item (triggers transfer to BranchB) e) Verify transfer is created: SELECT * FROM branchtransfers WHERE itemnumber=<item> ORDER BY datesent DESC LIMIT 1 f) Cancel the hold g) Verify transfer is cancelled: Check datecancelled is populated h) Verify cancellation_reason is 'CancelReserve' 3. Test cancelled transfers remain visible: a) Using item from test 2 with cancelled transfer b) Search for the item in staff interface c) View item details d) Verify cancelled transfer information is still visible 4. Test new transfers can be created after cancellation: a) With the same item from test 2 b) Go to Circulation > Transfer c) Scan the item barcode d) Select BranchC as destination e) Verify transfer is created successfully (not blocked) f) Check branchtransfers table shows both cancelled and new transfer: SELECT * FROM branchtransfers WHERE itemnumber=<item> ORDER BY datesent DESC 5. Test checkin with cancelled transfer (wrong branch): a) Create fresh scenario: Item at BranchA, patron at BranchB b) Place hold on item for patron (triggers transfer A->B) c) Cancel the hold (cancels the transfer) d) Item is still physically in transit e) At BranchC (wrong branch), check in the item f) Verify modal appears with message: "Transfer was cancelled whilst in transit, please return item to: BranchA" g) Click OK h) Verify new transfer created from BranchC to BranchA i) Check branchtransfers table: - Old transfer has datearrived populated - New transfer exists with reason 'TransferCancellation' 6. Test checkin with cancelled transfer (correct branch): a) Create scenario: Item at BranchA with cancelled transfer b) Check in item at BranchA (original holding branch) c) Verify cancelled transfer is received (datearrived set) d) Verify item returns to available status at BranchA e) Verify appropriate messaging displayed to staff 7. Test get_transfer() skips cancelled transfers: a) Create item with one cancelled transfer and one active transfer b) Call $item->get_transfer() via prove or koha-shell c) Verify it returns the active transfer, not the cancelled one 8. Test multiple cancelled transfers: a) Create item at BranchA b) Create and cancel transfer to BranchB c) Create and cancel transfer to BranchC d) Create active transfer to BranchB (don't cancel) e) Verify get_transfer() returns the active transfer f) Verify get_transfers() returns all three transfers 9. Run unit tests: prove t/db_dependent/Koha/Item/Transfer.t prove t/db_dependent/Koha/Item.t prove t/db_dependent/Circulation/Returns.t All tests should pass. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121740|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=28527 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121742|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=28527 --- Comment #12 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Yeah... that rebase was never going to work. I've reworked it from scratch taking the original as inspiration and included a comprehensive test plan. I'd love feedback, not sure I've thought it all through. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #188298|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=28527 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #14 from Lisette Scheer <lisette@bywatersolutions.com> --- When I got to step 3.d of the test plan, the item was still showing as available. I reset_all, yarn build, and cleared my browser cache. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|aleisha@catalyst.net.nz | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 --- Comment #15 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203483 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203483&action=edit Bug 28527: Handle cancelled in-transit transfers This patch addresses the issue where items with cancelled in-transit transfers become stuck in an inconsistent state, preventing new transfers from being created and causing confusion at checkin. Problem: -------- When a hold is cancelled while an item is in transit, the transfer is cancelled but remains in an incomplete state (datesent populated, datecancelled populated, datearrived not set). This causes: 1. Items cannot have new transfers created (blocked by cancelled transfer) 2. Checking in items at wrong locations doesn't provide clear messaging 3. No automatic workflow to return items to their original location 4. Cancelled transfers disappear from the system visibility Solution: --------- This patch implements a complete workflow for handling cancelled in-transit transfers: 1. Koha::Item::Transfer->is_cancelled() - New method to check if a transfer has been cancelled 2. Koha::Item::Transfer->in_transit() - Modified to return true even for cancelled transfers (now only checks datesent and datearrived) 3. Koha::Item->get_transfers() - Modified to include cancelled transfers in the result set, making them visible in the system 4. Koha::Item->get_transfer() - Modified to skip over cancelled transfers and return the first active transfer 5. Koha::Hold->cancel() - When cancelling a hold, now automatically cancels the associated in-transit transfer with reason 'CancelReserve' 6. C4::Circulation::AddReturn() - Modified to loop through and receive all cancelled transfers at checkin, track the original holding branch, and set new 'TransferCancelled' message 7. circ/returns.pl - Added handler for TransferCancelled message that automatically creates a reverse transfer to return the item to its original holding branch using reason 'TransferCancellation' 8. returns.tt - Updated checkin modal to display appropriate messages for both wrong transfers and cancelled transfers Test plan: ---------- 1. Setup - Create three library branches: BranchA, BranchB, BranchC 2. Test hold cancellation cancels transfer: a) Create an item at BranchA b) Create a patron at BranchB c) Place a hold on the item for the patron d) At BranchA, check out the item (triggers transfer to BranchB) e) Verify transfer is created: SELECT * FROM branchtransfers WHERE itemnumber=<item> ORDER BY datesent DESC LIMIT 1 f) Cancel the hold g) Verify transfer is cancelled: Check datecancelled is populated h) Verify cancellation_reason is 'CancelReserve' 3. Test cancelled transfers remain visible: a) Using item from test 2 with cancelled transfer b) Search for the item in staff interface c) View item details d) Verify cancelled transfer information is still visible 4. Test new transfers can be created after cancellation: a) With the same item from test 2 b) Go to Circulation > Transfer c) Scan the item barcode d) Select BranchC as destination e) Verify transfer is created successfully (not blocked) f) Check branchtransfers table shows both cancelled and new transfer: SELECT * FROM branchtransfers WHERE itemnumber=<item> ORDER BY datesent DESC 5. Test checkin with cancelled transfer (wrong branch): a) Create fresh scenario: Item at BranchA, patron at BranchB b) Place hold on item for patron (triggers transfer A->B) c) Cancel the hold (cancels the transfer) d) Item is still physically in transit e) At BranchC (wrong branch), check in the item f) Verify modal appears with message: "Transfer was cancelled whilst in transit, please return item to: BranchA" g) Click OK h) Verify new transfer created from BranchC to BranchA i) Check branchtransfers table: - Old transfer has datearrived populated - New transfer exists with reason 'TransferCancellation' 6. Test checkin with cancelled transfer (correct branch): a) Create scenario: Item at BranchA with cancelled transfer b) Check in item at BranchA (original holding branch) c) Verify cancelled transfer is received (datearrived set) d) Verify item returns to available status at BranchA e) Verify appropriate messaging displayed to staff 7. Test get_transfer() skips cancelled transfers: a) Create item with one cancelled transfer and one active transfer b) Call $item->get_transfer() via prove or koha-shell c) Verify it returns the active transfer, not the cancelled one 8. Test multiple cancelled transfers: a) Create item at BranchA b) Create and cancel transfer to BranchB c) Create and cancel transfer to BranchC d) Create active transfer to BranchB (don't cancel) e) Verify get_transfer() returns the active transfer f) Verify get_transfers() returns all three transfers 9. Run unit tests: prove t/db_dependent/Koha/Item/Transfer.t prove t/db_dependent/Koha/Item.t prove t/db_dependent/Circulation/Returns.t All tests should pass. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 --- Comment #17 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203485 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203485&action=edit Bug 28527: (follow-up) Redirect cancelled in-transit transfers to the right branch AddReturn's handling of a transfer cancelled whilst in transit always redirected the item back to the transfer's frombranch, on the assumption that the original purpose of the trip no longer applies (true for a cancelled hold or recall, the case this was built around). That assumption doesn't hold for every reason: - For StockrotationAdvance/StockrotationRepatriation, redirecting to frombranch sends the item backwards. Koha::StockRotationItem's stage is already updated to the next stage optimistically when the advance transfer is created, and StockRotation's own cron already re-evaluates and corrects an item's location every run (needs_ repatriating/needs_advancing, see Bug 42513). Creating a redirect here is a redundant transfer that StockRotation would then have to notice and correct a second time. Skip creating one at all and let StockRotation handle it in a single hop, as it already can. - For ReturnToHome/ReturnToHolding/RotatingCollection/ LibraryFloatLimit, the transfer's destination was never in doubt - it's the item's home/holding branch or a collection's base - so cancelling this specific transfer attempt doesn't mean that destination stopped being correct. Redirect onward to tobranch instead of backward to frombranch. - Everything else (Reserve, LostReserve, CancelReserve, Recall, RecallCancellation, Manual, TransferCancellation) keeps the existing frombranch behaviour: the specific reason for the trip is gone, so send the item home. New Koha::Item::Transfer->reroute_to encapsulates this decision. Test plan: 1. prove t/db_dependent/Koha/Item/Transfer.t => New 'reroute_to tests' subtest passes 2. prove t/db_dependent/Circulation/Returns.t => New 'Cancelled in-transit transfers are rerouted appropriately' subtest passes: no transfer created for StockrotationAdvance, frombranch for Reserve, tobranch for ReturnToHome 3. prove t/db_dependent/Circulation.t t/db_dependent/Circulation/ \ t/db_dependent/Koha/Item.t t/db_dependent/Reserves.t \ t/db_dependent/StockRotationItems.t t/db_dependent/Holds.t => All pass, no regressions -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |30777 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30777 [Bug 30777] stockrotationitems table could store additional information -- You are receiving this mail because: You are watching all bug changes.