https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40331 --- Comment #2 from Lisette Scheer <lisette@bywatersolutions.com> --- (In reply to Nick Clemens (kidclamp) from comment #1)
This seems to be conflicting ideas in the code.
At step 4, we get a WrongTransfer message and pop-up a modal, before displaying that modal we do: 553 # We need to ignore limits here. While we can't transfer from this branch, it is, wrongly, here right now 554 # and that fact must be recorded 555 my $new_transfer = $item->request_transfer( 556 { 557 to => $old_transfer->to_library, 558 reason => $old_transfer->reason, 559 replace => 'WrongTransfer', 560 ignore_limits => 1 561 } 562 );
So this step updates the original transfer to cancelled with wrongtransfer reason and creates a new transfer
So one transfer is closed and a new one created. Then when the 'Confirm hold and transfer' button is clicked we hit the cud-affect_reserve code: 156 # Add transfer, enqueue if one is already in the queue, and immediately set to in transit 157 my $transfer = $item->request_transfer( { to => $tobranch, reason => 'Reserve', enqueue => 1 } ); 158 $transfer->transit;
So we are intentionally queuing a second transfer - I don't understand the case where the first transfer needs to be left in place - or perhaps we can simply check if the first transfer exists, is going to the correct library, and then simply mark the existing one as in transit from our current location?
Then here we have a new transfer that is created and sent. We should instead be updating the transfer from the previous code. Should we be showing the "wrong transfer" modal? Currently the "hold-modal" is what shows, but I believe previously "wrong transfer" showed and the transfer could be canceled if needed? -- You are receiving this mail because: You are watching all bug changes.