Bug 21415 - Set maxreserves by borrower category
Summary: Set maxreserves by borrower category
Status: RESOLVED DUPLICATE of bug 15524
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: 17.11
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-26 16:12 UTC by Andrew Fuerste-Henry
Modified: 2019-05-08 13:44 UTC (History)
4 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2018-09-26 16:12:12 UTC
Currently the system preference MaxReserves sets an overall limit for reserves across all item types for all borrower categories. It would be helpful to allow this limit to differ based on category code.

Be aware that there is already a bug asking for a the ability to differ MaxReserves by branch (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7030)
Comment 1 Katrin Fischer 2018-09-27 22:18:12 UTC
Hi Andrew,
there is already a seeting in the circulation matrix for this too - Holds allowed (count). Would this cover your use case?
Comment 2 Andrew Fuerste-Henry 2018-10-03 13:37:45 UTC
Hi Katrin! I should have spelled out the use case a bit more, as I don't believe it can be accomplished with the existing syspref and circ matrix. The library wants:

Patron Category A can place holds on:
Up to 20 books
Up to 20 dvds
Up to 20 cds
But not more than 20 items total across all three item types

Patron Category B can place holds on:
Up to 100 items total across all item types with no specific limits per item type

So we set the circ matrix as:
Patron A, Book, 20 holds
Patron A, DVD, 20 holds
Patron A, CD, 20 holds
Patron B, All item types, 100 holds

With that circ matrix setup, if we set MaxReserves to 20 then patron category A works as desired but category B is limited to 20 holds. If we set MaxReserves to 100, then category B works as desired but category A can have up to 60 holds total (20 of each item type).
Comment 3 Martha Fuerst 2018-10-03 18:41:06 UTC
We have a patron category called LIBRARYUSE that we use for programming and problems. Here's a case where we have run into the MaxReserves problem that Andrew has described.

In trying to gather previously "fast-add" items so that they can get fully cataloged, I can't put more than 20 of them on hold for our Technical Services LIBRARYUSE account, even though the circ matrix has a limit of 999 holds for LIBRARYUSE patrons across item types.

The same thing has the potential to be an issue for the LIBRARYUSE account we use to manage hotspots that have been deactivated or damaged so that we can corral them.
Comment 4 Katrin Fischer 2018-10-04 20:45:25 UTC
Hi Andrew and Martha, thx for explaining!
Comment 5 Fiona Borthwick 2019-05-08 13:36:42 UTC
Although the number of holds can be set in the circulation rules, this is based on a combination of patron category / item type. One of our customers would like to limit the overall number of holds a specific patron category can place to be 6 but the holds allowed in the circ rules means that they can reserve 6 books and 6 DVDs for example.

I definitely would like to see this enhancement as it would be used widely I believe in the public libraries especially.

Could be achieved by enhancing the maxreserves system preference but an alternative option would be to add an extra circulation policy - e.g. Default hold limit by patron category (similar to the Default loan limit by patron category that currently exists).
Comment 6 Andrew Fuerste-Henry 2019-05-08 13:39:10 UTC
Hi all! It looks like this bug should have been marked as a dupe of bug 15524, which was pushed to and released in 18.11.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15524

So, good news, we have this functionality now!
Comment 7 Andrew Fuerste-Henry 2019-05-08 13:44:39 UTC

*** This bug has been marked as a duplicate of bug 15524 ***