Here's the situation: - Library has Branch A and Branch B - Library has ReservesControlBranch set to enforce based on item home library - Library has circ rule for all branches / all patrons / itype DVD that has max of 1 hold allowed - Patron is allowed to place 1 hold on a DVD from Branch A AND 1 hold on a DVD from Branch B This same logic applies to other parts of the circ and fine rules that are enforcing counts - holds per day, current checkouts allowed, total current checkouts allowed, maximum holds allowed, etc.
Clarifying a bit, we at ByWater have talked this one back and forth and are fairly uncertain about it. We agree that this behavior isn't really what one would logically assume based on how rules are presented. But is this behavior correct? Is it what libraries want? There may not be a universal agreement to be found.
I could come up with scenarios where a consortium using one instance of Koha may want this to behave as is, but speaking from the perspective of a system with multiple locations, it's not how we would interpret it "should" behave.
PCCLD is seeing this issue with a number of our users placing an excessive amount of holds and filling up the hold shelves. It is also an issue because we have several locations that are non-floating and we need the rules of the non-floating library followed over the rules of the patron's library.
If I understand correctly, to me the current behavour is correct for me. As the "All libraries" rule is not really over "All libraries" but "Fallback to be used when no rule for the specific library is set". And we explain this on the top of the page, so I think changing it would go against that. I think if we wanted a 'total hold allowed over all libraries for a specific itemtype' we'd need a new setting.
Created attachment 105356 [details] The different queries used to count holds vs issues You can see that for issues, if using a default rule we remove the branch restriction from the search. For reserves we don't make this distinction, this is the cause of the behaviour here that is not explained in the text on the page i.e. that reserves control changes the way holds are counted. Additionally, looking at the holds counting, the check for matching borrowers.branchcode is a tautology - find holds where the borrower's branchcode is the borrower's branchcode :-) We don't bother with this check in the issues
Hi, (In reply to Andrew Fuerste-Henry from comment #0) > This same logic applies to other parts of the circ and fine rules that are > enforcing counts - holds per day, current checkouts allowed, total current > checkouts allowed, maximum holds allowed, etc. The current checkouts allowed part seems to be actually due to a bug, please see bug 27834