[Bug 42006] New: Hold group/hyperholds appear on the holds queue multiple times
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42006 Bug ID: 42006 Summary: Hold group/hyperholds appear on the holds queue multiple times Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: jrobb@sekls.org QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, lisette@bywatersolutions.com, tomascohen@gmail.com When placing a hold for a group of records using the hold group (hyperhold) feature, the holds queue appears to generate a hold for each record in the group. This can lead to situations where the hold gets filled by a nonlocal copy when a local copy is available. To replicate in ktd: 1. Enable RealTimeHoldsQueue and DisplayAddHoldGroups 2. Search for Birds 3. Tick the boxes for the first two records 4. Click Place hold 5. Search for Henry Acevedo 6. Set the pickup location to Midway 7. Tick the 'Treat as hold group' box 8. Click Place holds 9. Run the holds queue for Midway, the hold appears there 10. Run the holds queue for Centerville, the hold also appears there 11. Run the queue for All libraries, two rows are listed for the single hold needing filled, one for each record involved This hold should only be on the Midway record at this point as the item location matches the hold pickup location. This also seems to make multiple holds appear on the same library's queue for a single hold group. If you select all three titles in the Birds search for a grouped hold with a pickup of Midway, you'll see two titles listed on the Midway queue for the one hold needing filled. In practice, this will lead to staff pulling multiple copies of a thing then being frustrated when only one fills the hold and the others need reshelved. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42006 trevor.diamond@mainlib.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trevor.diamond@mainlib.org --- Comment #1 from trevor.diamond@mainlib.org --- Part of this is "intended behavior", since the point of the hyperhold is to grab whichever item can be obtained the fasted. So each individual record level request would be placed on a library's hold queue. Your point is valid, though! You could have a request with multiple editions at the same location and if you pulled all of them, it would lead to frustration. The original mental scenario involved a more dynamic queue (where as you mark an item as located, all the other relevant holds would be removed automatically). There's another bug about local pickup availability influencing how the queue and item filling behaves while the request is still new. It will need to take into account holds groups. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 The smartest way to process all these would be "which individual requests have available items...and of this subset, are any available at the pickup location" and then only place one (random) request of the filtered list on the queue. But you'd need to make sure this logic doesn't iterate too often so the system isn't putting too much resources into it? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42006 carthur@slolibrary.org <carthur@slolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carthur@slolibrary.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42006 Michelle Spinney <mspinney@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mspinney@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42006 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert@arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42006 Chip Halvorsen <Chip.Halvorsen@WestlakeLibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Chip.Halvorsen@WestlakeLibr | |ary.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42006 Catrina Berka <catrina@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |catrina@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org