Overview

Acquisitions

Administration

General

Bug 37661 - Disable/Enable Bookings

This introduces a new system preference called EnableBooking: "[Enable]/[Disable] the booking module". If this is set to [Disable], Koha will automatically hide these bookings-related features:

Patron accounts - 'Bookings' tab:

Circulation - 'Bookings to collect' button:

Bib records - 'Bookable' tab:

Items tab in bib records - 'Bookable' option:

Note that the 'Bookable' option in Item types settings and the 'Bookings' column in the Item types table will still show when EnableBooking is set to [Disable].

Any ByWater Solutions partners who requested custom code to hide the features above prior to this upgrade are encouraged to submit a ticket requesting that we remove the code now that it is no longer needed.

Bug 35761 - Add an administration editor for FTP and SFTP servers, Bug 39190 - Rework new (S)FTP classes to be polymorphic classes, and Bug 38489 - EDI should be updated to use the new FTP/SFTP Servers management page

Server and credential information for FTP and SFTP connections, including EDI, are now all configured in Administration > File transports.

Access to this function requires the 'Manage file transports (manage_file_transports)' permission under the 'Manage Koha system settings (Administration panel) (parameters)' group.

Settings include the file path, login details, and upload/download directories:

Notes about each setting:

1. Name: This is the name that will be visible for selection in EDI accounts.
   
2. Transport: Defaults to SFTP, but FTP is also available.
   
3. Host: The FTP/SFTP address - for instance, ftp.brodart.com.
   
4. Port: Defaults to 22, which is the correct port for SFTP connections. This should be changed to 21 for FTP connections.
   
5. Passive mode: This doesn't apply to SFTP connections, and will default to On (Recommended)/Enabled (Recommended) for FTP connections. There is generally no need to adjust this.
   
6. Authentication mode: In nearly all cases, this will stay at the default of Password-based. If a ByWater Solutions partner has a vendor who recommends another option, please submit a ticket with us for discussion.
   
7. Key file: Leave blank unless otherwise discussed.
   
8. Remote download directory and Remote upload directory: These will be provided by your vendor.
   
9. Debug mode: This can be set to Disabled in most cases. It can be updated to Enabled if needed to troubleshoot connections.
   

When saving a new connection or editing an existing one, staff will be presented with a confirmation screen. For SFTP connections, saving will test the connection:

For FTP connections:

Libraries who access this feature will most commonly do so for EDI connections. Instead of configuring EDI FTP/SFTP settings in Acquisitions (or Administration) > EDI accounts, the actual server details will now be created and edited in File transports. 

Existing FTP/SFTP configurations for EDI set up in Acquisitions (or Administration) > EDI accounts should automatically move to File transports at the time of upgrade.

Since EDI connections will now be configured in File transports instead of in EDI accounts, libraries with multiple accounts for the same EDI vendor will no longer need to enter their credentials multiple times (as long as the credentials are the same between accounts for the same vendor, as is typical). Instead, staff will enter credentials once per vendor in File transports, and then select the proper transport for each vendor account in EDI accounts:

Note the handy link to Administration > File transports that makes it easy to view/edit connections!

The EDI accounts table will show whether a transport is selected, and if so, whether it has been used or has errors. If it has not yet been used:

If there are errors, or no file transport is selected:

Bug 37893 - Migrate some SIP configuration into the staff interface

Libraries' SIP details are now stored in the staff interface instead of in a SIPConfig.xml file. This means that libraries who are comfortable doing so can create and modify their own SIP configuration details in Administration > Self-service circulation (SIP2).

Existing SIP configurations will automatically migrate to Self-service circulation (SIP2) at upgrade.

Libraries who are not versed in SIP configuration are encouraged to continue submitting tickets to request ByWater Solutions' assistance with SIP setup and modification.

Bug 26993 - Allow StoreLastBorrower to retain a locally-defined number of previous borrowers

The StoreLastBorrower system preference now has an option for the number of borrowers to retain in the items_last_borrower table: "Store the last [#] patron(s) to return an item. This setting is independent of the opacreadinghistory and AnonymousPatron system preferences. Leave empty or set to 0 to disable the preference."

The number of borrowers indicated in the system preference will show in the 'Last returned by' entry on the Items tab:

Since the data is stored in its own table, increasing the number isn't retroactive. The higher number of borrowers will only be stored and thus displayed for returns moving forward.

If the number in StoreLastBorrower is reduced, any history beyond the new lower threshold will be automatically deleted. For instance, if it is set to 3 but then changed to 2, record of the oldest borrower's return will be deleted from items_last_borrower. If the number is increased back to 3, the oldest borrower's return won't re-appear since the data has been cleared.

Logs

Bug 9762 - Log circulation overrides

When circulation actions take place by override, there are now notes in logs explaining the policy that was overridden:

This can help managers troubleshoot circulation questions and track patterns in overrides. 

Bug 22632 - Add logging of merged patrons

Patron account mergers are now included in patron logs under the new Merge option under 'Actions'. This is part of standard patron modification logs, so systems with BorrowersLog set to "[Log] changes to patron records and patron restrictions" will automatically have access to this history moving forward.

Managers can find merge history for a specific patron from their 'Modification log' tab:

Note that the merged patron is identified by their card number.

Alternately, a patron's modification log can be filtered to only search for Merge in 'Actions':

Managers can also search for all patron account merges over a time period from Tools > Logs by selecting the Patrons in 'Modules' and Merge in 'Actions':

Since merged borrowers are considered deleted, managers can use the card number from this log to find details about the merged account in the deletedborrowers table. For instance, a simple report could be:

SELECT db.borrowernumber, db.surname, db.firstname, db.preferred_name, db.email, db.branchcode, db.dateenrolled 

FROM deletedborrowers db 

WHERE db.cardnumber = <<Deleted patron's card number>> 

Cataloging & catalog display

1. If staff opens an existing record for editing that has an invalid ISBN, the modal will only appear if they click into 020$a and then back out of the field.
2. The plugin only validates that the ISBN exists per the link above. It does not validate that the ISBN is correct for that title.
   
3. Staff are not prevented from saving a record with an invalid ISBN.
   
4. At this time, the plugin is only available for the basic catalog editor. It is not available in the advanced catalog editor or when adding a new record from the Acquisitions module.

1. Search results - StaffResultsPage and OPACResultsPage
   
2. Lists - StaffListPage and OPACListPage
   
3. Full bib display - StaffDetailPage and OPACDetailPage

If your library has been using custom code to display information in any of these locations, please submit a ticket for assistance removing the code.

Circulation

General

1. If the system preference is set to [Unless overridden by patron category, do] and either the item type or the patron category is set to No, Koha will not check for previous checkouts.
   
2. If the system preference is set to [Unless overridden by patron category, do not] and either the item type or the patron category is set to Yes, Koha will check for previous checkouts.
   

1. If a staff member tries to withdraw a blocked item from the 'Items' tab, the error message will be Cannot withdraw an item in transit or Cannot withdrawn checked out item.
   
2. From the full item editing screen, the error messages are Error saving item: In transit item cannot be withdrawn and Error saving item: Onloan item cannot be withdrawn.

1. AutomaticRenewalPeriodBase: "When renewing checkouts automatically, base the new due date on [the old due date of the checkout/the current date]."
2. ManualRenewalPeriodBase: "When renewing checkouts manually, base the new due date on [the old due date of the checkout/the current date]."

Holds

1. Expiration date from and Expiration date to: Holds expiring starting on a date ('from'), ending on a date ('to'), or use both for a range. Expiration dates include system-set (per DefaultHoldExpirationdate, if applicable) and patron-set expiration dates for unfilled holds, as well as filled hold expiration dates (as set by ReservesMaxPickUpDelay).
2. Libraries: Holds' pickup library. If left blank, Koha will look for holds set for pickup at all locations. Multiple selections are allowed.
3. Found status: This also allows multiple selections. The options are:
   
1. 'No status' excludes holds with any found status (in transit, in processing, and waiting).
2. 'In transit' means holds that have triggered to fill and are currently in transit to their pickup library.
3. 'In processing' means holds that need processing per HoldsNeedProcessingSIP.
4. 'Waiting' means holds that have been filled and are waiting on the holds shelf for patron pickup.
   'No status' is not the same as leaving this field blank. If this field is left blank, Koha will look for holds with any of the found statuses above and for those without a found status.
4. Suspended: Choose not suspended, suspended, or leave blank for both.
   
5. Suspended until from and Suspended until to: Date range for suspended holds.
6. Hold note: Searches the contents of the 'Notes' field if a note exists on the hold.

1. It will not prevent staff from updating pickup locations to disallowed libraries (see Bug 41882 - Batch hold modification tool updates pickup locations to disallowed libraries).
2. If a note is added to a hold that already had a note, the new note will replace, not be appended to, the prior one.
3. Patrons are not automatically notified about changes to pickup location, suspension status, or expiration date, so libraries should communicate that separately as needed. (Changes will be reflected in their OPAC/Aspen accounts, but no new notice is sent.)
   
4. At this time, changes using the batch hold modification tool aren't logged (see Bug 41883 - Modifications using batch hold modification tool aren't logged).

Bug 15516 - Allow to place a hold on first available item from a group of titles, Bug 40529 - Update how hold groups work, Bug 40517 - Allow grouping existing holds, Bug 40613 - Allow ungrouping holds, and Bug 40552 - Allow selecting all holds from a group

This new feature allows staff and patrons to place a hold on the first available item from a user-defined group. For instance, if a patron wants any format of a title for their book club, they could create a hold group with holds on the book on CD, standard print, and large print versions of the title. Or if they want a Canadian travel guide but don't have a preference between Lonely Planet, Fodor's, and Rick Steves, they could create a hold group from those three bibs. 

Note that this section will provide an overview of this feature, and that a forthcoming Help Center article will discuss it in more depth.

This feature is optional with the new system preference DisplayAddHoldGroups: "[Enable/Don’t enable] the ability to create hold groups which are fulfilled by one item." Set it to [Enable] to begin using hold groups.

In the database schema, hold groups are identified by the column hold_group_id in the hold_groups table. The hold_group_id column links to the reserves, old_reserves, and hold_groups_target_holds tables. 

Placing/modifying: staff interface

In the staff interface, hold groups can be created at the time holds are placed or after the fact from already-placed holds. 

To create hold groups directly from search results, the system preference DisplayMultiPlaceHold must be set to "[Enable] the ability to place holds on multiple bibliographic records from the search results". If your library allows item-level holds, DisplayMultiItemHolds must be set to "[Enable] the ability to place holds on different items at the same time in staff interface and OPAC."

To create a hold group at the time holds are placed, start the same way as placing 'normal' holds: search for titles, select the titles that should be grouped, and click 'Place hold'. On the 'Hold details' screen, check the 'Treat as hold group' box to make this a hold group (rather than separate holds on each of the selected bibs), then click 'Place holds':

On the bib's 'Holds' tab, holds that are part of a group will have a link to the hold group in the Details column:

Clicking on 'hold group' in the holds table brings up a modal with links to all of the bibs in the hold group:

 

In patron accounts, the Holds table now has a 'Hold group' column. The number in that column indicates holds that are part of a group. Holds with no value in that column are standard, non-grouped holds:

Hold groups can also be created from existing 'standard' holds. This is the same process staff will use to add a separate hold to an existing hold group. Starting at the patron's Holds tab, select the holds that should be grouped, then click 'Group selected':

Staff will see a confirmation screen, including a warning that already-grouped holds will be moved. Click 'Group' to proceed:

When holds grouped this way were already part of a group, this process technically creates an entirely new hold group rather than updating the existing one. This means that they will get a new hold_group_id. After grouping, the Holds table will be:

Placing: OPAC

For bib-level hold groups, patrons will select multiple titles from search results, and then click 'Place hold'. On the 'Placing a hold' screen, they will select the 'Treat as hold group' option:

In the OPAC, hold groups are noted with '(part of hold group)' under each title:

If patrons click on that text, the table will expand to show details of each group:

There is no way for patrons to group existing 'standard' holds from the OPAC. If a patron wishes to group holds that they have placed separately, they should either contact the library for assistance or cancel the existing holds and re-place them as a group.

Here is the corresponding staff interface view for that patron:

In the staff interface, clicking on the number in the 'Hold group' column will bring up a modal with options to select all holds in the group, or ungroup the holds:

Clicking 'Select group holds' from that modal will select all of the holds in that group, which is helpful if staff want to cancel, suspend, or unsuspend all holds in the group. Clicking 'Ungroup holds' will retain the holds, but will ungroup them so that they behave like 'standard' holds.

Note that hold groups can be bib-level, item-level, or a combination.

Filling group holds using the Holds queue
At this time, if multiple bibs/items from the same hold group are available, they will all show on the Holds queue (see Bug 42054 - Group holds and real time holds queue: multiple titles show at once). Also, note that the Holds queue does not have any indication that a title is part of a hold group (see Bug 41983 - Holds Queue should show when holds are part of a group).

Once an item that satisfies a group hold is checked in and fills the hold, other titles from the group will not trigger to fill the hold. However, libraries using the real-time holds queue should note that filling a group hold does not trigger a rebuild of the holds queue (see Bug 42055 - Real time holds queue doesn't rebuild when hold from group hold is filled).

Filling group holds using Holds to pull

As with the Holds queue, if multiple items are available to satisfy a hold group, those multiple items will show in Holds to pull at the same time. However, Holds to pull does have a '(part of a hold group)' link, so staff should check that for groups before pulling multiple titles for the same patron:

Once an item that satisfies a group is checked in and fills the hold, other titles from the group will disappear from Holds to pull and will not trigger to fill the hold if checked in. 

Checkouts before holds are filled

If a patron checks out an item that is part of a group hold before the hold has been filled, the other holds in the group will be automatically cancelled. This is the same behavior as non-group holds.

Working with filled group holds

When an item belonging to a group hold is checked in and fills the hold, note that the other bibs/items in the group will still show as on hold from the bib(s) and from patron’s account. However, as noted above, they will not trigger to fill the hold for that patron if checked in. (If other patrons are on the hold list, items will trigger to fill those other patrons' holds.) This is the expected behavior. Groups are retained even once a hold is filled in case, for instance, the filled hold has to be reverted - since the group still exists, the next available item will trigger without having to re-create the group.

Other holds from the group will automatically cancel once the filled hold is checked out.

Cancelling group holds

For unfilled group holds, cancelling an individual bib/item from the hold will not cancel the entire group. (If the group only has two bibs/items, the remaining hold will be automatically converted to a 'standard' hold.)

For filled holds that are part of a group, cancelling the waiting hold will not cancel the entire group - the other bibs/items in the group must be cancelled separately (See Bug 41849 - Cancelling filled hold from group does not cancel remaining pending holds from group or indicate that it's a hyperhold).

Groups in hold history

Holds that belonged to a group where a different item filled the hold will show in patrons' hold history as Cancelled once the filled item is checked out. At this time, patrons' 'Hold history' tabs in the staff interface and in the OPAC do not show any information about the hold having been part of a group (see Bug 41955 - OPAC: Patron hold history table should show hyperhold/hold group information and Bug 41954 - Staff interface: Patron hold history table should show hyperhold/hold group information).

Logs

In hold logs, group holds can be identified by their hold_group_id:

Note that this is in addition to the reserve_id, and that reserve_id is the Object. The hold_group_id isn't a searchable Object, but managers can search using 'hold_group_id' => [#] in Info:

For troubleshooting, note Bug 41878 - No logs for grouping existing holds or ungrouping a hyperhold.

For details on how group holds count toward hold limits, please see Bug 42255 - Grouped holds counted inconsistently for circ rules.

Bug 31698 - Add ability to move a hold to a new bibliographic record/item

This enhancement allows staff to move holds from one bib (or item) to another. If, for instance, a patron mistakenly placed a hold on the young readers' edition of a title but actually wanted the standard/original version, staff would have had to cancel the original hold on the young readers' bib and re-place it on the standard bib. Or if the only copy of a book on CD was too damaged to circulate (and wasn't going to be reordered), and staff wanted to move its holds to the Playaway version, they would need to cancel them (which could be done in bulk) and re-place all of them (which would have to be done one by one). With this enhancement, staff can now move one or more holds at a time instead of cancelling and re-placing!

This feature will be available to staff with the 'Move holds between items and records (alter_hold_targets)' permission (under 'Place and modify holds for patrons (reserveforothers)'). The 'Move selected' button will not show for staff without that permission.

Record-level holds

In this example, a patron mistakenly placed a hold on the standard print version of a title, but they actually want the large print version.

1. To move a bib or record-level hold, start by finding the bib number of the record that holds are moving to (that is, the target). This can be found in the bib's URL or at the top of the 'Items' tab.

2. Next, go to the 'Holds' tab of the bib that holds are moving away from, select the holds that need to move, then click 'Move selected' > 'Record level holds to a different record':

3. On the modal, paste the target bib number into the search box, then click 'Search':

4. Select the checkbox for 'Move all selected record level holds to this record' to enable the 'Move selected holds' button, then choose 'Move selected holds':

5. The success screen will have links to the bib the hold moved from and the bib that it moved to:

6. Staff should review the priority of moved holds and adjust accordingly. Moved holds will be placed at the bottom of the target's list, regardless of the date that holds were originally placed. This means that even if the moved holds were placed before existing holds on the target bib, the moved holds will have a lower priority (that is, they will be filled later even though they were placed earlier).

Item-level holds

In this example, a patron originally placed a hold on the 2026 copy of a travel guide. The 2026 copy is now lost, however, so they've asked that they hold be moved to the 2025 copy as the next most recent.

1. For items, start by identifying the barcode of the item that holds will be moving to (the target).

2. Next, go to the 'Holds' tab of the bib that holds are moving away from, select the holds that need to move, then 'Move selected' > 'Item level holds to a different item':

3. Paste in the barcode of the target item, then click 'Search'. Note that this example uses another item from the same bib, but this also works for moving holds to items on different bibs:

4. Check the box for 'Move all selected item level holds to this item' to enable the 'Move selected holds' button, then choose 'Move selected holds':

5. The success screen will have links to both bibs, similar to the success screen for bib-level moves. 

6. As with moved bib-level holds, note that moved item-level holds will be placed at the bottom of the target's list, regardless of the date that holds were originally placed. This means that even if the moved holds were placed before holds on the target bib, the moved holds will have a lower priority (that is, they will be filled later even though they were placed earlier). Staff will want to review the priority of moved holds and adjust accordingly.

Both of the examples above moved a single hold, but the same process works for moving multiple holds at once.

There are some situations where holds will not successfully move:

1. Holds won't move to a bib where holds aren't allowed per the circulation matrix ('Holds allowed (total)’'= 0) or 'Holds and bookings policies by item type', even if hold policies can be overridden and would successfully fill for the former. Here is the error message for both scenarios:
   
2. Holds won't move if the target record only allows holds from patrons matching the item's home library per 'Holds and bookings policies by item type'. For example, a patron from Main has a hold on bib A. Staff tries to move the hold to bib B, whose only item belongs to North, and North only allows holds from North patrons:
   
   

On the other hand, holds will move and be unfillable if a library's 'Holds and bookings policies by item type' allows holds by patrons from any library, but pickup at the item's home library only. The hold pickup location will not automatically update to reflect the rule, and there is no indication that the rule has been broken. This is the case even if Library transfer limits prevent the item from sending to the (new, not allowed) pickup location. For example, a patron is from West, and their original hold on bib A is to be picked up at West. Bib B belongs to East, which allows holds from West patrons but only for pickup at East. Staff move the hold to bib B. The move is successful, but since the pickup location remains West, it will never trigger to fill. For further discussion, see Bug 41879 - Holds that move to a new bib can be unfillable.

Note that there are gaps in how moved holds are logged. See Bug 41880 - Logs for moved holds don't indicate original bib number/item number for details and discussion.

Bug 40335 - Holds queue does not allow multiselect

Staff can now multi-select collection codes and shelving locations in the holds queue:

Keep in mind that like Advanced search, Koha addresses multiple selections within a facet as OR, and between facets as AND. So if Non-fiction and Rare books are selected for Collection and Adult non-fiction is selected for Shelving location, the results will be (ccode = non-fiction OR rare books) AND (loc=adult non-fiction). This includes selections for item type and library as well.

Searching

Some libraries have custom code that performs a similar function to this new built-in feature. If your library has custom code for that purpose, please open a support ticket so that we can remove it. 

Patrons

Automatically updating expiration dates will calculate from the day the change is made, not from the original day of registration or the existing expiration date.

Staff patrons

1. 'View checkout history (view_checkout_history)' - required to access patrons' 'Circulation history' tab
   
2. 'View holds history (view_holds_history)' - required to access patrons' 'Holds history' tab
   

Keep in mind that if patrons have their privacy set to 'Never', no data will show in those tabs even if Intranetreadinghistory and/or IntranetReadingHistoryHolds are set to [Allow] and staff members have the permissions above.

OPAC

Notices

The new Template Toolkit default versions will not replace existing notices at upgrade, so no existing customization will be lost unless your library copies the new default(s) to any of the notices above.