Bug 24868 - When CircControl or ReservesControlBranch are enforced based on item, location limits are enforced per library
Summary: When CircControl or ReservesControlBranch are enforced based on item, locatio...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Nick Clemens
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-13 17:40 UTC by Andrew Fuerste-Henry
Modified: 2021-03-02 14:13 UTC (History)
11 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
The different queries used to count holds vs issues (4.52 KB, text/plain)
2020-05-26 11:37 UTC, Nick Clemens
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2020-03-13 17:40:34 UTC
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.
Comment 1 Andrew Fuerste-Henry 2020-03-13 17:54:23 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.
Comment 2 Martha Fuerst 2020-03-25 13:35:51 UTC
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.
Comment 3 Daniel Gaghan 2020-05-11 15:27:30 UTC
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.
Comment 4 Katrin Fischer 2020-05-23 11:31:09 UTC
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.
Comment 5 Nick Clemens 2020-05-26 11:37:24 UTC
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
Comment 6 Joonas Kylmälä 2021-03-02 14:13:21 UTC
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