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