| Summary: | When CircControl or ReservesControlBranch are enforced based on item, location limits are enforced per library | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Andrew Fuerste-Henry <andrew> |
| Component: | Circulation | Assignee: | Nick Clemens (kidclamp) <nick> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | daniel.gaghan, gmcharlt, jonathan.druart, joonas.kylmala, kyle.m.hall, kyle, martin.renvoize, mfuerst, nick, tomascohen |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25643 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27834 |
||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Attachments: | The different queries used to count holds vs issues | ||
|
Description
Andrew Fuerste-Henry
2020-03-13 17:40:34 UTC
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 |