There are a number of bugs addressing print slip and holds issues, so this bug addresses solely the following three scenari: Item with homebranch A is reserved for pickup at branch B. 1) Item is checked in at A (parameters $reserved and $transfertodo are set) 2) Item is checked in at C (parameters $diffbranch and $transfertodo are set) 3) Item is checked in at A, then at C (parameter $WrongTransfer is set) 4) Item is checked in at A, then at B (parameter $reserved is set) In all of these, messages are created correctly, but hold-transfer-slip.pl popup is generated with transfer=1. hold-transfer-slip.pl ignores $transfer so all cases opens a dialog generated from template RESERVESLIP, where the three first actually should generate TRANSFERSLIP. Either hold-transfer-slip.pl must respect $transfer variable or transfer-slip.pl must be used in cases of transfer. Popups are generated in returns.tt, e.g.: hold-transfer-slip.pl?transfer=1&borrowernumber=[% borrowernumber %]&biblionumber=[% itembiblionumber %]&op=slip
Created attachment 26896 [details] [review] Bug 12043 - Popup when reserved item checked in at wrong branch should generate transfer slip This patch corrects some wrong popups in Returns.tt handling transfers of reserved items. Instead of using hold-transfer-slip.pl with param transfer=1 (which seems to be silently ignored) it uses transfer-slip.pl with itemnumber and destination branch, which allows for printing correct slips. It also removes the non-used param $tranfer in hold-transfer-slip.pl. Test plan: ( see cases in bug description ) 1) Make a reservation on item with homebranch A to branch B 2) checkin item at its homebranch A 3) press 'Print slip and confirm transfer' 4) verify that slip uses template RESERVESLIP 5) apply patch 6) repeat steps 1-3 7) verify that slip now uses template TRANSFERSLIP
I think I personally prefer this scenario, it seems better for maintaining patron privacy, but I do wonder if some libraries would rather know when they are transferring for a hold versus simply returning a book to another branch? Currently if someone comes in asking for a book on the transfer shelf we can easily see if it is available or transferring for a hold, this change means we have to double check. I don't know if it would be possible for TRANSFERSLIP to include the reason for the transfer, or if my concerns are shared by anyone else but I wanted to mention them. I tested on a sandbox and will sign off, it works according to the test plan.
Patch tested with a sandbox, by Nick Clemens <nick@quecheelibrary.org>
Thanks for the feedback! You obsoleted the attachment without uploading a new, I don't know it that was intended? It can easily be undone by 'show obsolete', clicking 'details' next to the bug, then 'edit details', and unchecking the obsolete box. >Currently if someone comes in asking for a book on the transfer shelf we can >easily see if it is available or transferring for a hold, this change means we >have to double check. >I don't know if it would be possible for TRANSFERSLIP to include the reason for >the transfer, or if my concerns are shared by anyone else but I wanted to >mention them. In our library the transferred items are always checked in when arriving at the destination to check for holds, and if a hold is present for the item, a hold note (with reserve id) is printed and a 'hold is ready' message is sent to borrower by sms or email. I don't know how other libraries handle this, but wouldn't always an item need to be checked in at destination? Maybe I'm missing something. Anyway, there will probably be some followup on this one.
(In reply to Benjamin Rokseth from comment #4) > Thanks for the feedback! > > You obsoleted the attachment without uploading a new, I don't know it that > was intended? It can easily be undone by 'show obsolete', clicking 'details' > next to the bug, then 'edit details', and unchecking the obsolete box. It's my fault, git-bz has not been updated on sandboxes. I did it this morning, this issue should not appear anymore.
Created attachment 28609 [details] [review] Bug 12043 - Popup when reserved item checked in at wrong branch should generate transfer slip This patch corrects some wrong popups in Returns.tt handling transfers of reserved items. Instead of using hold-transfer-slip.pl with param transfer=1 (which seems to be silently ignored) it uses transfer-slip.pl with itemnumber and destination branch, which allows for printing correct slips. It also removes the non-used param $tranfer in hold-transfer-slip.pl. Test plan: ( see cases in bug description ) 1) Make a reservation on item with homebranch A to branch B 2) checkin item at its homebranch A 3) press 'Print slip and confirm transfer' 4) verify that slip uses template RESERVESLIP 5) apply patch 6) repeat steps 1-3 7) verify that slip now uses template TRANSFERSLIP Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Created attachment 33563 [details] [review] Bug 12043 - Popup when reserved item checked in at wrong branch should generate transfer slip This patch corrects some wrong popups in Returns.tt handling transfers of reserved items. Instead of using hold-transfer-slip.pl with param transfer=1 (which seems to be silently ignored) it uses transfer-slip.pl with itemnumber and destination branch, which allows for printing correct slips. It also removes the non-used param $tranfer in hold-transfer-slip.pl. Test plan: ( see cases in bug description ) 1) Make a reservation on item with homebranch A to branch B 2) checkin item at its homebranch A 3) press 'Print slip and confirm transfer' 4) verify that slip uses template RESERVESLIP 5) apply patch 6) repeat steps 1-3 7) verify that slip now uses template TRANSFERSLIP Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Hi Benjamin, can you take a look at the patch? It only contains a one line change... and it looks like the problem is already fixed on master? I suspect it's no longer needed.
(In reply to Katrin Fischer from comment #8) > Hi Benjamin, > > can you take a look at the patch? It only contains a one line change... and > it looks like the problem is already fixed on master? I suspect it's no > longer needed. Actually, my bad. Seems like the main patch fell out in the rebase. Removing the line $transfer = 1; from circ/hold-transfer.pl was just to clean up the unused parameter transfer=1 from templates. The main patch uses transfer.pl instead of hold-transfer.pl when a transfer was made. I will submit the patch anew and reset to signed off
Created attachment 33656 [details] [review] Bug 12043 - Popup when reserved item checked in at wrong branch should generate transfer slip This patch corrects some wrong popups in Returns.tt handling transfers of reserved items. Instead of using hold-transfer-slip.pl with param transfer=1 (which seems to be silently ignored) it uses transfer-slip.pl with itemnumber and destination branch, which allows for printing correct slips. It also removes the non-used param $tranfer in hold-transfer-slip.pl. Test plan: ( see cases in bug description ) 1) Make a reservation on item with homebranch A to branch B 2) checkin item at its homebranch A 3) press 'Print slip and confirm transfer' 4) verify that slip uses template RESERVESLIP 5) apply patch 6) repeat steps 1-3 7) verify that slip now uses template TRANSFERSLIP Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
I see some weird behaviour in my testing. Koha says on check-in: Please ... to Centerville Print slip or Cancel transfer But my transfer slip states: Transfer to Midway Benjamin, can you take a look how this can happen? I manually transferred it to Centerville (using the feature on the circulation page), while the book is originally from Midway.
- this bug is now mainly deprecated by 13482.