Bug 12043 - Popup when reserved item checked in at wrong branch should generate transfer slip
Summary: Popup when reserved item checked in at wrong branch should generate transfer ...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: master
Hardware: All All
: P5 - low minor (vote)
Assignee: Benjamin Rokseth
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-08 12:08 UTC by Benjamin Rokseth
Modified: 2017-06-14 22:10 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 12043 - Popup when reserved item checked in at wrong branch should generate transfer slip (4.69 KB, patch)
2014-04-08 12:34 UTC, Benjamin Rokseth
Details | Diff | Splinter Review
Bug 12043 - Popup when reserved item checked in at wrong branch should generate transfer slip (4.74 KB, patch)
2014-06-02 13:50 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 12043 - Popup when reserved item checked in at wrong branch should generate transfer slip (1.52 KB, patch)
2014-11-14 11:04 UTC, Benjamin Rokseth
Details | Diff | Splinter Review
Bug 12043 - Popup when reserved item checked in at wrong branch should generate transfer slip (4.79 KB, patch)
2014-11-18 15:18 UTC, Benjamin Rokseth
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Rokseth 2014-04-08 12:08:23 UTC
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
Comment 1 Benjamin Rokseth 2014-04-08 12:34:00 UTC Comment hidden (obsolete)
Comment 2 Nick Clemens 2014-05-30 21:32:18 UTC
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.
Comment 3 Biblibre Sandboxes 2014-05-30 21:32:49 UTC
Patch tested with a sandbox, by Nick Clemens <nick@quecheelibrary.org>
Comment 4 Benjamin Rokseth 2014-06-02 08:06:29 UTC
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.
Comment 5 Jonathan Druart 2014-06-02 13:48:05 UTC
(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.
Comment 6 Jonathan Druart 2014-06-02 13:50:15 UTC Comment hidden (obsolete)
Comment 7 Benjamin Rokseth 2014-11-14 11:04:26 UTC Comment hidden (obsolete)
Comment 8 Katrin Fischer 2014-11-15 09:39:19 UTC
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.
Comment 9 Benjamin Rokseth 2014-11-18 15:18:03 UTC
(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
Comment 10 Benjamin Rokseth 2014-11-18 15:18:45 UTC
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>
Comment 11 Katrin Fischer 2014-11-20 07:12:15 UTC
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.
Comment 12 Benjamin Rokseth 2016-11-06 22:13:26 UTC
- this bug is now mainly deprecated by 13482.