Holds Rules Changes in 19.05

by Andrew Fuerste-Henry on Oct 30, 2019

While fixing bugs is objectively good, it sometimes creates its own transitional difficulties. In Bug 20837, the community found and corrected an important issue in holds policy. That correction is likely to cause some confusion.

Let me stress upfront that this is a nairly niche issue. Before I go into detail, know that this will only impact systems where all of the following are true:

• Koha is set up with more than one branch or library
• Holds Policy by Item Type rules are defined at the branch level
• The system preferences CircControl and ReservesControlBranch are set to two different values

If any one of those things is not true of your system, this blog post does not apply to you.

Some holds background

The basics of holds behavior is set in your circulation matrix, where we define how many holds a given type of patron can have per item type, whether or not they can place on-shelf holds, and so on.

This behavior is further defined in the Checkout, Hold, and Return policy sections below, which allows us to set overall hold limits either as a default or for specific patron categories.

And, finally, we can use the Holds Policy by Item Type section at the bottom of the Circulation and Fines Rules page to block whole item types from holds or control whether or not those item types are holdable between branches.

This web of rules is fairly complex to begin with, but remember that all of these rules -- just like your circulation rules -- can be set up differently for different branches. When that happens, Koha’s first step for any hold is to determine which set of rules to use.

CircControl and ReservesControlBranch

When an item is checked out, Koha uses the CircControl system preference to decide which branch’s circ rules to use. Generally this means either we use the rules for the branch the patron is from, the rules for the branch the item is from, or the rules for the branch the checkout is taking place at. Koha decides on a set of rules and uses them to decide whether or not the checkout is valid and how long it should be.

When a hold is placed, something similar happens. Koha uses the ReservesControlBranch system preference to decide whether to use the rules for the patron’s branch or the rules for item’s branch to determine whether or not the hold can be placed. Those same rules are checked again when the item is checked in, to determine whether or not the hold should be captured.

The problem

Last year, the community discovered that Koha was confusing these two system preferences and sometimes using CircControl to determine whether or not a hold could be placed. Specifically, Koha was using CircControl to pick which set of Holds Policy by Item Type rules to enforce, when it should have been using ReservesControlBranch.

As far as we can see, this has been the case for as long as Holds Policy by Item Type has existed. So the current behavior may be what longtime users expect, but it directly disagrees with the stated intent of the system preferences.

The solution

So, simply enough, Bug 20837 makes Koha correctly use ReservesControlBranch to determine which set of Holds Policy by Item Type rules to use in a multi-branch system. It makes Koha do what it says.

However, for some libraries this may mean a change to how your holds rules are enforced. Specifically, this will be multi-branch libraries where holds behavior differs between branches and CircControl and ReservesControlBranch are not set to the same thing. In these cases, there is no course of action that will preserve the exact behavior you’re used to. Instead, your best option is to look at your Holds Policy by Item Type setup carefully, think through how it will behave under your different ReservesControlBranch options, and decide what will work best for your patrons and staff. As ever, we’ll be happy to help you puzzle through your options and what they will mean.