https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814
--- Comment #109 from Martin Renvoize (ashimema) <[email protected]> --- Created attachment 203348 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203348&action=edit Bug 19814: (follow-up) Fix no-op WrongTransfer repair repair_wrong_transfer() asked request_transfer() to replace the stale transfer with one to the same to_library/reason as the transfer it was replacing. request_transfer()'s own dedup check runs before the replace logic and matches on frombranch/tobranch/reason, so whenever the item's current holding branch equalled the stale transfer's frombranch (e.g. the item never actually left and was checked in again at the same branch), that check found the stale transfer still live and handed it straight back -- silently skipping the replace. The old row was never cancelled and no new row was created. Cancel the stale transfer explicitly before requesting its replacement, so request_transfer()'s dedup search no longer sees it as live. This is the same bug in both the single-item and batch checkin paths, since both call this shared sub. Test plan: 1. Set up a transfer for item X from library A -> B, then check the item back in at library A itself (its own frombranch) rather than B or a third branch. 2. Before this patch: the A->B transfer row is untouched -- datecancelled/cancellation_reason stay NULL, no new row appears. 3. After this patch: the A->B row gets datecancelled set and cancellation_reason = 'WrongTransfer', and a new row is created recording the item's corrected frombranch. 4. Repeat via batch checkin -- same result. -- 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/
