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

[Bug 41962] New: Add comment to SearchAuthorities about unused params, update POD accordingly
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41962 Bug ID: 41962 Summary: Add comment to SearchAuthorities about unused params, update POD accordingly Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl 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 9

[Bug 41944] New: Error 500 on non-existent ILL request (op=illview)
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41944 Bug ID: 41944 Summary: Error 500 on non-existent ILL request (op=illview) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com It should be returning the usual 404, but is no checking it and throwing template errors instead. To reproduce: 1. Have KTD launched with an ILL backend loaded: $ ktd --proxy --name rapido --single-plugin ~/git/koha-plugins/rapido-ill up -d $ ktd --shell k$ cd /kohadevbox/plugins/rapido-ill/scripts k$ perl bootstrap_rapido_testing.pl k$ restart_all 2. Log into the instance at `http://rapido-admin.localhost` 3. Point your browser to a [non-existent ILL request](http://rapido-intra.localhost/cgi-bin/koha/ill/ill-requests.pl?op=illview&illrequest_id=1000) => FAIL: Boo, template errors and stacktrace Note: In production, the you get a 500 error and the template errors show up in the logs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 41942] New: Hiding primary contact method hides lang with PatronSelfModificationBorrowerUnwantedField
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41942 Bug ID: 41942 Summary: Hiding primary contact method hides lang with PatronSelfModificationBorrowerUnwantedField Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Bug 34438 added lang in opac registration/modification form. But it is linked to primary contact method hidden or not. Looks like this is not on purpose. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 41934] New: Empty table header in course reserves table causes accessibility error
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41934 Bug ID: 41934 Summary: Empty table header in course reserves table causes accessibility error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: accessibility Severity: normal Priority: P5 - low Component: Accessibility Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org The responsive control column in the OPAC course reserves table contains an empty <th> element. This results in an empty table header and an empty aria-label, which is flagged as an accessibility error by automated testing tools. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 41933] New: Course reserves OPAC DataTables search field missing accessible label
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41933 Bug ID: 41933 Summary: Course reserves OPAC DataTables search field missing accessible label Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Accessibility Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org The search input generated for the course reserves table in the OPAC uses language.search: "_INPUT_", which produces an empty <label> element. This results in the search field lacking an accessible name for screen reader users and fails accessibility requirements. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 41884] New: Job report for batch item modifications that fail due to PreventWithdrawingItemsStatus has no details on failed items
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41884 Bug ID: 41884 Summary: Job report for batch item modifications that fail due to PreventWithdrawingItemsStatus has no details on failed items Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If PreventWithdrawingItemsStatus is set to prevent withdrawal of in transit and/or checked out items, and some items in a batch item modification fail because they're either in transit or checked out, the job details screen does not provide any information about which items failed or the reason for the failure. At a minimum, it should show the item number or barcode so that libraries know which items need attention. When individual items can't be withdrawn due to the system preference, the error message notes the reason, so ideally that would be included in the job report too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 41883] New: Modifications using batch hold modification tool aren't logged
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41883 Bug ID: 41883 Summary: Modifications using batch hold modification tool aren't logged Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Changes made via the batch hold modification tool that are logged when made to holds individually from the bib are not logged when using the tool. To replicate: -Place a hold -Run the Holds log using the hold's reserve_id. There will be a single entry for the hold's creation. -Find the hold using the batch hold modification tool, and update its pickup location -Run the Holds log for that hold, and note that no entry has been generated for the changed pickup location -From the bib's Holds tab, update the same hold's pickup location -Run the Holds log again for that hold, and note that an entry was generated for the pickup location change when it was updated from the bib The same issue applies for updating expiration dates and for suspending/unsuspending, all of which do generate log entries when performed on individual holds from the bib. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 41882] New: Batch hold modification tool updates pickup locations to disallowed libraries
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41882 Bug ID: 41882 Summary: Batch hold modification tool updates pickup locations to disallowed libraries Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a library's 'Holds and bookings policies by item type' is set to only allow pickup at an item's home library, the batch hold modification tool can still be used to update a hold's pickup location to other libraries such that the hold will never trigger to fill. To replicate: -Set ReservesControlBranch to 'item's home library' -Set Main library's 'Holds and bookings policies by item type' so that PASS items can only be picked up at Main -Place a hold on a bib whose only item is a PASS belonging to Main -Use the Batch hold modification tool to identify the hold you just placed -Update the pickup location to North. Note that the update is successful, and there's no indication that the pickup location is now a problem. -Check in Main's PASS, and note that the hold doesn't trigger to fill The batch update shouldn't process for holds where the change will make the hold unfillable per a library's 'Holds and bookings policies by item type'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 41880] New: Logs for moved holds don't indicate original bib number/item number
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41880 Bug ID: 41880 Summary: Logs for moved holds don't indicate original bib number/item number Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com If a hold is moved from bib A to bib B (or from item A to item B), and no change was made to the hold before the move, there is no way to identify the bib or item number of the original hold. To replicate: -Place a hold on bib A (or item A) -View it in Tools > Logs using the reserve_id. As is standard, no details other than the reserve_id show in the Info column. -Move the hold to bib B (or item B) -Run the holds log again for the reserve_id. Note that an entry is generated for the move, but only the bib number (or item number) it was *moved to* shows. There is no way to know what bib or item the hold was moved *from*. If a change is made to a hold before it's moved, staff will be able to see the original bib number/item number in logs. But there are likely to be many cases where the first change made to a hold is moving it to a new bib/item, which means that the original bib number/item number will be untraceable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 41878] New: No logs for grouping existing holds or ungrouping a hyperhold
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41878 Bug ID: 41878 Summary: No logs for grouping existing holds or ungrouping a hyperhold Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When grouping existing holds into a hyperhold or when ungrouping a hyperhold, the actions aren't logged, which is going to make troubleshooting extremely difficult (or impossible, depending on the issue). Hold groups are assigned an ID which shows in logs as hold_group_id when other changes are made to the hold, but grouping/ungrouping itself isn't logged. To replicate: -Place 2 or more holds for a patron (regular, not grouped) -Find the reserve_id for one of the holds, and view it in Tools > Logs. There will be an entry for the hold's creation. -From the patron's account, select the holds and click 'Group selected' -Run the log for the reserve_id, and note that there was not an entry generated by putting the hold into a group -Suspend the hold, then view the log for that reserve_id. Note that the log entry for the suspension now includes the hold_group_id. -From the patron's hold tab, click on the number in the 'Hold group' column, then select 'Ungroup hold' -Run the log for the reserve_id, and note that there is no new entry for ungrouping the hold -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26