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

[Bug 43208] New: When searching action logs incorrectly formatted timestamps can slow responses
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43208 Bug ID: 43208 Summary: When searching action logs incorrectly formatted timestamps can slow responses Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- Observed in production on a site with many rows in action logs, searching using the filters can take a long time. Testing the query on the command line I noticed it was fast if I used correct mySQL timestamps, however, the query took over a minute when the timestamps were formatted like 2026-07-31T00:00:00Z Below is the query I got from dumping the resultset as a query, it took over a minute to run, then if I correct the timestamp it takes seconds (SELECT `me`.`action_id`, `me`.`timestamp`, `me`.`user`, `me`.`module`, `me`.`action`, `me`.`object`, `me`.`info`, `me`.`interface`, `me`.`script`, `me`.`trace`, `me`.`diff`, `librarian`.`borrowernumber`, `librarian`.`cardnumber`, `librarian`.`surname`, `librarian`.`firstname`, `librarian`.`preferred_name`, `librarian`.`middle_name`, `librarian`.`title`, `librarian`.`othernames`, `librarian`.`initials`, `librarian`.`pronouns`, `librarian`.`streetnumber`, `librarian`.`streettype`, `librarian`.`address`, `librarian`.`address2`, `librarian`.`city`, `librarian`.`state`, `librarian`.`zipcode`, `librarian`.`country`, `librarian`.`email`, `librarian`.`phone`, `librarian`.`mobile`, `librarian`.`fax`, `librarian`.`emailpro`, `librarian`.`phonepro`, `librarian`.`B_streetnumber`, `librarian`.`B_streettype`, `librarian`.`B_address`, `librarian`.`B_address2`, `librarian`.`B_city`, `librarian`.`B_state`, `librarian`.`B_zipcode`, `librarian`.`B_country`, `librarian`.`B_email`, `librarian`.`B_phone`, `librarian`.`dateofbirth`, `librarian`.`branchcode`, `librarian`.`categorycode`, `librarian`.`dateenrolled`, `librarian`.`dateexpiry`, `librarian`.`password_expiration_date`, `librarian`.`date_renewed`, `librarian`.`gonenoaddress`, `librarian`.`lost`, `librarian`.`debarred`, `librarian`.`debarredcomment`, `librarian`.`contactname`, `librarian`.`contactfirstname`, `librarian`.`contacttitle`, `librarian`.`borrowernotes`, `librarian`.`relationship`, `librarian`.`sex`, `librarian`.`password`, `librarian`.`secret`, `librarian`.`auth_method`, `librarian`.`flags`, `librarian`.`userid`, `librarian`.`opacnote`, `librarian`.`contactnote`, `librarian`.`sort1`, `librarian`.`sort2`, `librarian`.`altcontactfirstname`, `librarian`.`altcontactsurname`, `librarian`.`altcontactaddress1`, `librarian`.`altcontactaddress2`, `librarian`.`altcontactaddress3`, `librarian`.`altcontactstate`, `librarian`.`altcontactzipcode`, `librarian`.`altcontactcountry`, `librarian`.`altcontactphone`, `librarian`.`smsalertnumber`, `librarian`.`sms_provider_id`, `librarian`.`privacy`, `librarian`.`privacy_guarantor_fines`, `librarian`.`privacy_guarantor_checkouts`, `librarian`.`checkprevcheckout`, `librarian`.`updated_on`, `librarian`.`lastseen`, `librarian`.`lang`, `librarian`.`login_attempts`, `librarian`.`overdrive_auth_token`, `librarian`.`anonymized`, `librarian`.`autorenew_checkouts`, `librarian`.`primary_contact_method`, `librarian`.`protected`, `patron`.`borrowernumber`, `patron`.`cardnumber`, `patron`.`surname`, `patron`.`firstname`, `patron`.`preferred_name`, `patron`.`middle_name`, `patron`.`title`, `patron`.`othernames`, `patron`.`initials`, `patron`.`pronouns`, `patron`.`streetnumber`, `patron`.`streettype`, `patron`.`address`, `patron`.`address2`, `patron`.`city`, `patron`.`state`, `patron`.`zipcode`, `patron`.`country`, `patron`.`email`, `patron`.`phone`, `patron`.`mobile`, `patron`.`fax`, `patron`.`emailpro`, `patron`.`phonepro`, `patron`.`B_streetnumber`, `patron`.`B_streettype`, `patron`.`B_address`, `patron`.`B_address2`, `patron`.`B_city`, `patron`.`B_state`, `patron`.`B_zipcode`, `patron`.`B_country`, `patron`.`B_email`, `patron`.`B_phone`, `patron`.`dateofbirth`, `patron`.`branchcode`, `patron`.`categorycode`, `patron`.`dateenrolled`, `patron`.`dateexpiry`, `patron`.`password_expiration_date`, `patron`.`date_renewed`, `patron`.`gonenoaddress`, `patron`.`lost`, `patron`.`debarred`, `patron`.`debarredcomment`, `patron`.`contactname`, `patron`.`contactfirstname`, `patron`.`contacttitle`, `patron`.`borrowernotes`, `patron`.`relationship`, `patron`.`sex`, `patron`.`password`, `patron`.`secret`, `patron`.`auth_method`, `patron`.`flags`, `patron`.`userid`, `patron`.`opacnote`, `patron`.`contactnote`, `patron`.`sort1`, `patron`.`sort2`, `patron`.`altcontactfirstname`, `patron`.`altcontactsurname`, `patron`.`altcontactaddress1`, `patron`.`altcontactaddress2`, `patron`.`altcontactaddress3`, `patron`.`altcontactstate`, `patron`.`altcontactzipcode`, `patron`.`altcontactcountry`, `patron`.`altcontactphone`, `patron`.`smsalertnumber`, `patron`.`sms_provider_id`, `patron`.`privacy`, `patron`.`privacy_guarantor_fines`, `patron`.`privacy_guarantor_checkouts`, `patron`.`checkprevcheckout`, `patron`.`updated_on`, `patron`.`lastseen`, `patron`.`lang`, `patron`.`login_attempts`, `patron`.`overdrive_auth_token`, `patron`.`anonymized`, `patron`.`autorenew_checkouts`, `patron`.`primary_contact_method`, `patron`.`protected` FROM `action_logs` `me` LEFT JOIN `borrowers` `librarian` ON `librarian`.`borrowernumber` = `me`.`user` LEFT JOIN `borrowers` `patron` ON `patron`.`borrowernumber` = `me`.`object` WHERE ( ( ( `module` = 'CRONJOBS' AND ( `timestamp` <= '2026-07-31T23:59:59Z' AND `timestamp` >= '2026-07-31T00:00:00Z' ) ) AND ( `me`.`timestamp` LIKE '%renew%' OR `me`.`user` LIKE '%renew%' OR `me`.`module` LIKE '%renew%' OR `me`.`action` LIKE '%renew%' OR `me`.`object` LIKE '%renew%' OR `me`.`info` LIKE '%renew%' OR `me`.`interface` LIKE '%renew%' ) ) ) ORDER BY `me`.`timestamp` DESC LIMIT 20); -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 42190] New: Add datatables to reports
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42190 Bug ID: 42190 Summary: Add datatables to reports Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Markus made a really neat datatables plugin: https://github.com/mpathy/KohaDatatables4Reports/tree/main I think it would be a great feature for core Koha. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 71

[Bug 43267] New: Batch operations from datatables report view should only send visible results (same as standard view)
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43267 Bug ID: 43267 Summary: Batch operations from datatables report view should only send visible results (same as standard view) Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 42190 Target Milestone: --- Created attachment 203428 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203428&action=e… Screenshot showing 'Batch operations with....' button from reports datatables view Sending results to batch operations from the new datatables report view should only send visible results (that is, it should work the same way as sending results from the standard report view). Staff can send *visible* results to batch operations from a report that contains columns for borrowernumber, biblionumber, itemnumber, or cardnumber. However, when using the new datatables feature, all report results are sent to batch operations, not just the visible results. To add extra confusion, the button for batch operations from the datatables view reads 'Batch operations with [total results number] visible records', even when the default 20 records are visible (see attached screenshot). If I change nothing and send results to batch operations as is, all results (not just the 20 visible) are sent. Only visible results should send to batch operations from the datatable view so that it works the same way as sending results to batch operations from the standard report view. (Or, all report results from the standard view should be sent for batch operations, not only the visible results.) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42190 [Bug 42190] Add datatables to reports -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 30681] New: Allow overlay protection of MARC data by subfield
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30681 Bug ID: 30681 Summary: Allow overlay protection of MARC data by subfield Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 14957 Bug 14957 introduces overlay protection enforced at the MARC tag level. It would be great to be able to specify down to the subfield level in rules. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 [Bug 14957] Write protecting MARC fields based on source of import -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 39263] New: When an ILL request is closed the item and biblio record created for it should be deleted
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39263 Bug ID: 39263 Summary: When an ILL request is closed the item and biblio record created for it should be deleted Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com When an ILL request is closed (I mean the document has been returned to the supplying library) the item and biblio record created for it should be deleted, either in real time (better I suppose) or with a script in cron They were only created to enable the document to be checked out to the patron. If we don't remove them, they will pollute the catalog. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 42611] New: Javascript error on readingrec.pl when no reading history
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42611 Bug ID: 42611 Summary: Javascript error on readingrec.pl when no reading history Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com If you start a fresh KTD, open your F12 tools, and go to http://localhost:8081/cgi-bin/koha/members/readingrec.pl?borrowernumber=51 you'll see a Javascript error. It's because we call 'let table_dt = table.DataTable();' when when "table" is not defined. Should be an easy fix. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 41091] New: Add ISO18626 to ILL for borrowing
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41091 Bug ID: 41091 Summary: Add ISO18626 to ILL for borrowing Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Bug 37762 is adding lending to Koha using the ISO18628 spec. It would be a good followup if we could also using ISO for borrowing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 42734] New: autoMemberNumValue syspref has no UI â add it to patrons preferences with a caution note
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42734 Bug ID: 42734 Summary: autoMemberNumValue syspref has no UI â add it to patrons preferences with a caution note Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Bug 34000 introduced autoMemberNumValue as an internal monotonic counter to prevent cardnumber re-issuance. However there is currently no way for staff to view or correct this value if it becomes inflated â for example, if a book barcode is accidentally scanned when creating a patron and that patron is subsequently deleted or has their cardnumber corrected. This patch adds autoMemberNumValue to the Patrons system preferences page (near autoMemberNum) so that superlibrarians can correct a runaway counter without contacting vendor support. The entry includes a caution note explaining: - that the value is managed automatically and should not normally be changed - that Koha always generates from max(counter, live_db_max), so lowering the counter only has effect once the patron responsible for the inflated number has been deleted or had their cardnumber corrected - the risk of setting it too low (potential cardnumber re-issuance) Test plan: 1. Apply patch 2. Go to Administration > System preferences > Patrons 3. Confirm autoMemberNumValue is visible immediately below the autoMemberNum preference 4. Confirm the caution note is displayed 5. With autoMemberNum enabled, create a patron without specifying a cardnumber and confirm the generated number is consistent with the counter value 6. Adjust autoMemberNumValue to a lower number (after ensuring no active patron holds a cardnumber in that range), create another patron, and confirm the next auto-generated number reflects the corrected counter -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 43265] New: Add ability to choose hold cancellation reason if hold is cancelled at the time of check out
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43265 Bug ID: 43265 Summary: Add ability to choose hold cancellation reason if hold is cancelled at the time of check out Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: alyssa.drake(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- During checkout, sometimes patrons will try to check out items that are on hold for someone else. If they do this at the front desk with a staff person, the staff person is presented with the option to confirm the check out and cancel the hold or not cancel the hold. Unlike canceling holds from the patron screen or the bibliographic record, staff aren't able to choose the reason why the hold was cancelled. Some libraries would like to add the ability to select the hold cancellation reason when canceling holds this way. Examples of reasons why libraries might want this feature: They want to pull the item from circulation prematurely. The item is for a pass for something they no longer are allowed to assign passes for. The last available item is damaged and is irreplaceable. The item is for a semester long check out and other items cannot fill the hold. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42078] New: Allow vendor ID searches on serial subscription vendor search page
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42078 Bug ID: 42078 Summary: Allow vendor ID searches on serial subscription vendor search page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently the serial subscription vendor search (serials/acqui-search-result.pl) only searches vendors by name using a LIKE query. This enhancement updates the search logic so the input field may also match a vendor ID. If the entered value matches an ID, the corresponding vendor will be returned in the results. This improves usability for staff who know the vendor ID and want to quickly locate a vendor without needing to search by name -- You are receiving this mail because: You are watching all bug changes.

1 19