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

[Bug 42182] New: StaffReportsHome HTML customization does not work when branch limited
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42182 Bug ID: 42182 Summary: StaffReportsHome HTML customization does not work when branch limited Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface 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 TO recreate: 1- Create a StaffReportsHome HTML customization 2- Limit it by branch 3- Log into that branch and to to the reports home page 4- No HTML customization -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 42163] New: wrapper-staff-tool-plugin.inc no longer loads the admin menu
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42163 Bug ID: 42163 Summary: wrapper-staff-tool-plugin.inc no longer loads the admin menu Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org 41367 broke the wrapper for the plugin and it no longer loads on plugins when using the wrapper. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 64

[Bug 42156] New: Staging and matching authorities with bad characters can fail
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42156 Bug ID: 42156 Summary: Staging and matching authorities with bad characters can fail Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We have some protections on bibliographic records with bad characters to avoid dying, however for authorities we don't do the same. Importing records with invalid characters can kill the matching jobs during staging -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 42149] New: The main navigation needs an aria-label
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42149 Bug ID: 42149 Summary: The main navigation needs an aria-label Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org 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 When there are more than one <nav> elements on a page, it is best practice for each to have a unique aria-label to help screen readers be able to jump between the landmarks. The Breadcrumb nav is labeled, but the main nav is not. If the user pulls up a list of landmarks to navigate the page, they have to assume that the first nav is the main one. While technically using the nav element without the aria-label passes the minimum requirements for WCAG 4.1.2 (Name, Role, Value), it fails WCAG 2.4.1 (Bypass Blocks) because the user has to do extra work to know how to get to the main nav. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 42147] New: Action logs for hold creation contain less data
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42147 Bug ID: 42147 Summary: Action logs for hold creation contain less data Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com In 24.11, the "info" column in the action logs for a hold creation action contained the full hold data. As of 25.05 and onward, this is no longer the case. Holds created through the staff interface show only the reserve_id in the "info" column, and holds created by API show the API arguments, which is a bit more helpful, but still not as much data as the "info" column used to contain. This makes it harder to search for the logs of a specific hold, and in some cases harder to determine whether an unexpected hold option/status was user error on the part of whoever placed the hold, or whether that unexpected state occurred later. It would be very helpful to restore the behavior of logging the full hold object data in the "info" column. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 42142] New: The gear icon to toggle panel for login settings needs accessibility updates
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42142 Bug ID: 42142 Summary: The gear icon to toggle panel for login settings needs accessibility updates Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org 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 View source on any Koha page and paste into the W3C Markup Validation Service. https://validator.w3.org/#validate_by_input Notice the error: The aria-label attribute must not be specified on any i element unless the element has a role value... This violates WCAG 1. 4.1.2 Name, Role, Value (Level A) I think the <a> element should have the role button and aria-label Toggle panel for login settings and the <i> element should have aria-hidden="true" The Toggle panel for login settings also needs some work to announce its state as collapsed and expanded to be more accessible for screen readers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 42020] New: (Bug 39482 follow-up) Library info link shown in OPAC without OpacLibraryInfo and library URL
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42020 Bug ID: 42020 Summary: (Bug 39482 follow-up) Library info link shown in OPAC without OpacLibraryInfo and library URL Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Prior to Bug 39482 a link to library info modal (with (i) icon) was generated only if OpacLibraryInfo was defined. Now it is there even if there is no OpacLibraryInfo at all and no URL defined for the library. It is generated in any circumstances. (BTW this makes the following snippet from opac-detail.tt dead: [% ELSIF holding_library_url %] <a href="[% holding_library_url | url %]"> [% holding_library_name | html %] </a> [% ELSE %] <span>[% holding_library_name | html %]</span> [% END %] ) This is because Koha::Library::opac_info returns a RS now, and not an object, as it was before. So a test on $item->holding_branch->opac_info( { lang => $lang } ) in opac-detail.pl returns always true. To reproduce: 1) Have a standard ktd installation. 2) Make sure there is no OpacLibraryInfo defined in HTML customizations. 3) Make sure there is no URL for any library. 4) In OPAC, perform any search. On a detail page you would see a link to an empty modal from the Current library items column. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 41967] New: Cleanup database --labels deletes labels over 1 day old regardless of passed value
by bugzilla-daemon＠bugs.koha-community.org 24 May '26

24 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41967 Bug ID: 41967 Summary: Cleanup database --labels deletes labels over 1 day old regardless of passed value Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz A client noticed that their label batches were always deleted, even though our serverwide cron says to delete label batches over 30 days old. I noticed it does the same on main. To test you have to manipulate data a little bit : 1. Create two label batches 1.1. Go to Cataloging > Label creator > New > Label batch 1.2. Add barcodes in "Add by barcodes or itemnumbers" If using KTD, you can use the following barcodes 39999000010114 39999000010138 39999000010152 1.3. Click "Add items" 1.4. Redo steps 1.1 to 1.3 for the second batch (it can have the same barcodes, it doesn't really matter) 2. Manipulate the timestamps in the DB so that they are ~30 days ago and ~5 days ago * If using KTD access the database with `ktd --dbshell` (if outside the shell) or `koha-mysql kohadev` (if already inside the shell) UPDATE creator_batches SET timestamp = DATE_SUB(NOW(), INTERVAL 30 DAY) WHERE batch_id = '1'; UPDATE creator_batches SET timestamp = DATE_SUB(NOW(), INTERVAL 5 DAY) WHERE batch_id = '2'; * If necessary, change the label batch ids. If using a fresh KTD, the batches should be 1 and 2. ==> You should have 6 entries in creator_batches, 3 with a timestamp 30 days ago and 3 with a timestamp 5 days ago. 3. Run cleanup_database with --labels set to 15 days and verbose option (and confirm option) ==> The output says "Purging item label batches last added to more than 1 days ago. Done with purging 6 item label batches last added to more than 1 days ago." ==> Nothing left in creator_batches even though one set was less than 15 days old. :( -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[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 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