Bug 24301

Summary: Holds to pull: Name of borrower on list
Product: Koha Reporter: Michal Denar <black23>
Component: Hold requestsAssignee: Jonathan Druart <jonathan.druart>
Status: RESOLVED DUPLICATE QA Contact: Josef Moravec <josef.moravec>
Severity: normal    
Priority: P5 - low CC: black23, gmcharlt, jonathan.druart, josef.moravec, katrin.fischer, lucy.vaux-harvey, martin.renvoize, nick, rbit, rhouk
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19288
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on:    
Bug Blocks: 24488    
Attachments: Bug 24301: Retrieve patron's info for hold with priority = 1
Bug 24301: Retrieve patron's info for hold with priority = 1
Bug 24301: Retrieve patron's info for hold with priority = 1

Description Michal Denar 2019-12-23 15:54:57 UTC
Hi,
if somebody more than one borrowe wants to pull one document, name of first borrower at cgi-bin/koha/circ/pendingreserves.pl is very often wrong = don't correspond to borrowwer that is on first position at holds que.
Comment 1 Lucy Vaux-Harvey 2020-02-03 11:48:31 UTC
This issue has been raised also by one of our supported libraries on 18.11.11.  When the item is scanned the hold is always assigned to the correct user (first on the hold priority list) but this is often not the user that was listed in the 'First patron' column in the holds to Pull report.
Comment 2 Michal Denar 2020-02-03 12:00:03 UTC
Hi Lucy,
yes, we need to see first on the hold priority list borrower name. Now is it more or less random name from priority list. It's confusing for librarians.
Comment 3 Jonathan Druart 2020-04-21 10:28:24 UTC
Is that the same problem as the one we fixed on the detail page recently (bug 19288)?
Comment 4 Ron Houk 2020-05-16 16:15:07 UTC
I can confirm this bug is happening to us.  We're on 19.05.09. To recreate the problem:

1. Place a hold on an item that is checked in.
2. Repeat a few more times with different patrons.
3. Go to the holds to pull list
4. The name that shows up for the item appears to be chosen randomly and often isn't the patron with priority 1.
Comment 5 Michal Denar 2020-05-16 20:41:56 UTC
+1
Comment 6 Jonathan Druart 2020-05-18 11:04:02 UTC
Created attachment 105011 [details] [review]
Bug 24301: Retrieve patron's info for hold with priority = 1

And not the first one in the table.

Can we always assume there is a priority=1?

Test plan:
Check an item out
Place some item level hold on the item
Change the some priotities of the hold
Go to the holds to pull list
Note that the patron who is the next in the list (piority=1) is listed
Comment 7 Ron Houk 2020-05-18 13:20:08 UTC
Hi,

I'd also like to note, that in my post above to recreate the problem, all of the holds I placed were bib level.
Comment 8 Michal Denar 2020-05-18 19:39:10 UTC
Created attachment 105045 [details] [review]
Bug 24301: Retrieve patron's info for hold with priority = 1

And not the first one in the table.

Can we always assume there is a priority=1?

Test plan:
Check an item out
Place some item level hold on the item
Change the some priotities of the hold
Go to the holds to pull list
Note that the patron who is the next in the list (piority=1) is listed

Signed-off-by: Michal Denar <black23@gmail.com>
Comment 9 Josef Moravec 2020-05-20 08:54:47 UTC
Created attachment 105139 [details] [review]
Bug 24301: Retrieve patron's info for hold with priority = 1

And not the first one in the table.

Can we always assume there is a priority=1?

Test plan:
Check an item out
Place some item level hold on the item
Change the some priotities of the hold
Go to the holds to pull list
Note that the patron who is the next in the list (piority=1) is listed

Signed-off-by: Michal Denar <black23@gmail.com>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Comment 10 Nick Clemens (kidclamp) 2020-05-20 16:25:25 UTC
This breaks the count of holds:
place 2 holds
"pull this many items" on report says 2
Apply patch
Now it says 1

The information will still be wrong if the holds queue is running, because it may select a hold that is not priority one when associating items

Additionally,  transfer limits and localholdspriority will affect which hold is pulled

This is similar to bug 19288
Comment 11 Jonathan Druart 2020-05-21 09:06:55 UTC
We need to focus on a rewrite of this controller. See bug 24488.

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