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

[Bug 41982] New: Linked items resulting from EasyAnalyticalRecords are not shown on OPAC results page
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41982 Bug ID: 41982 Summary: Linked items resulting from EasyAnalyticalRecords are not shown on OPAC results page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When using EasyAnalyticalRecords, "virtual" items originating from host records are shown in: 1) staff detail, 2) staff results, 3) OPAC detail, but not on OPAC results page. To reproduce (in ktd): 1) Turn EasyAnalyticalRecords on. 2) Link the item 3999900000001 (originating from biblio #1) to biblio #2 (with New > Link to host record). 3) Check that you are able to see the linked item in staff detail and OPAC detail (biblio record #2) and also on the staff results page (make a search with the word 'behind'). Verify that on the OPAC results page (with the same search) you get: "Availability: No items available." This is confusing and inconsistent. -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 39419] New: Holds API treats 'expiration_date' as 'patron_expiration_date'
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39419 Bug ID: 39419 Summary: Holds API treats 'expiration_date' as 'patron_expiration_date' Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is going to have a related issue in Aspen, but I think the confusion starts here Koha has two fields for hold expiration: expirationdate - (usually) auto generated date set based no when holds on the shelf expire patron_exiration_date - the day the patron says they don't need the hold after The API takes "expiration_date" and maps it to "patron_expiration_date" This can be unclear for outside systems. Aspen has a 'Default Not Needed After Days' setting which is assumed to be setting the automatic expiraton date, but in fact sets the patron date We should allow either field to be set via the API -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 110

[Bug 39160] New: Mojolicious::Plugin::OAuth2 is loaded suboptimally
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39160 Bug ID: 39160 Summary: Mojolicious::Plugin::OAuth2 is loaded suboptimally Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial 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 This is a deep cut, but the following line is not optimal: $self->plugin( 'Mojolicious::Plugin::OAuth2' => $oauth_configuration ); Mojolicious will first try to load that as Mojolicious::Plugin::Mojolicious::Plugin::OAuth2 before it realises that we've already loaded Mojolicious::Plugin::OAuth2 earlier in Koha::REST::V1. I reckon that should say: $self->plugin( 'OAuth2' => $oauth_configuration ); -- In the grand scheme of things, it's not a big deal, but we can save ourselves 26 system calls by changing 1 line. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 32542] New: Coce images not appearing in staff client
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32542 Bug ID: 32542 Summary: Coce images not appearing in staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1. Have Coce on, use 'https://coce.bywatersolututions.com' as the CoceProviders if needed. Select all providers 2. Turn on IntranetCoce and OpacCoce. 3. Do a OPAC search to retrieve some Coce images on both the OPAC results page and detail. 4. Do the same search and look at the same detail pages in the staff client. Nothing appears. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45

[Bug 38181] New: Extreme slow search results on OPAC (only) search when result records contain multiple items.
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38181 Bug ID: 38181 Summary: Extreme slow search results on OPAC (only) search when result records contain multiple items. Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: kdask(a)altsol.gr QA Contact: testopia(a)bugs.koha-community.org When performing a search on the OPAC, if the results containing records that are having a large number of holdings (e.g serials with over 1000 issues/items or even less) there is a huge delay on showing the results (~x8 times slower for the same search if we remove the multiple items from the resulting records) The odd is that the exact same search on the intranet interface works without these delays so I'm guessing that this is a problem on the OPAC search implementation? The problem exists with zebra but also with the use of Elasticsearch engine. Using elasticsearch tried also removing all the item related indexes - 952* subfields (and re-indexing) but the result is the same. In the following google drive link you can find a demo bib record with 1809 items (MarcXML - Marc21) if it helps to reproduce it.https://drive.google.com/file/d/11SQmfdWal9tzcovS0mrgu6vIOPf1aCbc/view You will have to import the record, and then try searching for the title on OPAC: The Journal of biological chemistry. In my case with a decent server without load (Debian, 4cpu cores, 16gb RAM) with plack enabled takes about ~50sec to get the result. Regards -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 50

[Bug 40146] New: Untranslatable actions on vendor
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40146 Bug ID: 40146 Summary: Untranslatable actions on vendor Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: inkeri.hakulinen+bugz(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org Missing translations on some acquisitions-related words in version 25.05 1. Choose some language other than English 2. Go to Acquisitions 3. Search for a vendor and choose one. 4. When on vendor page, choose dropdown-menu from "+New" 5. You see following options: "Basket"*, "Contract"* and "Vendor". The two first are always in English, though "Vendor" is translated". In Finnish Koha community, we couldn't find an untranslated phrase from Weblate for the begininning of the dropdown-menu. I also tested Admin Kuhn's demo Koha 25.05 at https://koha-community.org/demo/ They have English and German languages installed there, but these translations were missing from there, too. Can someone please add these terms to be translatable? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 36506] New: Processing Fee should be configurable by branch
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36506 Bug ID: 36506 Summary: Processing Fee should be configurable by branch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In a consortia environment, some branches might want a process fee and others might not. This could be worked around with multiple item types, but that can cause other issues. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 76

[Bug 41758] New: Add Fingerprint Identifier data to Elasticsearch index mappings
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41758 Bug ID: 41758 Summary: Add Fingerprint Identifier data to Elasticsearch index mappings Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: januszop(a)gmail.com Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Libraries cataloguing older monographic resources request fingerprint indexing. In MARC 21, it would be the content of field 026, in UNIMARC - 012. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 42722] New: Improve invalidPickupBranch error message
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42722 Bug ID: 42722 Summary: Improve invalidPickupBranch error message Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com See Bug 41879 which fixes an issue where a hold can be moved to a bib owned by a branch that doesn't allow pickup at the original hold pickup location. The current error message reads: "Target item/record is an invalid pickup location". This is a bit awkward as it says the item/record _is_ a location. I'll brainstorm some other possibilities below. "Target item/record would have an invalid pickup location" "Hold is unable to be fulfilled using its original pickup location" Or something that tells you how to address the underlying issue? "Target item/record would have an invalid pickup location. Please move the hold to a different item/bib or change the pickup location of the hold to a valid one." I realize the last is the most verbose, but I do like the idea of providing solutions with the error message. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 42685] New: Capitalization: Supplying Agency Request ID and others
by bugzilla-daemon＠bugs.koha-community.org 29 Oct '26

29 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42685 Bug ID: 42685 Summary: Capitalization: Supplying Agency Request ID and others Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Found while translating main: Supplying Agency Request ID koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:940 Requesting Agency koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:947 Requesting Agencies koha-tmpl/intranet-tmpl/prog/js/vue/routes/ill.js:73 Requesting Agency Request ID koha-tmpl/intranet-tmpl/prog/js/vue/components/ILL/SupplyingResource.vue:1000 -- You are receiving this mail because: You are watching all bug changes.

1 29