Unless someone can explain to me how it's not redundant, I think we should remove the maxreserves system preference. The maximum amount of holds (regardless of patron category and can be set in Circulation and fines rules > Default checkout, hold and return policy > Maximum total holds allowed (count).
For upgrades, if there is a value in maxreserves, it should be transferred to circulation_rules > max_holds. Not sure what it should do if there is already a value in max_holds... take the biggest? give a warning in the about page?
Kyle, Nick, Katrin, do you see any reasons to keep this syspref instead of using the "Maximum total holds allowed (count)" of the default circ rule?
(In reply to Jonathan Druart from comment #1)
> Kyle, Nick, Katrin, do you see any reasons to keep this syspref instead of
> using the "Maximum total holds allowed (count)" of the default circ rule?
I don't think it means the same thing under all circumstances, at least not currently
See bug 24868.
The maxreserves is an 'over all libraries' rule. The default on all libraries is (I think) just a fall back if there is no rule for a specific library.
At least it should be.
I've seen some discussion currently on several bugs and I think that things are confusing at the moment.
The page is labelled: Defining circulation and fine rules for all libraries
But that's not actually what it states below and how it does work. A rule that you set there will only apply, if there is no other more specific rule for the library. It's a 'default' (fallback) not an 'all libraries' page.
And I feel the fix is to change the labelling (and I also believe that in old versions it was labelled differently). And maybe have real global settings somewhere else, not necessarily in the system preferences.
So far the maxreserves syspref is only used in the controllers, it is not used in the "canbereserved*" subroutines. That means there is an obvious issue in the code.
My proposition is to:
1. Remove maxreserves
2. And instead use:
* max_holds from "Default checkout, hold and return policy" as maxreserves. Either for "default" (all libraries), or per library.
* or max_holds from "Default checkout, hold policy by patron category" if defined (default or library specific).
I believe it's not the same thing and we should really discuss how to interpet default vs. all libraries - I believe we cannot have both and should not mix them. There needs to be a clear definition to move forward and we should avoid changing behaviour unintentionally for libraries.
Say you have 3 libraries.
As they all have the same circulation conditions you only enter rules under "Default (all libraries)". Max holds is set to 5.
maxreserves is set to 10.
What I believe happens is that you can have only up to 10 holds (capped by maxreserves), but a max of 5 for each of the libraries.
If we remove maxreserves, we either remove the ability to inherit or remove the global capping.
(In reply to Katrin Fischer from comment #6)
> I believe it's not the same thing and we should really discuss how to
> interpet default vs. all libraries - I believe we cannot have both and
> should not mix them. There needs to be a clear definition to move forward
> and we should avoid changing behaviour unintentionally for libraries.
> Say you have 3 libraries.
> As they all have the same circulation conditions you only enter rules under
> "Default (all libraries)". Max holds is set to 5.
> maxreserves is set to 10.
> What I believe happens is that you can have only up to 10 holds (capped by
> maxreserves), but a max of 5 for each of the libraries.
> If we remove maxreserves, we either remove the ability to inherit or remove
> the global capping.
+1 to all of this. Katrin's example scenario correctly describes the current behavior (based on what they've got ReservesControl set to). There's nothing in the circ rules that can accomplish exactly what MaxReserves does and I hate to remove that functionality, even though it is confusing.
For what it's worth, I get libraries asking for more functionality along the lines of what MaxReserves does -- they want to be able to set global limits irrespective of library and define things like "Patrons in Category A can have a total of 50 holds across all branches." As Koha stands now, that sort of rule may or may not be possible based on ReservesControl and other rules.
I agree that it would be nice and improve transparency if the 'maxreserves' was not hiding in system preferences. It would be nice if we had something like a different configuration area for this visible under circulation rules somehow.
I'd also suggest getting rid of the 'all libraries' terminology in favor of something else. I believe we had some iterations of phrasing there already, but the current one does seem more confusing than ever.
Maybe something like:
Default fallback rules (for libraries)
What about moving the maxreserves pref under a "global" section of the circ rules page?
It would be displayed only if no library is selected.
I like moving this into circ rules somewhere rather than leaving in sysprefs. But that compounds both the naming issue that Katrin's raising *and* the control branch issue that Nick's raising. We don't exactly have a place in circ rules right now in which to define that sort of global rules, we only have default rules. Even if those defaults are our *only* rules, they'll still be enforced for each library individually.
If there is a discussion (maybe on the ML?) and we found a consensus, I am willing to implement it.
I think a new page would probably be best. Don't mix up things on the first page - it's already confusing.
Funnily, when adding bug 25688 for the terminology issue, I found another really old bug about this problem:
Bug 8371 - Add global level issuing rules (number of checkouts over all libraries, etc.)
I have been testing out changes to reservations / holds settings in our test server and the maxreserves setting is not working for us in the way Katrin reports.
We are on 20.11.04 and all our 6 libraries have the same circulation policies so I have set Total reservations allowed (under Default issue, reserve & return policy by category) to 5 for all user categories permitted to place reservations. Our maxreserves is set to 10. We do not (currently) allow OPAC item level reservations so I am not yet thinking about how the Reservations allowed (under Defining circulation & fine rules for all libraries) will work for us. (Like, how would Koha know the counts of reservations by item type in our title-level reservation environment, so it could limit reservations using this very granular functionality?). I have set Reservations allowed to 10 which I think effectively takes ‘reservations by item type/user category’ out of the equation).
But I have not been able to place more than 5 reservation using either the OPAC or the Koha intranet. I tried this with ReservesControlBranch set to either of Item’s home library or user’s home library, but I have not been able to achieve what I thought was how the functionality works- say 5 reservations for items at library A, 3 reservations at library B and 2 at Library C.
We are trying to unravel how the counts are set so we can set the counts to be how we want them to be. Being able to advise users that ‘Patrons in Category A can have a total of 50 holds across all branches’ (or whatever) would be great.
Lets axe this syspref :-D
It is exactly the same thing as if we set a global max_holds for all libraries, all itypes and all categories. If it is not the same, then we need to fix it. This is probably due to the lack of flexibility on the circ rules UI.
(In reply to Tomás Cohen Arazi from comment #14)
> Lets axe this syspref :-D
> It is exactly the same thing as if we set a global max_holds for all
> libraries, all itypes and all categories. If it is not the same, then we
> need to fix it. This is probably due to the lack of flexibility on the circ
> rules UI.
It should intentionally not be the same. The all libraries is mislabelled and we need to fix it. It should be a fallback if no other rules are set for a library, not an "overall libraries". The GUI is bad.