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

[Bug 28332] New: Requesting Mana token with accented name fails
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28332 Bug ID: 28332 Summary: Requesting Mana token with accented name fails Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Mana-kb Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com CC: alex.arnaud(a)biblibre.com Test plan: - Go to Administration Share content with Mana KB (cgi-bin/koha/admin/share_content.pl) - in "Configure Mana KB" part, set your email and a name with accent (Université Foo), - click on "Send to Mana KB" => Fail. No mana token. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 21357] New: Filter elisions from index and search terms in Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21357 Bug ID: 21357 Summary: Filter elisions from index and search terms in Elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: ere.maijala(a)helsinki.fi To make searching easier at least in French, it would be nice to have the default configuration handle elisions properly (e.g. l'avion). Coming up with a proposed patch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 105

[Bug 30641] New: Authority detail page shows wrong number of records using the authority
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30641 Bug ID: 30641 Summary: Authority detail page shows wrong number of records using the authority Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl You can see the wrong behaviour in a clean sample database with http://localhost:8081/cgi-bin/koha/authorities/detail.pl?authid=133 To test: * Test plan assumes you are using the ktd sample data * Staff interface > authorities * Search for agile * Verfiy the result list shows used by 2 records and this is correct (authority is linked to both of them) * Switch to authority detail page * Verify it shows 3 records use this authority * Verify this is incorrect (the second record is not linked to the authority) I suspect that the detail page doesn't do an exact/phrase search opposed to the other pages, finding also records with similar authority numbers? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 41639] New: OPAC cover images use non-descriptive alt text
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41639 Bug ID: 41639 Summary: OPAC cover images use non-descriptive alt text Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: accessibility Severity: normal Priority: P5 - low Component: Accessibility Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org Cover images displayed in the Koha OPAC currently use generic alt text values such as “Amazon Cover Image” and “Local Cover Image.” These values do not provide a meaningful text alternative for screen reader users and do not meet WCAG 2.2 AA Success Criterion 1.1.1 (Non-text Content). Because OPAC cover images are functional (they are clickable and serve as a visual identifier for bibliographic records), they cannot be considered decorative and therefore require a descriptive text alternative. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 27431] New: ES searches containing words starting with 2 hyphens or only hyphen(s) fail
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27431 Bug ID: 27431 Summary: ES searches containing words starting with 2 hyphens or only hyphen(s) fail Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com On ElasticSearch, query like "(--)", "(-)" or "(--science)" fails. In authority module (authorities-home.pl or auth-finder.pl), searching a term like "Science -- fiction" produce a query that fail: "(Science) AND (--) AND (fiction)" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 25900] New: Double quotes breaks search with Zebra and QueryWeightFields
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25900 Bug ID: 25900 Summary: Double quotes breaks search with Zebra and QueryWeightFields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com Search with Zebra and system preference QueryWeightFields on builds a query with surrounding double quotes : q=tree => q="tree". Therefore existing double quotes are replaced by a space : q="tree" => q=" tree ". Looks like the leading space breaks the search, 0 results. Experimented on Ubuntu Xenial and Bionic with Indexdata repository so Zebra version is 2.1.4. It might be specific to this version. You can reproduce with direct CCL query (regardless QueryWeightFields) : https://demo.biblibre.com/cgi-bin/koha/opac-search.pl?idx=&q=ccl%3Dti%2Cphr… https://demo.biblibre.com/cgi-bin/koha/opac-search.pl?idx=&q=ccl%3Dti%2Cphr… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 30817] New: Make build_authorities_query takes QueryAutoTruncate system preference into account
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30817 Bug ID: 30817 Summary: Make build_authorities_query takes QueryAutoTruncate system preference into account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com Currently authorities search (contains) queries are always truncated using SearchEngine::Elasticsearch::QueryBuilder::_truncate_terms. Truncating queries could have some negative effects on search results (i.e relevance). An interesting test plan could be: - Enable Elasticsearch search engine, - make sure you have some authorities with the following heading-main content: "jean-Charles", "Jean", "Charles", "Jean Foo", "Foo Jean", "Jean Charles" - launch the following search: Main heading contains "jean-Charles" sort by "none" - Authority with heading-main "jean-Charles" should have the highest relevance score. But this is not the case. The score seems to be altered by the wildcard. Patch is coming. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 36925] New: ERM eUsage reports : data table filter does not work
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36925 Bug ID: 36925 Summary: ERM eUsage reports : data table filter does not work Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: michaela.sieber(a)kit.edu CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com The data table filter does not work in the ERM module > eUsage > reports Just Processing... but nothing happens -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 30691] New: ElasticSearch Indexer crashes on authtypecode NAME_EVENT
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30691 Bug ID: 30691 Summary: ElasticSearch Indexer crashes on authtypecode NAME_EVENT 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: domm(a)plix.at When GuessAuthTypeCode encounters a record containing tag 147, it returns 'NAME_EVENT'. But in the default Koha installation, 'NAME_EVENT' is not registered in auth_types: select * from auth_types where authtypecode = 'NAME_EVENT'; Empty set (0.000 sec) This causes a bug in Koha/SearchEngine/Elasticsearch.pm:362, because $field is undefined and then passed on to C4::Heading->new_from_field, which dies: Can't call method "tag" on an undefined value at /usr/share/koha/lib/C4/Heading.pm line 71 A simple fix (will be provided soon) is to just ignore and report such cases (as done a few lines further down in Koha/SearchEngine/Elasticsearch.pm, when there is no $authtypecode. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 36902] New: Blank year fields should not be indexed.
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36902 Bug ID: 36902 Summary: Blank year fields should not be indexed. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se The comment says 'Only accept years containing digits and "u"' but proceeds to also accept fields with blanks: # Only accept years containing digits and "u" push @{$default_options->{value_callbacks}}, sub { my ($value) = @_; # Replace "u" with "0" for sorting return map { s/[u\s]/0/gr } ( $value =~ /[0-9u\s]{4}/g ); }; If the field contains blanks it is either because it is invalid or because the year is missing, so the field should not be indexed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12