Koha 22.05: New holds functionality

by Sara Brown on Nov 29, 2022

Post updated 12/5/22

22.05 brings some exciting changes to how holds work in Koha!

Changes to hold expiration dates

Bug 21729 When reverting a hold the expirationdate should be reset creates a new database column for patron-driven hold expiration dates to improve how reverted holds are handled. Prior to 22.05, a patron-requested expiration or ‘Hold not needed after’ date and the date on which a filled hold should be canceled were both stored in reserves.expirationdate. This meant that when a filled hold was reverted, Koha retained the expiration date from the filled hold since it had no original expiration date to which it could return.

For example: a hold was placed with a 'hold not needed after' date of 12/30/22. When it was filled, the expiration date was updated to 12/19/22 based on the library's ReservesMaxPickUpDelay setting.

If I revert the hold, Koha no longer has the original 'hold not needed' date, so the expiration date remains based on the ReservesMaxPickUpDelay-generated date.

22.05 creates a new database field called reserves.patron_expiration_date for patron-driven ‘hold not needed after’ dates so that reserves.expirationdate is only used for the expiration/cancellation date of a filled hold or for the amount of time set in DefaultHoldExpirationdate andDefaultHoldExpirationdatePeriod.

For instance, when this hold was placed, the patron indicated that they did not want it after 12/30/22. Both the expirationdate and patron_expiration_date columns are set with this value.

When the hold is filled, the expirationdate field updates with the last day the item will be held by the library, and the original 12/30/22 date is retained in patron_expiration_date:

If I then revert the hold's waiting status, Koha is able to reset the Expiration column with the patron-driven patron_expiration_date of 12/30/22 instead of retaining the expiration date generated when the hold was filled:

In this context, 'patron-generated expiration date' means either a 'Hold not needed after' date set by the patron in the OPAC or the 'Hold expires on date' set when placing a hold from the staff interface.

If a hold is placed without a patron-driven expiration date, reverted holds will be set with a blank expiration date. This will be the case even if the library is using DefaultHoldExpirationdate and DefaultHoldExpirationdatePeriod to cancel holds that are unfilled after X number of days/months/years.

Ability to make hold start and end dates required

Bug 30108 Allow making hold dates required creates a new system preference that gives libraries the option to make hold dates mandatory when patrons place holds via the OPAC.

The new OPACMandatoryHoldDates system preference can be set for the date a hold starts, the day it ends, or both. The options for this system preference are:

No hold dates
Both hold dates (a start date and an end date)
Hold end date
Hold start date (requires that AllowHoldDateInFuture and OPACAllowHoldDateInFuture are enabled)

With ‘Both hold dates’ selected, patrons will see this in the OPAC:

When libraries use this feature, the date patrons enter into the ‘Hold not needed after’ field will populate the new reserves.patron_expiration_date field discussed above.

New Expiration date column

Bug 27868 Adding the Expiration Date to the Holds Awaiting Pickup report makes it much easier for staff to see when a hold expires by adding a column to both tabs of the Holds Awaiting Pickup (waitingreserves.pl) table.

Previously, staff would have no way to know what day a hold actually expired until it moved to the ‘Holds waiting over X days’ tab, and even then wouldn’t be able to easily see what exact day the hold had actually expired. The new column makes the date readily available.

Prior to 22.05, Holds Awaiting Pickup looked like this:

I can see that the hold has been waiting since 9/14, and that it’s been there for over 14 days, but there’s no convenient way to see what day it actually expired. For libraries that don’t count closed days in the amount of time patrons have to pick up their items, adding 14 to the ‘Waiting since’ date won’t be accurate.

With 22.05, however, the table includes a new ‘Expiration date’ column on both tabs:

The ‘Expiration date’ column displays the date from reserves.expirationdate, which as discussed above is now separate from any patron-generated ‘hold not needed after’ date.

Holds queue updates

Bug 29760 Show patron category in Holds queue adds the patron category as a new column to Circulation–Holds queue. Like other columns in the table, libraries can configure in Administration–Table settings whether or not it shows by default. The table can be sorted by the new Patron category column by clicking on its header.

Bug 29346 Real-time holds queue update - Sponsored by Montgomery County Public Libraries
This enhancement adds a new system preference called RealTimeHoldsQueue: “[Enable/Disable] updating the holds queue in real time.” Setting to Enable will make the Holds queue update in realtime by using a background job. Updates to the queue are triggered by actions on a bib with holds including including items being checked in or out, items being added, or holds on the bib being canceled, modified, or filled. When one of those triggers occurs, Koha will use background jobs to update the queue for that specific bib only without rebuilding the entire queue. This means that the queue will not update for bibs that aren't triggered until one of those prompts occur, unless libraries are also running the build_holds_queue cron.

More 22.05:
Koha 22.05: Upgrades Hub