Summary: | Holds to pull: Name of borrower on list | ||
---|---|---|---|
Product: | Koha | Reporter: | Michal Denar <black23> |
Component: | Hold requests | Assignee: | 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, 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: | ||
Circulation function: | |||
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
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. 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. Is that the same problem as the one we fixed on the detail page recently (bug 19288)? 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. +1 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 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. 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> 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> 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 |