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

[Bug 42957] New: On additem.pl clicking on field columns no longer allow Edit/delete
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42957 Bug ID: 42957 Summary: On additem.pl clicking on field columns no longer allow Edit/delete Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: janet.mcgowan(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Created attachment 201352 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201352&action=e… inline column options on Manage items page Clicking ‘Edit’ and ‘Manage items’ from the bibliographic record. In the list of items (at 24.11) it used to be possible to click on a column cell - such as collection code and be presented with Edit item, Delete item options inline. See attachment. This is no longer the case at 25.11 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 21996] SPAM
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21996 Adolfo Rodríguez Taboada <adolfo.rodriguez(a)xercode.es> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42999 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 38412] New: Koha should warn when hold on bibliographic record requires hold policy override
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38412 Bug ID: 38412 Summary: Koha should warn when hold on bibliographic record requires hold policy override 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 35573 When AllowHoldPolicyOverride is set to Allow, Koha will specifically mark items for which an item-level hold will require an override. However, nothing in the interface indicates when the bibliographic level hold will require an override. To recreate: - Have AllowHoldPolicyOverride set to Don't Allow - Have a bib record with just one item - confirm you can place a hold on either the biblio or the item - edit your item such that it become unholdable (mark it Not For Loan or something) - confirm that you cannot place a hold on either the biblio or the item - set AllowHoldPolicyOverride to Allow - confirm that Koha shows an alert on the item indicating that the hold will require an override - confirm that Koha does not indicate the bibliographic level hold will require an override Bug 33573 restored these alerts for items. I don't recall if we've ever had these alerts for biblios. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35573 [Bug 35573] Koha is not correctly warning of overridden items when placing a hold if AllowHoldPolicyOverride -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 5917] Switch Koha to use Template::Toolkit
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5917 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42996 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42996 [Bug 42996] xt/author/show-template-structure.pl is no longer needed -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 37570] New: Add possibility to send request on other url defined by a new syspref SearchAlsoIn
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37570 Bug ID: 37570 Summary: Add possibility to send request on other url defined by a new syspref SearchAlsoIn Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hello Like OPACSearchForTitleIn I would like to purpose you a new syspref "SearchAlsoIn" which adds the possibility of defining urls to launch the query on other sites. This can be added on both sides (personal pages and OPAC results pages). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 42634] New: Self-checkout Finish/logout does not reliably clear the JWT cookie
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42634 Bug ID: 42634 Summary: Self-checkout Finish/logout does not reliably clear the JWT cookie Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org On the web-based self-checkout (opac/sco/sco-main.pl), clicking the Finish/close button on the kiosk does not reliably end the patron session. The JS redirects the browser to ?op=logout, but the server-side response does not actually delete the JWT cookie - it emits an empty value with no Expires attribute, so the browser keeps a session-scoped empty cookie (or, in some intermediary/cache scenarios, retains the previous valid JWT). The patron remains logged in until the cookie genuinely expires, which presents as the Finish button "doing nothing" or working only intermittently. In opac/sco/sco-main.pl the Set-Cookie for JWT on logout is built as: -value => \$jwt // '', -expires => \$jwt ? '+1d' : '', Empty -expires produces a session cookie with an empty value rather than a deletion. The standard pattern for clearing a cookie is a past Expires, e.g. '-1d'. Test plan: 1. Enable web-based self-checkout (SelfCheckoutByLogin or IP-range). 2. Log in as a patron at /cgi-bin/koha/sco/sco-main.pl. 3. Open browser DevTools -> Application -> Cookies. Note the JWT cookie value. 4. Click the green "Finish" button. 5. Without the patch: observe Set-Cookie: JWT= on the ?op=logout response with no Expires; the JWT cookie may persist or be replaced with an empty session cookie that some browsers/proxies handle inconsistently. 6. Apply the patch and reload. Click Finish again. 7. Confirm Set-Cookie: JWT=; expires=<past>; ... is sent and the JWT cookie is removed from the browser entirely. 8. Confirm the kiosk reliably returns to the login screen and the next page load does not re-authenticate from a stale JWT. Sponsored-by: OpenFifth (Ticket #246176, John Innes Centre) -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 17748] New: Show due date and availability in item search results
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17748 Bug ID: 17748 Summary: Show due date and availability in item search results Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com After searching an item, i. e. with barcode, you can't see wheter it is checked out or not. Therefore the due date and / or the availability of the item would be very helpful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61

[Bug 42952] New: Public SRU with OPAC logic out-of-the-box
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42952 Bug ID: 42952 Summary: Public SRU with OPAC logic out-of-the-box Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- While working with Terry Reese to fix the MarcEdit integration with Koha, he pointed out that Koha doesn't have a public Z39.50/SRU endpoint out of the box. I think the reasoning previously has been that the z3950responder.pl and Zebra provide unfiltered access to the indexes. But... with the z3950responder.pl we could provide a more mediated access. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 31606] New: Enhance acquisitions to allow ordering on next year's budget when still in current year.
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31606 Bug ID: 31606 Summary: Enhance acquisitions to allow ordering on next year's budget when still in current year. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: rkuiper(a)roundrocktexas.gov QA Contact: testopia(a)bugs.koha-community.org Created attachment 140860 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140860&action=e… Full description of problem of end-of-year processing & possible solution. The topic of end-of-year processing has come up regularly in the koha-us Acquisitions SIG. Librarians would like to have a way to order things for the next year when still in the current year and have the items showing up on the next year's budget. Example: our library has a fiscal year that goes from Oct 1 to Sept 30. A popular book will release October 15. We want to order the book in August. We would like to have the item ordered on the new fiscal year starting October. How do we do that? I have attached a Word document that more fully explains the issue and I have suggested a solution that I think will work for both EDI and non-EDI vendors. Please look over the solution and share any problems or improvements. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 61

[Bug 42994] New: Atomic update for Bug 40658 (local-number sortable) fails on Zebra-only installations
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '26

05 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42994 Bug ID: 42994 Summary: Atomic update for Bug 40658 (local-number sortable) fails on Zebra-only installations Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: dghdghfghfgh04(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- The atomic update script that implements Bug 40658 ("Ensure local-number is sortable"), located at installer/data/mysql/db_revs/251104011.pl (25.11.x) / equivalent on main, unconditionally instantiates the Elasticsearch indexer and calls update_mappings(), regardless of the SearchEngine system preference: my $index_name = $Koha::SearchEngine::Elasticsearch::BIBLIOS_INDEX; my $indexer = Koha::SearchEngine::Elasticsearch::Indexer->new( { index => $index_name } ); $indexer->update_mappings(); On a Zebra-only installation with no Elasticsearch server configured or running, this call fails, and koha-upgrade-schema / updatedatabase aborts partway through the atomic update with: ERROR: Exception 'Koha::Exception' thrown 'Unable to update mappings for index "koha_<instance>_biblios". Reason was: "". Index needs to be recreated and reindexed' accompanied by: Use of uninitialized value $reason in concatenation (.) or string at /usr/share/koha/lib/Koha/SearchEngine/Elasticsearch/Indexer.pm line 276. The "Reason was: ''" text and "Index needs to be recreated and reindexed" wording are misleading — they suggest a mapping conflict on an existing index. In practice, the failure occurs even when there is no Elasticsearch server reachable at all (verified via `ss -tlnp | grep 9200`, `curl` returning connection refused/000, and no elasticsearch systemd unit present). The root cause is that $reason in Indexer.pm (line 276) is never populated with the actual underlying error (connection failure, mapping conflict, or otherwise), so all failure modes are reported identically and misdirect troubleshooting toward index/mapping issues rather than connectivity. Steps to reproduce: 1. Set up or use an existing Koha instance with: - SearchEngine system preference = Zebra - No Elasticsearch server configured/running 2. Run koha-upgrade-schema <instance> (or updatedatabase.pl) up to/through the 40658 atomic update. 3. Observe the exception above; the upgrade halts. Expected behavior: The atomic update should check the SearchEngine system preference before attempting any Elasticsearch operations, e.g.: if ( C4::Context->preference('SearchEngine') eq 'Elasticsearch' ) { # existing ES mapping update logic } else { say_info($out, "Zebra in use: skipping Elasticsearch mapping update"); } The underlying database change (search_marc_to_field.sort = 1 for the local-number field) should still be applied regardless of search engine, since that part is search-engine-agnostic and succeeds independently of the ES call. Additionally, Indexer.pm line 276 should be fixed so that $reason is actually populated from the underlying exception/error, rather than being left uninitialized — this would have surfaced the real cause (connection failure) immediately instead of a misleading mapping-conflict message. Workaround used: 1. Manually verified and applied the DB-only change: UPDATE search_marc_to_field SET sort = 1 WHERE search_marc_map_id = <id for local-number/biblios/marc21>; 2. Patched the local copy of the atomic update script to skip the Elasticsearch call when SearchEngine != 'Elasticsearch'. 3. Re-ran the schema upgrade successfully. Note: this workaround needs to be reapplied after any package upgrade that overwrites the vendored atomic update script, until this is fixed upstream. Related: Bug 40658 (this report is about the atomic update script it introduced, not the local-number__sort fix itself, which is unrelated and working as intended). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1