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

[Bug 41931] New: While creating EasyAnalitics empty subfields are created
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41931 Bug ID: 41931 Summary: While creating EasyAnalitics empty subfields are created Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: januszop(a)gmail.com Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl While creating EasyAnalitics empty subfields are (often) created. In C4::Biblio::PrepHostMarcField a whole set of subfields is addes to the field 773 regardless if a respective value exists or not. This often creates empty subfields and generates warnings. To reproduce: 1. Set EasyAnalyticalRecords to Show. 2. Go to biblio #1, copy the barcode. 3. Go to biblio #2, chose Edit > Link to host record > enter the barcode. 4. Examine the biblio #2: a) a new "virtual" item from biblio #1 is being displayed; b) a 773 field has been inserted, but with empty subfields $d & $x). 5. There should be warnings in plack-intranet-error.log like: [WARN] Use of uninitialized value in join or string at /usr/share/perl5/MARC/Field.pm line 696. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 42477] New: Suggestions > hold workflow - automatically place a hold from a suggestion
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42477 Bug ID: 42477 Summary: Suggestions > hold workflow - automatically place a hold from a suggestion Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org We would love to see the suggestions workflow link up with the holds workflow so that once a suggestion is changed as 'ordered' this would trigger a script to check for the matching ISBN and then place a title level hold (using the customer details from the suggestion) against the title (using the ISBN as the match). Once a hold is placed the workflow is complete. We'd love to be able to run this script daily so that when the title arrives via our edi orders, a hold is automatically placed and less work for Acquisition staff. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 42420] New: Strings from data-placeholder attributes not translated
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42420 Bug ID: 42420 Summary: Strings from data-placeholder attributes not translated Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: translate.koha-community.org Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com It seems that strings from data-placeholder attributes are not translated in Koha, and they are absent from Pootle. Examples include all "Search by..." placeholders in koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-advsearch.tt. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 35711] New: Compatibility levels before 10 are deprecated
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35711 Bug ID: 35711 Summary: Compatibility levels before 10 are deprecated Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Seeing this when trying to build custom packages: dh clean --fail-missing --with bash-completion dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_auto_clean -O--fail-missing dh_auto_clean: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_clean -O--fail-missing dh_clean: warning: Compatibility levels before 10 are deprecated (level 9 in use) No idea what it means, but see bug 18908 for a similar fix. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 36007] New: Add the ability to batch edit in Course Reserves
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36007 Bug ID: 36007 Summary: Add the ability to batch edit in Course Reserves Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice to have the ability to batch edit in course reserves. A scenario could be, a course is reactivated, the items in the course are the same, but they all need to be relocated for the course is happening at a different branch, or a different reserve location. A batch edit would allow staff to retain the list of items in the course, but easily update the new course reserves values. At this time, each item would need to be individually edited. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

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

09 Oct '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 42

[Bug 37692] New: Self-registration verification cannot be done if OPACPublic is not allowed
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37692 Bug ID: 37692 Summary: Self-registration verification cannot be done if OPACPublic is not allowed Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: olli-antti.kivilahti(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org User needs to be logged in to verify his pending account creation. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 37250] New: Redesign labels home page to match other module home pages
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37250 Bug ID: 37250 Summary: Redesign labels home page to match other module home pages Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org I propose to update the label creator home page so that it has a grid of links like the circulation or cataloging home pages. -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 42744] New: Add Database backend for patron search (denormalized table)
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42744 Bug ID: 42744 Summary: Add Database backend for patron search (denormalized table) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 42508 Adds a zero-dependency Database backend for patron search using a denormalized table (patron_search_index) with MariaDB FULLTEXT indexes. Uses the field-group model: one row per patron per field group, enabling targeted search and weighted relevance. The same search interface as the ES backend, selected via the factory classes. Components: - patron_search_index table (field-group model) - Koha::SearchEngine::Database::Indexer::Patrons - Koha::SearchEngine::Database::Search::Patrons - Koha::SearchEngine::Search::Patrons (factory) - Koha::SearchEngine::Indexer::Patrons (factory) - patron_search_index.pl CLI tool with --backend switch - Integration tests starts_with uses LIKE on borrowers columns directly (fast with indexes). contains uses FULLTEXT BOOLEAN MODE on the index table. Facet filters and library scoping via standard SQL. This provides a patron search solution for installations that cannot deploy Elasticsearch. Depends on bug 42508. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 [Bug 42508] Add Elasticsearch patron search feature -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 42743] New: Support dedicated ES server for the patrons index
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42743 Bug ID: 42743 Summary: Support dedicated ES server for the patrons index 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 42508 Adds support for configuring a separate Elasticsearch server for the patrons index via koha-conf.xml: <elasticsearch> <server>127.0.0.1:9200</server> <index_name>koha_instance</index_name> <patrons_server>patron-es:9200</patrons_server> </elasticsearch> This enables deploying patron data on a dedicated ES cluster for performance isolation or data residency requirements. The configuration is read once in the constructor and the index-specific server overrides the default nodes. Falls back to <server> when no index-specific entry is present. Depends on bug 42508. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 [Bug 42508] Add Elasticsearch patron search feature -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6