https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blawlor@clamsnet.org --- Comment #9 from Brendan Lawlor <blawlor@clamsnet.org> --- I think this is still valid, or maybe it's a slightly different bug. We've got reports of duplicate transfers currently happening in production and I was also able to reproduce in main. To replicate: 1. With no holds, at library A check in an item owned by Library B 2. A branch transfer for Return to Home is triggered (Check in message: Not checked out) 3. Now place a hold on the bib record for pickup at library C 4. Check the item in at library A again 5. A new branch transfer is created for reason Reserve 6. The original ReturnToHome transfer is not cancelled 7. select * from branchtransfers to confirm no cancellationdate in the first transfer Maybe this is partially by design because you can't actually tell if an item is really in transit to return home, or if it accidentally got put back on the shelf at library A instead of going in delivery. In returns.pl there are two lines with this comment that enqueues a transfer if one is already in the queue: # Add transfer, enqueue if one is already in the queue, and immediately set to in transit my $transfer = $item->request_transfer( { to => $tobranch, reason => 'Reserve', enqueue => 1 } ); I wonder if either of those situations should use replace => 'Reserve' instead of enqueue => 1 I tested and changing to use replace instead of enqueue adds a datecancelled and cancellation_reason to the existing transfer instead of leaving it as a pending transfer. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.