Bug 13153

Summary: Waiting hold checked in at different library doesn't re-route item to correct library
Product: Koha Reporter: Kyle M Hall <kyle>
Component: Hold requestsAssignee: Nick Clemens <nick>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: major    
Priority: P5 - low CC: barton, cbrannon, edischer, eveal, george, gmcharlt, gwilliams, hughr, jbranick, jdemuth, jzairo, katrin.fischer, mfuerst, nick, r.delahunty, sally.healey
Version: unspecified   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: Bug 13153 - Waiting hold checked in at different library doesn't re-route item to correct library
Bug 13153 - Waiting hold checked in at different library doesn't re-route item to correct library

Description Kyle M Hall 2014-10-28 13:25:16 UTC
It seems that if an item is triggered at a location as waiting for pickup, if that item falls into the hands of another library by mistake, Koha doesn’t know what to do with it.  It just records a local use.  It doesn’t try to transfer home or to the library it should be waiting at.

Correct behavior should be that if it is scanned at another location other than where the system thinks it is, it should trigger a transfer to where it should be.

Right now, the only way to get the item back on course is to go to the holds for that item and change the waiting to priority 1 again, and change any other priorities back one level, if any, and then check the item in again.

To reproduce:
1) Place a hold on an item for a patron at LibraryA
2) Check the item in at LibraryA
3) Confirm the hold at LibraryA, the item is now a waiting hold
4) Set your logged in branch to LibraryB
5) Check the item in at LibraryB
6) Notice there is no request to transfer the item to LibraryA

I think what should probably happen is the hold status should go from Waiting (W) to In Transit (T), and a transfer should be created.
Comment 1 Christopher Brannon 2014-10-28 14:49:58 UTC
We believe this is a major cause for stalled items, and why items end up missing or on the shelves at other libraries.  This would be a very good bug to fix.

Christopher
Comment 2 Nick Clemens 2015-02-08 02:24:30 UTC
*** Bug 11924 has been marked as a duplicate of this bug. ***
Comment 3 Sally 2016-01-07 14:26:21 UTC
This issue doesn't occur often, but when it does, the 'local use' response in particular is highly problematic.

As a temporary measure, even a prompt for the staff member to investigate the item would be preferable.

Ideally, a full solution would be as Kyle has suggested - the hold should change status from Waiting to In Transit, and a transfer to the collection branch should occur.
Comment 4 Christopher Brannon 2016-01-19 21:50:50 UTC
Still problematic.  Ran into this issue again.  Caused by human error, but when correcting the situation, Koha displays confusing information.  Really need the hold status updated and item routed correctly if the item is scanned at another location while waiting.

Christopher
Comment 5 HB-NEKLS 2016-02-15 21:19:30 UTC
Still problematic in 3.22. I accidentally ran into it on testing 3.22 today.
Comment 6 jdemuth@roseville.ca.us 2016-11-10 23:16:47 UTC
I was able to confirm this between multiple libraries while the item is still in transit. 

Here was my test plan:

1. Placed a hold on an item that is checked out for a patron to pick up at Library A.
2. Item is checked in at library B and gets the transit hold message but staff accidentally send it to Library C.
3. Item is checked in at Library C and no hold message comes up at all and staff only see a Checkin: Not checked out message and put it on their shelved unaware of the hold. 
4. Item will show in Transit from Library B to A but is really at Library C. 

I have noticed this happen a few times and while the issue involves some staff errors, Koha should show the transit message at any library location and not just the two involved with the hold. 


Jen DeMuth
Library Technician 
Technology & Support Services
Parks, Recreation & Libraries
225 Taylor St.
Roseville, CA 95678
(916) 774-5238
roseville.ca.us/library
Comment 7 jdemuth@roseville.ca.us 2016-11-10 23:24:13 UTC
I forgot to include that we are on 3.22.08.

Jen DeMuth
Comment 8 Sally 2016-11-11 17:49:24 UTC
*** Bug 15118 has been marked as a duplicate of this bug. ***
Comment 9 Christopher Brannon 2017-03-02 22:52:30 UTC
This issue needs to be addressed.  This has been a time waster for support staff trying to figure out why these things happen each time.  A waiting item triggered at another library needs to be routed back to its intended destination and the waiting status needs to be set back to priority 1.

Christopher
Comment 10 George Williams (NEKLS) 2017-03-02 23:04:07 UTC
I agree with Christopher.  This has been a problem for a long time.

George
Comment 11 Nick Clemens 2017-03-07 22:11:12 UTC
Created attachment 60909 [details] [review]
Bug 13153 - Waiting hold checked in at different library doesn't re-route item to correct library

This patch changes AddReturn to revert a waiting hold whenchecked in at
another branch

To test:
1 - Place a hold for pickup at current branch
2 - Check in and confirm hold
3 - Change branch
4 - Checkin the item again
5 - Note there is no message to transfer or hold
6 - Note current location (holdingbranch) has changed though status
indicates waitingat original branch
7 - Apply patch
8 - Checkin the item again
9 - Note hold is reverted
10 - Note message to confirm hold/transfer
11 - Sign off
Comment 12 Marc Véron 2017-03-08 09:25:02 UTC
Created attachment 60911 [details] [review]
Bug 13153 - Waiting hold checked in at different library doesn't re-route item to correct library

This patch changes AddReturn to revert a waiting hold whenchecked in at
another branch

To test:
1 - Place a hold for pickup at current branch
2 - Check in and confirm hold
3 - Change branch
4 - Checkin the item again
5 - Note there is no message to transfer or hold
6 - Note current location (holdingbranch) has changed though status
indicates waitingat original branch
7 - Apply patch
8 - Checkin the item again
9 - Note hold is reverted
10 - Note message to confirm hold/transfer
11 - Sign off

Followed test plan, item gos to 'In transit' as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Comment 13 Christopher Brannon 2017-03-08 15:41:57 UTC
Found a problem scenario, may have to open another ticket, as this patch pretty much takes care of what is described.

Item from Library B checked in at Library A.  There is a hold for a patron at Library C.  It is accidently transferred to Library B or any other library other than A or C.  A transfer message comes up saying to transfer the item to Library C, saying there is a hold, but the patron name and barcode are blank (Patron category shows).  There is also a blank bullet after the patron line.  This may be a transfer message, but because it is showing that there is a hold, and the patron name and barcode are blank, I am not sure if it is part of this bug or something new.

Issue: Transfer message does not show patron name or barcode.  Extra bullet shown.
Comment 14 Nick Clemens 2017-03-08 15:55:51 UTC
(In reply to Christopher Brannon from comment #13)
> Found a problem scenario

Is this a scenario in master, or a side effect of this patch?
Comment 15 Christopher Brannon 2017-03-08 19:08:22 UTC
There seems to be an intermittent problem with routing/information.

I tried my previous scenario again, and it worked fine this time, but then I got the same failure through a different scenario.

1) Checked in item with no checkouts or holds belonging to Library B at Library A for transfer. Item is now in transit to Library B.
2) Placed a hold on item to be picked up at Library C.  
3) Triggered hold at Library A and was routed to Library C.  Item is in transit to Library C.
4) Signed in as Library D, checked in item and it routed Library C fine.
5) Signed in as Library C and triggered the hold.  Item is now waiting.
6) Signed in as Library D, checked in item.  The modal doesn't come up, and the transfer message is on the screen to got to transfer the item to Library C, but patron barcode and name are missing.
7) If I cancel the transfer and check it in again, the modal comes up and patron information shows properly.

I think there is a conflict with an initial transfer that doesn't get cleared out in the whole process.

On master, if I follow the same steps, this is what I see:

1) Checked in item with no checkouts or holds belonging to Library B at Library A for transfer. Item is now in transit to Library B.
2) Placed a hold on item to be picked up at Library C.  
3) Triggered hold at Library A and was routed to Library C.  Item is in transit to Library C.
4) Signed in as Library D, checked in item and it wants to go home to Library B.  WRONG
5) Signed in as Library C and triggered the hold.  Item is now waiting.
6) Signed in as Library D, checked in item.  The modal doesn't come up, and the transfer message is on the screen to got to transfer the item HOME to Library B, AND to confirm hold for patron.  The library the patron is picking up at is NOT showing, but patron name and barcode ARE showing.  The extra bullet is showing and is a pre-existing issue.
7) If I cancel the transfer and check it in again, there are no messages and a local use is recorded.  WRONG
Comment 16 Hugh Rundle 2018-02-27 23:02:42 UTC
This bug has been listed since 2014 and a patch provided 12 months ago. It is a really big problem for multi-branch libraries and as others have noted, the workarounds are cumbersome.

What needs to happen to close this off? 

I note the issue raised by Christopher but it seems unclear whether this is caused by the patch or is simply revealing a different bug. My own preference would be to note it as a separate bug and push this patch, which will do the job in most scenarios. Not getting the right info in a popup telling staff who the hold is for is a minor problem compared to not getting any indication at all that an item has an allocated hold on it and needs to be transferred.
Comment 17 Katrin Fischer 2018-02-27 23:14:52 UTC
It looks like Christopher moved this into 'in Discussion' pointing out some issues he found - moving to failed QA to get some feedback from the developer.

It could help if you could test the patch and confirm good/bad behaviour looking at the test plans. 

I also notice the bug was not assigned, so might have slipped through the saved searches.
Comment 18 Hugh Rundle 2018-02-27 23:19:48 UTC
Great, ok I'll wait a bit to see if Marc or Nick can shed any light and if they think further testing is needed we might be able to test at Brimbank.

(In reply to Katrin Fischer from comment #17)
> It looks like Christopher moved this into 'in Discussion' pointing out some
> issues he found - moving to failed QA to get some feedback from the
> developer.
> 
> It could help if you could test the patch and confirm good/bad behaviour
> looking at the test plans. 
> 
> I also notice the bug was not assigned, so might have slipped through the
> saved searches.
Comment 19 Katrin Fischer 2018-02-27 23:20:50 UTC
Thx for commenting - it's good. :)
Comment 20 Martha Fuerst 2018-06-21 14:35:14 UTC
Bug bump?
Comment 21 Hugh Rundle 2018-06-24 23:31:12 UTC
(In reply to Martha Fuerst from comment #20)
> Bug bump?

Just confirming that we applied this patch on 16.11 in a 5-branch library service several months ago and it appears to have fixed the substantive problem.

Would be great to do the pop-up message cleanup for 18.11 but maybe that should be split into a new bug?
Comment 22 Ed Veal 2018-07-24 20:34:51 UTC
My view on this bug is that it is appropriately marked as "low" since this issue should rarely arise. However, it has also been a long standing issue for many libraries, the bug was posted in 2014 so it is almost four years old. 

s a library managers we try very hard to get staff to not make mistakes but in the real world they happen. The problem here is when this issue does creep in it has a direct patron impact and makes the staff as well Koha look bad in the eyes of our patrons.  

Let's see if we can get some movement on this issue. 

Ed
Comment 23 Katrin Fischer 2018-08-08 12:40:54 UTC
Nick, could you take a look at the comments here plz?
Comment 24 Lisette Scheer 2018-09-12 18:25:14 UTC
*** Bug 19720 has been marked as a duplicate of this bug. ***
Comment 25 Christopher Brannon 2018-09-26 20:06:32 UTC
I managed to resolve this issue in my bug.  I welcome more sign-offs.

*** This bug has been marked as a duplicate of bug 21346 ***