https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42006
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from [email protected] --- 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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
