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

[Bug 43273] New: Grammar and spell check extension Allow spellcheck="true"
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43273 Bug ID: 43273 Summary: Grammar and spell check extension Allow spellcheck="true" Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: sam.young(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 Target Milestone: --- Ticket received said We are hoping to start using Grammarly or another spell checking browser extension to help us in our cataloging. Is there any current development or would it be possible to create a customization or small enhancement to enable native browser spell checking? We use both the basic and advanced editors. Thanks for your help with this! Just needed to add spellcheck="true" to the forms as a system preference to allow this to be turned on and off. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43270] New: Reports using datatables: filtered reports should only send filtered results to batch operations
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43270 Bug ID: 43270 Summary: Reports using datatables: filtered reports should only send filtered results to batch operations Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: minor 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: --- From the new datatables view in Reports, if you filter results using the 'Search' box and then export the results, only the *filtered* results are exported (not the full result set). However, if you filter results using the datatables view and then send click 'Batch operations with...', the *full* results set is sent to batch operations. Only the filtered results should be sent to batch operations, in line with how 'Export' works from filtered results. To replicate: -Create or run a report with a column that allows batch operations (such as borrowernumber, itemnumber, or biblionumber) -Click the 'Open in DataTables' option from your results -Filter your report using the 'Search' box so that only a portion of the results show -Click 'Export', select an option (ex: Print), and note that only the filtered subset shows in the exported data -Return to your results, and check that the filter is still applied -Click 'Batch operations with...' and select an operation -Note that the full results set, not only the filtered subset, has been sent to batch operations 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 1

[Bug 24898] New: AddIssue destructively changes transfers
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24898 Bug ID: 24898 Summary: AddIssue destructively changes transfers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 24298 As highlighted in a comment on bug 24298, AddIssue can destructively cancel transfers. The transferto field is forcefully overriden and the reason isn't recorded. We should handle this in a clearer way.. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24298 [Bug 24298] Record if a transfer was triggered by 'return to homebranch' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 22160] New: OMNIBUS: Transfers enhancements
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22160 Bug ID: 22160 Summary: OMNIBUS: Transfers enhancements Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 90

[Bug 42513] New: Stock Rotation fails when Advancement transfer is cancelled and then item is repatriated
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42513 Bug ID: 42513 Summary: Stock Rotation fails when Advancement transfer is cancelled and then item is repatriated Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Example: | action | date | reason | cancellation_reason | | ------------------------- | ---------- | -------------------------- | ------------------- | | Item transfer requested | 2025-09-30 | StockrotationAdvance | - | | Item transfer cancelled | 2025-10-01 | - | ItemLost | | Item scanned in +transfer | 2025-10-02 | StockrotationRepatriation | - | | ------------------------- | ---------- | -------------------------- | ------------------- | Because there's no completion date for the StockrotationAdvance transfer, it will never move forward. The check in StockRotationItem.pm sub needs_advancing specifically compares to the most recent completed transfer with a reason of "StockrotationAdvance" We need to check if there's a StockrotationRepatriation to the current stage's branch after the cancelled StockrotationAdvance transfer or it will stay there forever and never rotate unless it's manually advanced. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 43271] New: Hold cancellation via Holds to Pull should include a confirmation modal
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43271 Bug ID: 43271 Summary: Hold cancellation via Holds to Pull should include a confirmation modal Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- When cancelling a hold from the patron or biblio, clicking the cancel button (garbage can) brings up a modal in which one selects a cancellation reason and confirms the cancellation. The Holds to Pull page, on the other hand, asks one to select a reason before clicking Cancel and does not include a confirmation step. It would be good to make Holds to Pull use the same confirmation modal as the bib and patron -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 43272] New: Rework Holds to Pull to fetch data via API
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '26

11 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43272 Bug ID: 43272 Summary: Rework Holds to Pull to fetch data via API Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Blocks: 43017 Target Milestone: --- The Holds to Pull page loads slowly when a system has many holds in the system. We should rework this page to use the API to pull this data. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43017 [Bug 43017] [OMNIBUS] Interface optimization -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[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