https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24898 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203469 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203469&action=edit Bug 24898: AddIssue no longer falsifies transfers it interrupts When AddIssue found an active transfer for the item being checked out, it unconditionally stamped datearrived to now and rewrote tobranch to the checkout branch, regardless of whether that was actually the transfer's destination. This silently discarded the real destination and recorded a false arrival, with no reason logged for what happened - corrupting the audit trail and confusing any code (e.g. StockRotation) that later reasons about that transfer's history. AddIssue now compares the transfer's tobranch to the branch the checkout is happening at: - If they match, the item has genuinely arrived at its destination and is being checked out from there, so the transfer is completed normally via Transfer->receive (the same call AddReturn already uses for this case). - If they don't match, the item was diverted before completing its journey, so the transfer is cancelled via Transfer->cancel with cancellation_reason 'WrongTransfer' - the same enum value AddReturn already uses for an item turning up at the wrong branch. The original tobranch and reason are preserved rather than overwritten. No schema change is needed; 'WrongTransfer' already existed as a cancellation_reason value for this exact situation on the check-in side, it just wasn't reused here. Test plan: 1. Apply the patch 2. prove t/db_dependent/Circulation.t => All tests pass, including the two 'Checkout should ... transfer' subtests 3. prove t/db_dependent/Circulation/ t/db_dependent/Koha/Item.t \ t/db_dependent/Koha/Item/Transfer.t t/db_dependent/Reserves.t => All pass, no regressions 4. Manually: place a hold on an item at library B, let it transfer from library A, then check it out at library C (neither A nor B). Confirm in branchtransfers that the original transfer now shows cancellation_reason = 'WrongTransfer' and tobranch is still B, not C, and datearrived is NULL. 5. Repeat, checking the item out at library B (the real destination). Confirm the transfer shows datearrived set and tobranch unchanged. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24898 --- Comment #3 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203471 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203471&action=edit Bug 24898: DBIC Schema Update -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24898 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Sponsorship status|--- |Unsponsored QA Contact|testopia@bugs.koha-communit |nick@bywatersolutions.com |y.org | 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=24898 --- Comment #5 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203474 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203474&action=edit Bug 24898: Add 'Checkout' to branchtransfers.cancellation_reason enum AddIssue needs to distinguish "this transfer was cancelled because the item turned up at the wrong branch" (the existing 'WrongTransfer' value, used by AddReturn) from "this transfer was cancelled because the item got checked out before it ever arrived" - two different real-world events that shouldn't share one enum value, per the discussion on Bug 24298 comment 27/28. Test plan: 1. Apply the patch 2. perl installer/data/mysql/updatedatabase.pl 3. dbic --force 4. Confirm branchtransfers.cancellation_reason now accepts 'Checkout' -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24898 --- Comment #7 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203476 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203476&action=edit Bug 24898: AddIssue no longer falsifies transfers it interrupts When AddIssue found an active transfer for the item being checked out, it unconditionally stamped datearrived to now and rewrote tobranch to the checkout branch, regardless of whether that was actually the transfer's destination. This silently discarded the real destination and recorded a false arrival, with no reason logged for what happened - corrupting the audit trail and confusing any code (e.g. StockRotation) that later reasons about that transfer's history. AddIssue now compares the transfer's tobranch to the branch the checkout is happening at: - If they match, the item has genuinely arrived at its destination and is being checked out from there, so the transfer is completed normally via Transfer->receive (the same call AddReturn already uses for this case). - If they don't match, the item was diverted before completing its journey, so the transfer is cancelled via Transfer->cancel with cancellation_reason 'Checkout' (added by the previous commit) - preserving the original tobranch and reason rather than overwriting them. This matches the discussion on Bug 24298 comment 27/28, which is where this bug originated: the cancellation reason shouldn't be conflated with what originally triggered the transfer, and the original destination shouldn't be destroyed just because something else happened to the item first. Test plan: 1. Apply the patch 2. prove t/db_dependent/Circulation.t => All tests pass, including the two 'Checkout should ... transfer' subtests 3. prove t/db_dependent/Circulation/ t/db_dependent/Koha/Item.t \ t/db_dependent/Koha/Item/Transfer.t t/db_dependent/Reserves.t => All pass, no regressions 4. Manually: place a hold on an item at library B, let it transfer from library A, then check it out at library C (neither A nor B). Confirm in branchtransfers that the original transfer now shows cancellation_reason = 'Checkout' and tobranch is still B, not C, and datearrived is NULL. 5. Repeat, checking the item out at library B (the real destination). Confirm the transfer shows datearrived set and tobranch unchanged. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24898 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |22160 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22160 [Bug 22160] OMNIBUS: Transfers enhancements -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24898 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|22160 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22160 [Bug 22160] OMNIBUS: Transfers enhancements -- You are receiving this mail because: You are watching all bug changes.