Bug 41095 - Allow to limit LocalHoldsPriority filling to a maximum number of holds in the queue
Summary: Allow to limit LocalHoldsPriority filling to a maximum number of holds in the...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-10-24 10:16 UTC by Johanna Räisä
Modified: 2025-11-12 14:02 UTC (History)
4 users (show)

See Also:
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johanna Räisä 2025-10-24 10:16:17 UTC
Libraries want to limit the LocalHoldsPriority filling to match only x number of holds in the queue. If there are 100 holds and they want to allow the LocalHoldsPriority system preference to check only 20 first holds for example.
Comment 1 Lisette Scheer 2025-10-24 13:56:40 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.
Comment 2 Anneli Österman 2025-11-12 14:02:47 UTC
> 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. :)