Bug 27086 - Add a both/most restrictive option for ReservesControlBranch
Summary: Add a both/most restrictive option for ReservesControlBranch
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-24 13:10 UTC by Nick Clemens (kidclamp)
Modified: 2022-10-25 18:25 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:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens (kidclamp) 2020-11-24 13:10:41 UTC
Some libraries would like to be able to check both a patron's branch, and an items branch when determining if an item can be held.

This is related to reciprocal borrowing, where one library  does not allow holds on dvds from other libraries, but other libraries do. 

They want the home library's rule to affect their patrons when placing holds on DVDs from other libraries

In this scenario we would check the rules based on both settings, using the most restrictive rule found
Comment 1 AspenCat Team 2021-02-23 21:27:53 UTC
Currently we are attempting to control differing holds rules amongst branch libraries with branch transfer limits.  This is an effective, but not efficient way to ensure that both the holds rules (whether it can be lent on one side, and whether or not it can be requested on the other) are followed when a patron places a hold.  By checking both the patron library and the home library of the item, then managing holds could be easily and accurately done in the circ rules. - Bob
Comment 2 AspenCat Team 2021-12-21 18:34:32 UTC
Here are scenarios that ByWater came up with that generally describe how this would work.

Scenario 1:
Libraries A, B, C, and D in a consortium
A, B, C all have DVDS and will share these items with other libraries
Library D doesn't have any DVDs and is not allowed to request other libraries DVDs.
Library A, B, C set their hold policy to any library can place a hold
With the proposed development, Library D sets a rule to say no holds allowed on DVDs (because they don't have them and patrons can't have anybody else's).
The new logic of checking item AND patron library would result in no hold being allowed by patrons from library D, but would be allowed by A,B, C

Scenario 2:
Libraries A, B, C, and D in a consortium
A, B, C all have DVDS and will share these items with other libraries
Library D has DVDs but does NOT allow others to request their DVDs and as a result their patrons are not allowed to request other libraries DVDs.
Library A, B, C set their hold policy to any library can place a hold
With the proposed development, Library D sets a hold policy rule that specifies 'HOME library '. The logic here is a bit murkier as the hold is allowed by A,B,C libraries but 'obliquely' points to patrons of D being the only ones allowed to place holds so the software needs to know that also means they are NOT allowed to place holds on others DVDs.
Note: this logic starts to include some assumptions and becomes a tad grey

Scenario 3:
Libraries A, B, C, D, and E are in a consortium
Libraries A,B, C and in a library group (a school district, or small town with 3 branches for example)
All the libraries have DVDs, but Group A,B,C only want to share their DVDs with themselves and not with D or E. A,B,C all share together, D and E share together, but D and E can't request A,B,C and A,B,C can't request D or E.
This is what branch transfer limits is effectively doing for you now - albeit in a difficult way to administer.