https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527
--- Comment #13 from Martin Renvoize (ashimema) <[email protected]> --- Created attachment 194017 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194017&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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
