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

[Bug 43653] New: Show or hide collapse/show controls based on state
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43653 Bug ID: 43653 Summary: Show or hide collapse/show controls based on state Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 43651 Target Milestone: --- Instead of always showing "Collapse all sub funds" and "Expand all sub funds" controls we should hide the one which isn't relevant. Same for the "Show inactive budgets" controls. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43651 [Bug 43651] Clarify "Expand all" and "Collapse all" link labels in Acquisitions and Funds sections -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 43600] New: Strange behavior with Booking dates when editing a booking
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43600 Bug ID: 43600 Summary: Strange behavior with Booking dates when editing a booking Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle(a)bywatersolutions.com Target Milestone: --- TO recreate: 1. Make an item, or item type, bookable. 2. Create a booking 3. Edit the booking 4. Notice strange behavior with the Booking dates. Sometimes you see them correctly, sometimes the field is empty. Usually the dates appear for a second and then disappear. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 42764] New: codespell.t fails after container OS upgrade due to newer codespell dictionary
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42764 Bug ID: 42764 Summary: codespell.t fails after container OS upgrade due to newer codespell dictionary Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org When the KTD container OS is upgraded (e.g. Debian Bookworm -> Trixie), two things happen simultaneously that cause xt/author/codespell.t to fail: 1. The OS codename changes, so Koha::Devel::CI::IncrementalRuns finds no history in the ci-results repository for the new codename and falls back to a full scan of all tracked files. 2. The newer OS ships a newer codespell version (installed unversioned from apt in package-config.yaml). Each codespell release expands its misspelling dictionary, so words silently accepted by the old version are now flagged. The combination means the first full scan on a new container OS fails on pre-existing code that was never touched since the old codespell version accepted it. The .codespell-ignore file (currently 20 entries) was developed against older codespell versions and does not cover terms newly flagged by the upgraded version. Test plan: 1. Apply patch 2. Run xt/author/codespell.t inside the new KTD container => All tests pass -- You are receiving this mail because: You are watching all bug changes.

1 36

[Bug 43525] New: Batch patron deletion and anonymization should be a background job
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43525 Bug ID: 43525 Summary: Batch patron deletion and anonymization should be a background job Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Patron deletion can be slow. When I test with 10,000 borrowers it takes 3minutes 45 seconds. We should move this to a background job. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 43670] New: Reverting waiting holds needs reason and notice
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43670 Bug ID: 43670 Summary: Reverting waiting holds needs reason and notice 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- When reverting a waiting hold, to my knowledge there is no way to explain why a hold was reverted, or notify the patron that the item is no longer waiting and why. It seems that it would be better customer service, if we have already notified a patron that a hold is waiting, to log and explain via notice why the hold was reverted. I don't know how complicated it would be for Koha to determine if the message is pending or not, and just remove the pending notification, or if the message was sent, to send a follow up with a reason why it was changed. If it is too complicated, just following the queued waiting message with a revert notice would suffice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43362] New: URI validation for biblio MARC21 field 856$u and items.uri
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43362 Bug ID: 43362 Summary: URI validation for biblio MARC21 field 856$u and items.uri Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic 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 Target Milestone: --- Would be nice to add (basic) URI validation for biblio MARC21 field 856$u and items.uri. Opening another report for authority records in relation to the use of external vocabularies, including corresponding biblio subfields. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 24910] New: Make it possible to choose see also-authorities in authority finder
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24910 Bug ID: 24910 Summary: Make it possible to choose see also-authorities in authority finder 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When searching for authorities, sometimes you may see the result you want to select in a see also, but it is not possible to *choose* that one. You have to do another search to get it into the results list of auth finder. Wouldnt it be nice if we could somehow add a link to choose them too? The current link allows you to open them, but this seems less useful at least in our case. Would a preference be useful to switch between choosing or opening ? Or should we add a small link? How could we address that best in terms of styling etc? Your feedback is appreciated ! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 43650] New: barcode value_builder: EAN13 treated as integer instead of string in JS
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43650 Bug ID: 43650 Summary: barcode value_builder: EAN13 treated as integer instead of string in JS 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: accounts(a)nyabla.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Created attachment 206873 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206873&action=e… the unexpected sequence of ean-13 barcodes the script treats the barcode as an integer instead of a string, meaning that an unexpected sequence is created (see attachment) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 42592] New: Flag +count embeds that cannot be sorted
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42592 Bug ID: 42592 Summary: Flag +count embeds that cannot be sorted Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Depends on: 41950 After bug 41950, +count embeds backed by a DBIC relationship are automatically sortable. However, some +count embeds are only computed at the Perl level (no matching DBIC relationship) and cannot be sorted. Currently, consumers discover this only by receiving a 400 error when attempting to sort. We need a mechanism to flag or advertise which +count embeds are sortable and which are not. This could be: 1. An annotation in the OpenAPI spec (e.g. x-sortable: false on the embed enum value) 2. A response header listing sortable fields 3. Documentation in the API markdown 4. A dedicated endpoint or metadata response The goal is to let API consumers know upfront which +count columns support sorting, without trial and error. Discussion started in bug 41950 comment 17. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41950 [Bug 41950] Make +count embeds sortable by using SQL-level COUNT subqueries -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 40394] New: Coce cover images should be requested in chunks
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40394 Bug ID: 40394 Summary: Coce cover images should be requested in chunks Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If you choose to display 100 results per page when searching the catalog, the current Coce client implementation will pick all the identifiers, and make an API call to Coce for the 100 ids. This is problematic because: * It can be overwhelming for the Coce server (it will make a thread/worker busy for too long even when another is idle). * It makes the rendering slow or unreliable. We should at least split the ids list into chunks of some fixed (limited) size. -- You are receiving this mail because: You are watching all bug changes.

1 2