| Summary: | Allow to limit LocalHoldsPriority filling to a maximum number of holds in the queue | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Johanna Räisä <johanna.raisa> |
| Component: | Hold requests | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | anneli.osterman, gmcharlt, lisette, tomascohen |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Johanna Räisä
2025-10-24 10:16:17 UTC
So if there were - 100 holds on the record - the first 20 holds were all for branch A - the 21st was for branch B - Branch B items was checked in you'd want it to go to the first hold for branch A? and then the next time it was checked in would go to branch B as they're now the 20th hold? I can definitely see a use case. My biggest concern is probably tracking down why holds filled in a specific order as this would add a fresh layer of complexity there. > you'd want it to go to the first hold for branch A? Yes, because you cannot predict when the "better" branch is next in line after the limit. When using a limit, you just have to accept that sometimes this kind of thing happens. There might be a better branch right after the limit or there might not be. :) We have bibliographic records that have more than thousand holds and we do not want the last one in line (who maybe made their hold today) to get the hold before those who have waited for their turn for months. This kind of limit is a compromise which allows to reduce transfers but prevents situations where hold made today gets filled instead of thosw who have waited much longer. > and then the next time it was checked in would go to branch B as they're now the 20th hold? Yes, if the item was checkedin at the branch B. But if it is checkedin at branch A, it will stay there. > My biggest concern is probably tracking down why holds filled in a specific order as this would add a fresh layer of complexity there. The diff column in action_logs tells the priority before and after the hold was filled so if the priority was smaller than the limit, I think it is quite certain that it was prioritized. I do not see how this is different from the situation where LocalHoldsPriority system preference is used without the limit. :) |