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

[Bug 43652] New: Make ILLRequestsTabs tab names translatable
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43652 Bug ID: 43652 Summary: Make ILLRequestsTabs tab names translatable Initiative type: --- Sponsorship --- status: 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: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- System preference ILLRequestsTabs adds the possibility to add and show different tabs for different ILL request statuses. However, tha name of the tab can only be added in one language. In multilingual interfaces this is a problem as it is shown as it is written in name attribute in the system preference. How to reproduce: 1. Go to Administration and search for the ILLRequestsTabs system preference 2. Add configuration, for example in English: - name: Requested status: - REQ - name: Completed status: - COMP 3. Make sure the ILL module (ILLModule systempreference) is enabled 4. Make sure you have more than one language installed and you have enabled more than one language in StaffInterfaceLanguages. 5. Go to the ILL module and select "Visit ILL requests" 6. Notice that that the Status tabs are in English (as added before) even when the used language is changed. What we need: - A way to add the tab names in multiple languages. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #61 from Pedro Amorim (ammopt) <pedro.amorim(a)openfifth.co.uk> --- Hi all, thanks for addressing the previous points. Upon looking again though, it appears there are a few more issues worth revisiting. Finding 1: editing a record now runs the duplicate check, on every install The follow-up "Check for duplicates when editing a bibliographic record" makes edits check for duplicates, including for frameworks with no matching rule, which fall back to the old title/author check. That's a behavior change for all sites and contradicts the release notes ("for use when creating new records"). If editing checks are wanted, could they be limited to frameworks with a matching rule, and the release notes updated? 1) Apply the patches, updatedatabase and restart_all (don't configure any matching rule) 2) Edit biblio 32 ('Alcestis'): http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=32 3) Change nothing, click 'Save' => Expected: the record is saved, as before the patches => Actual: 'Duplicate record suspected', pointing at biblio 33 ('Alcestis /') Finding 2: editing any framework other than Default fails The test plan only edits the Default framework, which is the one case that works. 1) Edit the 'Books, booklets, workbooks' framework: http://localhost:8081/cgi-bin/koha/admin/biblio_framework.pl?op=add_form&fr… => Expected: 'Description' is an editable text field => Actual: it's shown as plain text 2) Click 'Submit' => Expected: the framework is saved => Actual: 'An error occurred when updating this framework. Perhaps it already exists.' Finding 3: with a matching rule set, the edit check misses duplicates depending on which record you edit 1) Because of Finding 2, set the ISBN rule ('020$a', id 1) on the BKS framework directly: sudo koha-mysql kohadev -e "INSERT INTO biblio_framework_marc_matcher (frameworkcode, marc_matcher_id, forbid_duplicate_creation) VALUES ('BKS', 1, 0);" 2) Edit biblio 252, change nothing, click 'Save': http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=252 => 'Duplicate record suspected', pointing at biblio 155 (same ISBN 0964479621) 3) Edit biblio 155, change nothing, click 'Save': http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=155 => Expected: the same warning, pointing at biblio 252 => Actual: it saves with no warning Finding 4: with 'Forbid creation of duplicate' on, a record that has a duplicate can't be edited 1) Continuing from Finding 3, turn on 'Forbid creation of duplicate' for BKS: sudo koha-mysql kohadev -e "UPDATE biblio_framework_marc_matcher SET forbid_duplicate_creation = 1 WHERE frameworkcode = 'BKS';" 2) Edit biblio 252, change nothing, click 'Save': http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=252 => Expected: the edit is saved (the option is about creating duplicates, not editing existing records) => Actual: 'Duplicate record found' with only an 'Edit existing items' button, so there's no way to save the edit -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42880] New: Avoid the USMARC round-trip when building ES documents
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42880 Bug ID: 42880 Summary: Avoid the USMARC round-trip when building ES 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: --- For every record, marc_records_to_documents serializes the record to USMARC and then re-parses it with MARC::Record->new_from_usmarc, purely to "prove it will round-trip" before storing marc_data (Koha/SearchEngine/Elasticsearch.pm). Profiling shows this re-decode is roughly 20-25% of the per-record mapping CPU. The round-trip is a safety net to fall back to MARCXML storage when a record cannot be represented as USMARC (e.g. length > 99999). That check could run only when the encode actually fails, rather than decoding every record on the happy path. Test plan: 1. prove t/db_dependent/Koha/SearchEngine/Elasticsearch.t 2. Confirm marc_data is unchanged for normal records. 3. Confirm an over-long record still falls back to MARCXML storage. 4. Benchmark marc_records_to_documents before/after. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 38270] New: Add MARCXML options to ElasticsearchMARCFormat
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38270 Bug ID: 38270 Summary: Add MARCXML options to ElasticsearchMARCFormat Change sponsored?: --- 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As noted on bug 27365, Elasticsearch search results don't get fetched correctly if a MARCXML record cannot be serialized in the compact ISO MARC 2709 format. One reason it might not be able to be serialized is due to 1 MARC field containing more than 9999 bytes or a whole record containing more than 99999 bytes. The change to be provided here will store MARCXML instead of ISO MARC 2709. -- During development, it may be found that a compressed form of MARCXML is preferred to an uncompressed form to be more comparable with the currently stored ISO MARC. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 27365] New: Koha doesn't check marcxml field size is < 10000 and fails in various places
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27365 Bug ID: 27365 Summary: Koha doesn't check marcxml field size is < 10000 and fails in various places Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hi ISO standard >The core of the framework is a MARCXML schema that allows lossless round-trip >conversion of an ISO 2709 MARC 21 record and an XML-encoded MARC 21 record. Thus a field size is 9999 bytes max. But /usr/share/perl5/MARC/File/USMARC.pm doesn't care: my $direntry = sprintf( "%03s%04d%05d", $field->tag, $len, $dataend ); and if len >= 10000 it silently creates a bogus directory with a length of 13 rather then 12. These non-conformed marxml will fail in various places. Export, search results list with elasticsearch which store ISO 2709 record in index and use them as data source in results list. eg: Easy to trigger in french UNIMARC with 359 (sorry in french) https://www.transition-bibliographique.fr/wp-content/uploads/2019/02/B359-2… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56

[Bug 40960] New: Notifying holds should not print notice if no messaging preference is notified
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40960 Bug ID: 40960 Summary: Notifying holds should not print notice if no messaging preference is notified Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In overdue_notice.pl, holds_reminder.pl, no paper notice is sent to patron if no checkbox is checked. This should be the same for notifying holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 41023] New: Add the abilty to select multiple values in dropdown lists in holding table
by bugzilla-daemon＠bugs.koha-community.org 27 Sep '26

27 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41023 Bug ID: 41023 Summary: Add the abilty to select multiple values in dropdown lists in holding table Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If filters are enabled for holding table (items), for 4 fields the filter is a drop-down list (item type, homebranch, holdingbranch, status). It is currently not possible to select multiple values. It should be very useful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 6473] Test bug for Git-bz ✔ ❤ ★
by bugzilla-daemon＠bugs.koha-community.org 27 Sep '26

27 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197097|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6473] Test bug for Git-bz ✔ ❤ ★
by bugzilla-daemon＠bugs.koha-community.org 27 Sep '26

27 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #190256|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6473] Test bug for Git-bz ✔ ❤ ★
by bugzilla-daemon＠bugs.koha-community.org 27 Sep '26

27 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #190255|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

1 0