Bug 24301 - Holds to pull: Name of borrower on list
Summary: Holds to pull: Name of borrower on list
Status: RESOLVED DUPLICATE of bug 24488
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Jonathan Druart
QA Contact: Josef Moravec
URL:
Keywords:
Depends on:
Blocks: 24488
  Show dependency treegraph
 
Reported: 2019-12-23 15:54 UTC by Michal Denar
Modified: 2021-03-16 11:14 UTC (History)
10 users (show)

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


Attachments
Bug 24301: Retrieve patron's info for hold with priority = 1 (1.26 KB, patch)
2020-05-18 11:04 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 24301: Retrieve patron's info for hold with priority = 1 (1.31 KB, patch)
2020-05-18 19:39 UTC, Michal Denar
Details | Diff | Splinter Review
Bug 24301: Retrieve patron's info for hold with priority = 1 (1.37 KB, patch)
2020-05-20 08:54 UTC, Josef Moravec
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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 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 ***