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

[Bug 21453] New: blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21
by bugzilla-daemon＠bugs.koha-community.org 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21453 Bug ID: 21453 Summary: blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: arouss1980(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If you add or alter an authority record and edit one of the MARC fields in UNIMARC 5XX 'See Also Reference Tracing Block' [1], you can click on the ellipsis (...) next to a subfield [2] to launch the authority finder plugin. This plugin allows you to search for an authority and then pick an entry from the 'Special relationship:' dropdown menu in order to set the relationship between the two authorities. The results list of the authority finder contains 'Choose' buttons which _should_ insert all data from the chosen authority into the appropriate subfields of the MARC tag you are editing [3]. However, in UNIMARC setups this does not work: clicking on 'Choose' only populates subfield $a ('Entry Element') with data, but not subfields $3 and $5 ('Authority Record Number' and 'Tracing Control', respectively), which are just as important for correct authority linking. I've tracked this down to these lines of code which are MARC21-specific and use hardcoded subfield values in blinddetail-biblio-search.pl: 91 for ( $field->subfields ) { 92 next if $_->[0] eq '9'; # $9 will be set with authid value 101 push( @subfield_loop, { marc_subfield => 'w', marc_values => $relationship } ) if ( $relationship ); There is also this code in the template blinddetail-biblio-search.tt: 38 [%- END -%]‡9[% authid | html %]"; 138 if(code.value=='9'){ 139 subfield.value = "[% authid |replace("'", "\'") |replace('"', '\"') |replace('\n', '\\n') |replace('\r', '\\r') %]"; These code fragments don't work 100% because in UNIMARC authorities the authid value is stored in subfield $3 and the relationship code in $5. I propose to modify the Perl script above (which is currently MARC flavour agnostic), have it check the 'marcflavour' system preference, and use that to decide which subfield to push the authority relator code to. A similar approach in the template file will set the authid subfield value depending on whether you are a MARC21 or UNIMARC user. [1] Known as the 'Related Access Point Block' in recent IFLA updates. [2] For the ellipsis to appear next to a subfield, you must view the MARC structure of the relevant authority type and then edit the subfields of the tag you're interested in. Finally, you must select an authority type from the 'Thesaurus:' dropdown menu. [3] Under the hood each 'Choose' button is a call to the JS function doauth(), which in turn calls blinddetail-biblio-search.pl with the parameters required (authid, relationship, etc.). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 41

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

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- 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 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 Biblibre Sandboxes <sandboxes(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #195692|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 28 Sep '26

28 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 --- Comment #456 from Biblibre Sandboxes <sandboxes(a)biblibre.com> --- Created attachment 206894 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206894&action=e… Bug 6473: test Signed off using the sandbox 'x6473' -- You are receiving this mail because: You are watching all bug changes.

1 0

[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