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.
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. :)