https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41095 Anneli Österman <anneli.osterman@koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anneli.osterman@koha-suomi. | |fi --- Comment #2 from Anneli Österman <anneli.osterman@koha-suomi.fi> ---

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. :) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.