January 2026 - Koha-bugs - lists.koha-community.org

[Bug 40072] New: MARC21 Addition to relator terms in technical notice 2025-04-03
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40072 Bug ID: 40072 Summary: MARC21 Addition to relator terms in technical notice 2025-04-03 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 40953] New: marc_ordering_process.pl broken due to accidental newline
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40953 Bug ID: 40953 Summary: marc_ordering_process.pl broken due to accidental newline Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Executing marc_ordering_process.pl will fail to run with the following errors: /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 21: =head1: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 23: marc_ordering_process.pl: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 25: =head1: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 27: --confirm]: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 27: --verbose]: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 27: ./marc_ordering_process.pl: No such file or directory /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 29: or,: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 31: 0: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 33: =head1: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 35: This: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 36: If: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 38: =head1: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 40: =over: command not found /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 42: syntax error near unexpected token `newline' /usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 42: `=item B<-v|--verbose>' This is due to an inadvertent newline before the shebang of the script. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 39997] New: List of closed serials: reopening requires the syspref "RoutingSerials"
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39997 Bug ID: 39997 Summary: List of closed serials: reopening requires the syspref "RoutingSerials" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org On the list of closed serials, the action "reopen" is not displayed unless you have the syspref "RoutingSerials" active. >From koha-tmpl/intranet-tmpl/prog/en/modules/serials/serials-search.tt 139 [% IF ( routing && CAN_user_serials_routing ) %] 140 [% UNLESS ( subscription.cannotedit ) %] 141 142 <a 143 class="dropdown-item" 144 href="/cgi-bin/koha/serials/serials-search.pl?subscriptionid=[% subscription.subscriptionid | uri %]&amp ;op=reopen&routing=[% subscription.routing | uri %]&searched=1&title_filter=[% title_filter | uri %]&ISSN_filter=[% ISSN_filter | uri %]&EAN_fil ter=[% EAN_filter | uri %]&published_filter=[% publisher_filter | uri %]&bookseller_filter=[% bookseller_filter | uri %]&branch_filter=[% branch_filter | uri %]" 145 id="reopensub" 146 > 147 <i class="fa-solid fa-arrow-rotate-right"> Reopen</a 148 > 149 150 [% END %] 151 [% END # IF ( routing && CAN_user_serials_routing ) %] I have no clue why there is a restriction on routing and CAN_user_serials_routing. It breaks the ability to reopen serial from the list of closed serials if routing is not activated. To reproduce: 1 - Create a closed serial 2 - Disable the syspref "RoutingSerials" 3 - Go to cgi-bin/koha/serials/serials-search.pl and search for the closed serial ; click on the "closed" panel of the result -> on the actions button, there is no option to reopen 4 - Apply patch 5 - Repeat 3, there is now an option to reopen. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 39072] New: 24.11 - Item Search Shareable Link Adding Selections for Similar LOC Auth Values
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39072 Bug ID: 39072 Summary: 24.11 - Item Search Shareable Link Adding Selections for Similar LOC Auth Values Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: heather(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When executing an Item Search and copying the shareable link, the Item Search results for the shared link differ from the original results. Specifically, if a LOC authorized value is similar to another authorized value (ex: ADULT with description Adult and ADULTG with description Adult - Grab and Go), if an Item Search is executed for the ADULTG LOC, the shareable link somehow includes the ADULT LOC, causing the results to differ radically from the initial search. To Test: - Create LOC authorized values of ADULT with description "Adult" and ADULTG with description "Adult - Grab and Go" - Create an Item Search using the ADULTG LOC value - Click Copy shareable link and paste/go in new tab - See that the results of the copied link's Item Search differ widely from the original results - Click Edit search button and notice that the LOC authorized value of ADULT was added to the selected criteria for the search -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 40936] New: Add index for default patron sort order
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40936 Bug ID: 40936 Summary: Add index for default patron sort order Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The default sort order for Koha's patron search includes many columns, some of which are not indexed: [% CASE 'name-address' %] { "data":"me.surname:me.preferred_name:me.firstname:me.middle_name:me.othernames:me.street_number:me.address:me.address2:me.city:me.state:me.postal_code:me.country", Depending on the number of patrons in the database, and the specific configuration of the server, this can end up generating a query that creates a temp table in the hundreds of gigabytes of data or more. Not only does this risk crashing a database server with insufficient disk space, it's also incredibly slow. We've found a compound index prevents the issue and also makes the search much faster. InndoDB indexes have a fixed maximum length which is too small ( 3072 bytes ) to encompass the full data for all the fields we need to sort by. The following works well as a comprise to keep the index length within the maximum: CREATE INDEX idx_borrowers_sort_order ON borrowers ( surname(100), -- 400 preferred_name(80), -- 320 firstname(80), -- 320 middle_name(50), -- 200 othernames(50), -- 200 streetnumber(20), -- 80 address(100), -- 400 address2(75), -- 300 city(75), -- 300 state(40), -- 160 zipcode(20), -- 80 country(40) -- 160 ); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 40679] New: Existing holds toolbar goes wonky if you select 'del' from priority dropdown
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40679 Bug ID: 40679 Summary: Existing holds toolbar goes wonky if you select 'del' from priority dropdown Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Created attachment 185598 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=185598&action=e… Example of wonky toolbar To recreate: 1. Have some holds 2. Go to reserve/request.pl?biblionumber=x for your biblionumber 3. Change at least one hold priority to 'del' 4. Notice the toolbar above the table with Update Hold, Cancel selected, Cancellation reason now looks wonky. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 40861] New: Weird hash key $ord->{'count(*)'} in serials/acqui-search-result.pl
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40861 Bug ID: 40861 Summary: Weird hash key $ord->{'count(*)'} in serials/acqui-search-result.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org PLACK-INTRANET-ERROR.LOG PROD [2025/09/22 10:55:07] [WARN] Odd number of elements in anonymous hash at /usr/share/koha/serials/acqui-search-result.pl line 80. Associated code: push @{$loop_basket}, { basketno => $ord->{'basketno'}, total => $ord->{'count(*)'}, authorisedby => $ord->{'authorisedby'}, creationdate => output_pref( { str => $ord->{'creationdate'} } ), closedate => output_pref( { str => $ord->{'closedate'} } ), }; Note that SearchOrders does not create a key count(*) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 40759] New: Wrong date format in subscription brief history in OPAC
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40759 Bug ID: 40759 Summary: Wrong date format in subscription brief history in OPAC Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The brief history of a subscription shows the dates all in "database format" yyyy-mm-dd instead of using the formatting set in the DateFormat system preference. Dates on the subscription tab in the details page and full history are showing correctly. To test: * Add a subscription and receive 1-3 issues * Set the DateFormat system preference to format unlike yyyy-mm-dd * Go to the OPAC * Verify dates show corectly on the subscriptions tab itself * Click on more details * Verify dates how correctly in the full history * Verify the dates on the brief history are broken. /cgi-bin/koha/opac-serial-issues.pl? Example: Subscription information for ... The current subscription began on 2024-01-01 and is issued every month for 12 issues The first subscription was started on 2024-01-01 -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 38102] New: Checkout history in OPAC displaying more than 50 items
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38102 Bug ID: 38102 Summary: Checkout history in OPAC displaying more than 50 items Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the Checkout history tab of the OPAC, the 'Showing last 50 items/how all items' feature isn't working properly in 24.05. If I have a patron with over 50 items, all items are displaying on that tab when 'Showing last 50 items' should be active by default. If I click 'Show all items' to reload the page (which shows, as expected, all items), but then click 'Show last 50 items', I still see all items, not just the first 50. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 39896] New: Syspref AuthorLinkSortBy is not working for Unimarc or custom XSLT
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39896 Bug ID: 39896 Summary: Syspref AuthorLinkSortBy is not working for Unimarc or custom XSLT Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org The syspref AuthorLinkSortBy and AuthorLinkSortOrder depend on code in XSLT files. Currently, the code is only present in the default MARC21 files but it is not present in any UNIMARC files. Plus, if a library uses customs XSLT files (with syspref OPACXSLTDetailsDisplay, OPACXSLTResultsDisplay, XSLTDetailsDisplay, or XSLTResultsDisplay) they will not be able to use this functionality (unless they also updated their files but they have no way to know they need to do that). This is inevitable and is okay, but I think we should mention somewhere that these syspref depend on XSLT. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28