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

[Bug 9750] Bring routing lists into notices & slips
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9750 Marion Durand <marion.durand(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marion.durand(a)biblibre.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42303] New: Duplicate itemnumber in items and deleteditems table when order cancel fails
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42303 Bug ID: 42303 Summary: Duplicate itemnumber in items and deleteditems table when order cancel fails Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Noticed this while working on bug 41169. It's possible to end up with duplicate itemnumber in items and deleteditems table when cancelling an order. I attempted to cancel an order and one of the items is present in items_last_borrower table. This caused Koha to die on error 500 and exception [Foreign key constraint broken on deleting resource] was raised. After some debugging I tried canceling again and got: >DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Duplicate entry '227661' for key 'PRIMARY' since item is now in both items and deleteditems table after failed cancel. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 28628] New: Elasticsearch - Heading search form does'nt match related indexed heading
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28628 Bug ID: 28628 Summary: Elasticsearch - Heading search form does'nt match related indexed heading Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com When an authority is created using LinkBibHeadingsToAuthorities the heading created "700 $aVidard $bMathieu $f1971-..." (unimarc) is saved as "Vidard Mathieu 1971-..", indexed as "Vidard Mathieu 1971-.." and searched as "Vidard Mathieu 1971" => no match. So the link bib does'nt work. Test plan (UNIMARC exemple): - create a biblio with the following data in tag 700: - $a Vidard - $b Mathieu - $d 1971-... - save. => a new authority is created with the following heading "Vidard Mathieu 1971-.." - create an other biblio with the same value in tag 700. => again a new authority is created with the same heading. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 42323] New: View ILL request - hide patron's name in Patron-column
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42323 Bug ID: 42323 Summary: View ILL request - hide patron's name in Patron-column 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: kati.sillgren(a)porvoo.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com ill-requests.pl View ILL requests: hide or add possibility to hide patron's name in Patron-column. Patron-column includes now patron's name (firstname surname) patron's card number This action isn't logged. (GDPR) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 42320] New: Error in po files (plural form)
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42320 Bug ID: 42320 Summary: Error in po files (plural form) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com Some po files (xx-messages-js.po) have a faulty line at the start : Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n (for example Japanese (ja-Jpan-JP) and Korean (ko-Kore-KP)) It generates errors during the update/installation of translation for these languages The error look like this : ``` ERROR parsing plural forms header [nplurals=INTEGER; plural=EXPRESSION;] ``` The language is still available in the OPAC and staff interface after the translation and I couldn't find a bug on the interface (I didn't search very long), but it might be a problem for some translation if filled : ``` #: koha-tmpl/intranet-tmpl/prog/js/checkouts.js:1628 msgid "Show 1 unresolved claim" msgid_plural "Show {count} unresolved claims" msgstr[0] "" msgstr[1] "" ``` Should we add default values (even if it might not be specific for that language) ? "Plural-Forms: nplurals=2; plural=n != 1;\n" (source en-GB) or "Plural-Forms: nplurals=2; plural=n > 1;\n" (source fr-FR) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 12624] Getting all search results in C4::Breeding::Z3950Search, instead of pageful
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12624 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |33835 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33835 [Bug 33835] [OMNIBUS] Move Breeding module to Koha namespace -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33835] New: [OMNIBUS] Move Breeding module to Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33835 Bug ID: 33835 Summary: [OMNIBUS] Move Breeding module to Koha namespace Change sponsored?: --- Product: Koha Version: master 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 12624] Getting all search results in C4::Breeding::Z3950Search, instead of pageful
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12624 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |In Discussion --- Comment #7 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #6) > It looks like this hasn't changed yet - is it still a change we are > interested in? Not sure. I do not think that we should get all records rightaway if we search multiple targets at once and we potentially have many hits. Couldnt that be done smarter depending on the number of hits returned and the number of targets involved? See also bug 42321 for better handling empty SRU results. See also omnibus bug 33835 for moving out of C4. Moving this to In Discussion. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41205] New: Error in Advanced Cataloging editor when z39 source returns undef / empty records
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41205 Bug ID: 41205 Summary: Error in Advanced Cataloging editor when z39 source returns undef / empty records 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1 - Have LOC defined as a Z39 Source (standard in KTD) 2 - Open the advanced editor 3 - Search for ISBN 9780520401129 4 - Search explodes, logs like: AH01215: stderr from /kohadevbox/koha/svc/cataloguing/metasearch: Can't call method "raw" on an undefined value at /kohadevbox/koha/Koha/MetaSearcher.pm line 267., referer: http://localhost:8081/cgi-bin/koha/cataloguing/editor.pl AH01215: stderr from /kohadevbox/koha/svc/cataloguing/metasearch: Magic number checking on storable file failed at /usr/lib/x86_64-linux-gnu/perl/5.36/Storable.pm line 443, at /kohadevbox/koha/Koha/MetaSearcher.pm line 144., referer: http://localhost:8081/cgi-bin/koha/cataloguing/editor.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 6532] Way to move items to another record in batches
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '26

09 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 --- Comment #27 from Mathieu Saby <mathsabypro(a)gmail.com> --- The patch was made for us, I am going to test it. I suppose the status should now be "Need sign off"? -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0