Every six months, the Koha community does a major release, such as Koha 24.05. Major releases are when most new features and enhancements are added to Koha and made available to libraries.
In this blog post, Alex Buckley, Catalyst Rōpū kohinga developer, has highlighted 20 enhancements available in Koha 24.05.
Check out the full Koha 24.05 release notes.(external link)
If you would like to try out the new version as you read along, head to the demo of Koha(external link).
20 new enhancements in Koha 24.05
Cataloguing
1. Add the ability to lock records to prevent modification through the Koha staff interface [31791(external link)]
The cataloguing enhancement enables libraries to lock bibliographic records to protect records from being edited in the Koha staff interface. You can think of it as making the record read-only.
Currently, a record can only be locked if it meets two criteria:
-
The record was created via the Koha API. An API endpoint allows an external system to run an action within Koha. Libraries may use an external cataloguing system to push records to Koha via an API. The library could lock those records, so any changes must be made back in the external cataloguing system, rather than in Koha.
-
The library has defined a record source (a new setting) in the Koha Administration module. The record source needs to be passed from the external cataloguing system through the API when it pushes a new record to Koha. Libraries could define a rule that locks records with a specific record source, so they can’t be modified through the Koha staff interface.
A follow-up enhancement is coming (36372(external link)) that will enable permitted users to lock any records within Koha, regardless of their source.
2. Add optional statuses to catalog concerns [35628(external link)], Add resolution types to catalog concerns [32435(external link)] and Add the ability to assign tickets to librarians for catalog concerns [35657(external link)]
In Koha 23.05 a new feature was added to Koha for users to report concerns about bibliographic records. The community has built heavily on that in Koha 24.05, essentially, enabling a ticket management system!
When a concern is reported, library staff can:
-
assign a custom status to it – based on the ‘TICKET_STATUS’ authorised value category
-
assign the concern to a library staff patron to resolve it
-
set a custom resolution status – based on the ‘TICKET_RESOLUTION’ authorised value category.
Circulation
1. Place holds for patrons on accepted purchase suggestions [27595(external link)]
A time-saving enhancement for librarians, especially, if the library receives a high volume of purchase suggestions from patrons.
Libraries can enable the new PlaceHoldsOnOrdersFromSuggestions system preference. When enabled, and the library orders an item from a purchase suggestion, a hold will automatically be placed for the suggester.
No more manual placing reserves for patrons who suggest items!
2. Automate resolution of return claim when checking in an item [27753(external link)]
Do you ever find items with return claims suddenly turn up on the circulation desk, and then you have to figure out how to handle the claim? If so, this enhancement is for you.
It adds two new system preferences to Koha, enabling libraries to automatically resolve return claims on items when they are issued (using the new AutoClaimReturnStatusOnCheckin system preference) and returned (the new AutoClaimReturnStatusOnCheckout system preference).
Normally, when manually resolving a return claim, it’s required to give a reason for resolving it. For example, the item was found on the library shelves.
Using these two system preferences, you can set a default resolution for those return claims using one of the following options:
-
‘Found in library’
-
‘Returned by patron.’
Both system preferences are empty by default, so nothing will be automatically marked as resolved unless configured.
3. Overnight checkouts taking into account opening and closing hours [6796(external link)]
Auckland University of Technology (AUT)(external link) sponsored this enhancement.
Academic libraries often have high circulating items that need to be kept on the move – for example, reference materials required by many students for upcoming assessments. These items are usually treated by the library as an hourly loan.
Previously, if an item had a 3-hour loan period, issuing it to a student at 4 pm would make it due at 7 pm, even though the library closed at 5 pm. This confused students, as well as caused many unintentional overdue items.
With this enhancement, it is now possible for libraries to:
-
Define opening and closing hours for each of their library branches. This is configurable by librarians on the Libraries page of the Administration module.
-
Choose how loan periods should be affected by opening and closing hours using the new system preference ConsiderLibraryHoursInCirculation.
The system preference has three options:
- “Do not consider the library’s opening hours” – Continue the status quo behaviour of setting the item due date, ignoring library hours.
- “Shorten the loan period and set the checkout to be due at the library’s close time.”
- “Extend the loan period and set the checkout to be due at the library’s open time.”
4. Item record needs to keep local use count [16122(external link)]
An architectural enhancement that will be helpful for libraries using Koha reports to track local use circulation statistics of items.
A local use circulation is when an item is only used on-site (the item does not leave the library). Reference materials are an example of local use circulations. Such items would be things like reference materials.
This enhancement stores and increments a local use count for each item, standardising a database table that already stores issue and renewal counts. Therefore, circulation count statistics will be easier to access in SQL reports.
5. Place multiple item-level holds at once for the same record [15565(external link)]
When the new DisplayMultiItemHolds system preference is enabled, patrons can place multiple item-level holds on a single title via both the OPAC and staff interface.
Patrons can use the checkboxes and get in the holds queue for multiple items under one record. This would be especially useful for journal titles with many serial issues attached.
Searching
1. Add geo-search [31652(external link)]
If your library uses Elasticsearch(external link) for its search engine, this could be a helpful enhancement for you.
The search enhancement adds two new index mappings to Elasticsearch. Latitude and longitude can now be stored in the 034$s and 034$t subfields, respectively, of a bibliographic MARC record.
Why might this be helpful? Some records, like cartographic and mapping materials, are associated with a location. While libraries may have been able to store this information in a random notes field previously, it wasn’t very useful. With these new index mappings, the location data can be stored in a searchable way.
The Koha community are still working on a built-in interface for searching these location values. In the meantime, libraries can install the HKS3GeoSearch plugin(external link) to search and see the stored location on a map on their Koha website.
2. Add an option to NOT redirect to result when a search returns only one record [35728(external link)]
Educational Services Australia (SCIS) sponsored this enhancement.
Using the new ‘RedirectToSoleResult’ system preference, you can now control if Koha will redirect straight to a record detail page if that record is the only result for a search.
The ‘RedirectToSoleResult’ system preference controls both the OPAC and staff interface behaviour and defaults to the existing redirect behaviour.
Fines and fees
1. Automatically change lost status when an item is paid for [22740(external link)]
Here’s another great time-saving enhancement in Koha. This adds two new system preferences UpdateItemLostStatusWhenWriteOff and UpdateItemLostStatusWhenPaid.
These preferences enable libraries to configure globally which lost status an item should be automatically changed to when the item’s replacement fine is written off or paid in full.
The statuses are defined in the LOST authorised value category(external link) in the Koha Administration module.
One less task for librarians to have to follow up on!
MARC data support
1. Add a field to auth_header to record the main heading as a text string [30047(external link)]
A database architecture change, but it has a real-world impact on library reporting!
Until now, the ExtractValue() SQL function was required to query the main heading of authority records using SQL reports. For example:
ExtractValue(`marcxml`,'//datafield[@tag="100"]/*')
The ExtractValue() function was a slow, and resource-intensive process especially if a catalogue had many authority records. The function is essentially looking for a needle-in-a-haystack – it parses the entire record to fetch one MARC field.
Now the main heading for every authority record is stored in a standalone database column. Therefore, it is immensely faster to fetch headings using an SQL report.
Note: Currently, this enhancement will only take effect on new authority records, catalogued after the upgrade to Koha 24.05. It will not update existing authority records to use this new column.
2. Deduping authorities script (dedup_authorities.pl) [13706(external link)]
The addition of a new script that can be configured to run as a cronjob (automatic scheduled job). The script looks for duplicate authority records to remove, making it easier to clean up your catalogue.
Libraries can choose the criteria to determine which duplicate authority records should be removed. The options are:
-
Date: Keep the most recent of the duplicated authority records
-
Used: Keep the authority record which is linked to the most bibliographic records
-
PPN: For UNIMARC only - keep the duplicated authority if it has a PPN (based on the 009 field).
In true Koha fashion, the behaviour of the script is flexible to each library’s needs. Libraries can choose to only check for duplicates of specified authority types. If they want more control, they can additionally use SQL to limit the search using any field in the auth_header database table.
For example, using --where="datecreated > ‘2023-12-31’" will only search for duplicates created in the 2024 calendar year.
OPAC
1. Display author information for researchers [29948(external link)]
Libraries now have more granular control over how author information is displayed to OPAC users.
The flexibility in Koha with author display information will be helpful for academic libraries to display all author data in one place for assessment citations.
Using the new OPACAuthorIdentifiersAndInformation system preference, - it’s possible to collate any or all authority MARC fields to describe more about authors:
-
Activity (372$a$s$t)
-
Address (371$a$b$d$e)
-
Associated group (373$a$s$u$v$0)
-
Electronic mail address (371$m)
-
Identifiers (024$2$a)
-
Occupation (374$a$s$t$u$v$0)
-
Place of birth (370$a)
-
Place of death (370$b)
-
URI (371$u)
When viewing a record on the OPAC, if it links to an authority record, Koha will display the authority MARC fields selected in OPACAuthorIdentifiersAndInformation under a new ‘Author information’ tab.
The same author information will also be collated and displayed on the authority record detail page on the OPAC.
2. Self checkout batch mode [32256(external link)]
Koha-US sponsored this enhancement.
Many libraries use the Koha self checkout module – a high-trust method enabling library users to check out items to themselves.
This enhancement facilitates users to scan barcodes and check out items in a batch - much faster than scanning and issuing one-by-one!
To use the self checkout batch mode, you must enable the self checkout module – by setting the ‘WebBasedSelfCheck’ system preference to ‘Enable’.
Then you need to enable batch checkouts:
-
Enable the ‘BatchCheckouts’ system preference.
-
Choose which patron categories can use the batch self checkout in the ‘SCOBatchCheckoutsValidCategories’ system preference.
Permitted OPAC users will then see a larger barcode area on the self checkout module where they can input or scan many barcodes. When submitted, Koha will issue the items one-by-one.
Patrons
1. Add API endpoint to fetch patron’s previous holds [35353(external link)]
This enhancement adds a new API endpoint to Koha. An API endpoint allows an external system to run an action within Koha. This new endpoint provides the ability to fetch the previous holds placed by patrons. This improves existing Koha API behaviour which was only able to fetch a patron’s current holds.
This is helpful for libraries that use an alternative search platform for their users rather than the Koha OPAC, such as a VuFind discovery layer.
2. Copy permissions from one user to another [30623(external link)]
If you have to administer lots of Koha staff patron accounts then you’ll appreciate this enhancement.
Using the new ‘Copy settings’ and ‘Paste settings’ on a patron permission page, you can copy the permissions from one patron account and quickly paste them to multiple accounts.
Reports
1. Multiple selections for parameters used in the IN function [35746(external link)] and Runtime parameter modal should provide the option of “:all” [35856(external link)]
Libraries can choose values from pre-populated dropdowns when running reports using runtime parameters in the WHERE SQL clause. Libraries could then select an option from the dropdown to limit report results by that option.
For example: WHERE branchcode IN <<Select branches|branches>> would load a dropdown menu of library branches.
These enhancements build on this feature, making it possible to now choose multiple options from the dropdown. This is possible by adding :in to the end of your runtime parameter:
For example, WHERE branchcode IN <<Select branches|branches:in>> will load a multiple-select box:
Additionally, you could add :all to the end of your runtime parameter to indicate that someone could choose all dropdown options when running the report.
For example, WHERE branchcode IN <<Select branches|branches:all>> loads a dropdown with an ‘All’ option:
Acquisitions
1. Modify the sentence above the order table in English 1-page order PDF [33393(external link)]
Pymble Ladies College sponsored this enhancement.
Libraries can print basket groups into a one-page (English), two-page (English and German) and three-page (English, German and French) PDF file. They can then send this to a vendor to order new items.
The type of document is configured in the ‘OrderPdfFormat’ system preference.
Pymble Ladies College sponsored the original development of the 1-page English PDF file and has enhanced this to enable the customisation of some of the text to better reflect library workflows.
Using the new system preference ‘1PageOrderPDFText’ libraries can save custom wording that is printed above the order table in the 1-page English document.
Notices
1. Send notices using several email addresses [12802(external link)]
Koha patrons can have multiple email addresses stored. Previously libraries couldn’t specify which email address Koha notices should be sent to, or if notices could be sent to multiple addresses for each recipient.
Both options are now possible with this enhancement.
Using the new system preference ‘EmailFieldPrimary’ librarians can choose a singular patron email field to receive notices, for example, ‘Primary email’.
If the library sets ‘EmailFieldPrimary’ to ‘Selected addresses’ then Koha checks another system preference ‘EmailFieldSelection’. ‘EmailFieldSelection’ enables libraries to check multiple email address fields to receive notices. For example, both the primary and secondary email addresses for a patron could be selected to receive notices.
This can be especially helpful for young library members, ensuring both they and their parents receive notices about overdue items and holds.
2. Customise the format of notices when they are printed [33478(external link)]
Colorado Library Consortium sponsored this enhancement.
With this enhancement, you can customise how notices and slips look when printed by configuring CSS (style rules) for each print notice. Styles you can add include:
-
font sizes,
-
margins,
-
letterheads
-
and logos.
When editing any notice or slip (in the ‘Notices and slips’ tool) you’ll notice a ‘Format’ expandable tab at the bottom of the page.
To get you started, the Format tab has ‘Insert selectors to apply styles to’ helper links. Clicking on each of them will load the appropriate CSS selectors for headings, tables, or all text.
When you print the notice the styles will be applied.
Read more about the 9 new features, 239 enhancements and 529 bug and security fixes of the 24.05 Release on the Koha Community website(external link).
Catalyst Rōpū kohinga
If you have any questions or comments about this blog post or would like some support with your Koha instance, you are welcome to contact us.