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

[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 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 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 41265] New: NoIssuesChargeGuarantees and NoIssuesChargeGuarantorsWithGuarantees circulation checks not precise enough
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41265 Bug ID: 41265 Summary: NoIssuesChargeGuarantees and NoIssuesChargeGuarantorsWithGuarantees circulation checks not precise enough Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Hello all When a checkout is performed, the NoIssuesChargeGuarantees and NoIssuesChargeGuarantorsWithGuarantees values are checked. This is an ‘if’ statement with check values, but by default, these are empty strings and therefore defined in this way. I therefore believe that the verification is not exactly what we want, particularly when SIP performs the checkout without permission to force it. Furthermore, in kohastructure, the default value would be NULL from what I understand, and it has not been included in the syprefs sql file. Perhaps there are some cases that I am overlooking, but I will suggest a simple fix anyway. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 41404] New: No need to check related guarantor/guarantee charges when the limits are not set
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41404 Bug ID: 41404 Summary: No need to check related guarantor/guarantee charges when the limits are not set 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the code: # Check the debt of this patrons guarantees if ( defined $no_issues_charge_guarantees ) { # Check the debt of this patrons guarantors *and* the guarantees of those guarantors if ( defined $no_issues_charge_guarantors_with_guarantees ) { It is not possible to undef the system preferences, they are set as blank for no value - we need to check if they are numbers -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 43664] New: Copying password from the source record when merging patrons
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43664 Bug ID: 43664 Summary: Copying password from the source record when merging patrons Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Bug 30303 added the ability to choose which fields to retain when merging patrons. Patron merging still lacks the ability to copy passwords from the source patron to the destination patron. Add such functionality. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 42879] New: Avoid per-record plugin lookup in ES marc_records_to_documents
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42879 Bug ID: 42879 Summary: Avoid per-record plugin lookup in ES marc_records_to_documents Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- marc_records_to_documents invokes Koha::Plugins->call('elasticsearch_to_document', ...) once per record. Each call discovers the plugins implementing the hook, which runs a query against plugin_data -- even when no plugin implements the hook or plugins are disabled. In a batch reindex this is one extra query per record purely to discover there is nothing to call. The set of implementing plugins is constant for the batch. Resolve it once (or short-circuit when plugins are disabled / none implement the hook), then dispatch per record. Test plan: 1. prove t/db_dependent/Koha/SearchEngine/Elasticsearch.t 2. With a plugin implementing elasticsearch_to_document, confirm the hook still fires for every record. 3. Count DB statements during a batch reindex before/after. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 42500] New: Update hold ratios (reserveratios.pl) to fetch data via API
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '26

29 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42500 Bug ID: 42500 Summary: Update hold ratios (reserveratios.pl) 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 The Hold Ratios page is a pain point for larger systems with many holds. We should update how it fetches, displays, and interacts with data. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 52