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

[Bug 7985] In Checkout, list of items checked out should show Charge from table accountlines
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7985 Lisette Scheer <lisette(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact| |testopia(a)bugs.koha-communit | |y.org --- Comment #6 from Lisette Scheer <lisette(a)bywatersolutions.com> --- Setting empty QA contacts to Default. Some searches don't handle empty QA contact fields well. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 18407] New: REST API: Include renewability information on checkouts
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18407 Bug ID: 18407 Summary: REST API: Include renewability information on checkouts Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org It would be useful to have renewability information directly in the /checkouts endpoint to avoid making additional requests. However, this could be optional. Create /api/v1/checkouts/expanded endpoint to include additional data on checkouts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 35722] New: Item transfer operations should be available from the API
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35722 Bug ID: 35722 Summary: Item transfer operations should be available from the API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com CC: tomascohen(a)gmail.com We don't expose the item transfer queue in the API yet.. we should. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 25408] New: CanBookBeReserved should check "opacitemholds" policy
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25408 Bug ID: 25408 Summary: CanBookBeReserved should check "opacitemholds" policy Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com how to reproduce : Set an issuing rule with opacitemholds set to "Force" Make a search and select multiple records Place a hold on those records (using multi-hold records) Verify hold is placed on the record (next item available) where it shouldn't! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 151

[Bug 41113] New: Missing doc-head-close and cssinclude in sci-main.tt
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41113 Bug ID: 41113 Summary: Missing doc-head-close and cssinclude in sci-main.tt Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: aleisha(a)catalyst.net.nz, alexbuckley(a)catalyst.net.nz, dcook(a)prosentient.com.au, hammat.wele(a)inlibro.com, lucas(a)bywatersolutions.com, testopia(a)bugs.koha-community.org +++ This bug was initially created as a clone of Bug #21266 +++ Many of the some changes should be made to the self checkin templates -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 43675] New: Web installer shows a blank Installed version for outdated Perl modules
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43675 Bug ID: 43675 Summary: Web installer shows a blank Installed version for outdated Perl modules Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- When a required Perl module is installed but below the minimum version Koha needs, the web installer's "Check Perl dependencies" step (installer/install.pl step 1) correctly blocks progress, but the "Installed version:" field on that page is always blank, regardless of what is actually installed. Only "Minimum version:" and "Maximum version:" are populated. For example, with PDF::Reuse 0.39 installed (Koha on this branch requires 0.43, see Bug 41717), the page shows: PDF::Reuse Required Installed version: Minimum version: 0.43 Maximum version: Root cause: installer/install.pl builds the @upgrade array passed to the template with name, min_version, max_version and require, but never includes the installed version (available as cur_ver from C4::Installer::PerlModules::versions_info), even though koha-tmpl/intranet-tmpl/prog/en/modules/installer/step1.tt already expects and displays upgrade_module.version. This patch moves the missing/upgrade module list building (and the checkmodule blocking logic) out of install.pl and into a new C4::Installer::PerlModules::modules_report method, which now includes the installed version for upgrade_pm entries. install.pl becomes a thin caller of this method. This also makes the logic unit-testable, which it was not before (install.pl is a top-level CGI script with side effects, so it could not be exercised directly in a test). Test plan: 1. Apply the patch 2. prove t/Installer_PerlModules.t -- confirm the new modules_report subtest passes, including the 'Installed version of the outdated module is reported' assertion 3. In a KTD instance with an outdated required Perl module (e.g. an older PDF::Reuse than the cpanfile requires), go through the web installer and reach the "Check Perl dependencies" step 4. Confirm the "Installed version:" field for the outdated module now shows the actual installed version instead of being blank 5. Confirm the page still correctly blocks progress (no "Continue" button) when a required module fails the check, same as before -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43569] New: update_index masks per-document ES failures; reindex reports silent success
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43569 Bug ID: 43569 Summary: update_index masks per-document ES failures; reindex reports silent success Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Target Milestone: --- Elasticsearch indexing can silently drop records: update_index() masks per-document bulk failures, and rebuild_elasticsearch.pl reports success even when records fail to index. This is a follow-up to bug 42669, which fixed the es_indexer_daemon.pl silent job failure and NoNodes recovery. That fix only handles thrown exceptions (whole-operation failures). It does not address the case where the ES bulk request returns HTTP 200 but individual documents fail (mapping conflicts, strict_dynamic_mapping_exception, field-too-long, etc.). Those per-item failures are currently swallowed. == Current behavior == Koha::SearchEngine::Elasticsearch::Indexer::update_index(): - On a bulk response with $response->{errors} true, it only carp()s "One or more ElasticSearch errors occurred when indexing documents" and returns the raw response as if successful. - Callers cannot easily tell which records failed or act on them. misc/workers/es_indexer_daemon.pl: - Ignores the update_index() return value entirely; relies only on try/catch for exceptions. A partial bulk failure leaves the batch marked 'finished', so the affected records are silently missing from search. misc/search_tools/rebuild_elasticsearch.pl: - The buffered commit is wrapped in try/catch that only logs and continues; dropped records are never retried. - The final commit (uncommitted tail) is NOT wrapped, so under 'use autodie' an exception there kills the process mid-slice. - _handle_response() prints per-item error detail only at verbosity level 2, and even the summary line is suppressed at the default verbosity used by cron. Reindex cronjobs therefore report success while records fail. - Exit status is always 0, so cron wrappers cannot detect failures. - With --processes, child exit status is not propagated (wait() ignores $?), so a failed slice is invisible to the parent. == Proposed change (two-phase implementation on this bug) == Phase 1: Surface per-document bulk failures. - update_index() returns a Koha::Result::Boolean instead of the raw ES response. False when any bulk item errored; one message per failed record via add_message({ type => 'error', message => reason, payload => { record_id => id, error => ... } }). - Empty-body case returns a true Boolean (removes the current undef return and the undef-deref hazard in callers). - Whole-operation failures (bulk call throws, NoNodes) keep throwing Koha::Exceptions::Elasticsearch::BadResponse, so the daemon NoNodes reset path from bug 42669 stays intact. Exceptions mean "could not run"; the Boolean means "ran, some documents failed". - Migrate callers: * es_indexer_daemon.pl: inspect the Boolean; on false set index_ok = 0 so the batch is marked 'failed' instead of 'finished'. NOTE: this makes previously-hidden partial failures visible as failed jobs (intended). * rebuild_elasticsearch.pl: minimal migration so _handle_response does not break on the new return type (full hardening is Phase 2). * index_records() and bulkmarcimport.pl currently ignore the return; left as-is in Phase 1, noted as optional future work. - Tests: update t/db_dependent/Koha/SearchEngine/Elasticsearch/Indexer.t (the existing update_index assertion) and add all-success, partial-failure, empty-body, and whole-op-throws cases. Phase 2: Harden rebuild_elasticsearch.pl (depends on Phase 1). - Track failed/skipped counts; exit non-zero on any failure so cron wrappers can detect trouble. (Visible behavior change for existing automation.) - Wrap the final commit in the same try/catch as the buffered one, honoring the NoNodes-vs-real-error distinction so a hard outage is not masked as a soft warning under autodie. - Propagate child exit status in the --processes path (children exit non-zero on failure; parent aggregates $? from wait()). - Report fetched vs indexed vs failed vs skipped at the end; the current "Total N records indexed" line overstates success. == Out of scope == Standardizing logging across the ES indexing stack (Carp vs Koha::Logger alignment) will be handled in a separate report. == Open questions for QA == - Should index_records() aggregate and return a combined Boolean, or stay fire-and-forget for now? - Does the daemon 'finished' -> 'failed' semantic shift for partial failures warrant a release note? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 43706] New: Installer and onboarding selenium tests must fail with meaningful error if deps are not satisfied
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43706 Bug ID: 43706 Summary: Installer and onboarding selenium tests must fail with meaningful error if deps are not satisfied Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- They currently fail with an error that hide the real cause of the problem: STRACE: /usr/share/perl5/Try/Tiny.pm:123 in Selenium::Remote::Driver::catch {...} /usr/share/perl5/Selenium/Remote/Driver.pm:361 in Try::Tiny::try (eval 397):1 in Selenium::Remote::Driver::__ANON__ (eval 399):2 in Selenium::Remote::Driver::__ANON__ /usr/share/perl5/Selenium/Remote/Driver.pm:1340 in Selenium::Remote::Driver::_execute_command /usr/share/perl5/Selenium/Remote/Driver.pm:1340 in (eval) t/db_dependent/selenium/00-onboarding.t:108 in Selenium::Remote::Driver::find_element Error while executing command: no such element: Unable to locate element: //div[@class="alert alert-success"] at /usr/share/perl5/Selenium/Remote/Driver.pm line 411. at /usr/share/perl5/Selenium/Remote/Driver.pm line 356. # Looks like your test exited with 255 just after 1. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 43444] New: After logout and immediate login, language selection link takes back to login page
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43444 Bug ID: 43444 Summary: After logout and immediate login, language selection link takes back to login page Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: Macintosh OS: Mac OS Status: NEW Severity: minor Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: esa-pekka.keskitalo(a)helsinki.fi QA Contact: martin.renvoize(a)openfifth.co.uk CC: dpavlin(a)rot13.org Target Milestone: --- Langauge selection link does not work as expected, if one logs out of Koha and soon logs in again using the login page where one was taken when logging out. 1) Go to Koha, the login page URL is a simple www.example.com 2) Login, and you land on page .../cgi-bin/koha/mainpage.pl. Let us assume that the interface is now in English. 3) Look at the link of a language selection for Finnish in bottom bar: it is .../cgi-bin/koha/changelanguage.pl?language=fi-FI&prepost_referer=https%3A%2F%2Fwww.example.com%2F 4) Click the link, and the interface turns into Finnish. 5) Logout, and you land on page that looks like the login page in step 1 but the URL is .../cgi-bin/koha/mainpage.pl?logout.x=1 6) Login, and you again land on page cgi-bin/koha/mainpage.pl. Let us assume that the interface is again in English. 7) Look at the link of a language selection in bottom bar: it is cgi-bin/koha/changelanguage.pl?language=fi-FI&prepost_referer=https%3A%2F%2Fwww.example.com%2Fcgi-bin%2Fkoha%2Fmainpage.pl%3Flogout.x%3D1 8) Click the link, and you are taken to page .../cgi-bin/koha/mainpage.pl?logout.x=1 What is expected is that the interface turns into Finnish. Language selection using the drop down menu works as expected. Generally, I cannot find any other misbehaving links. If one first clicks any other link on .../cgi-bin/koha/mainpage.pl, the language selection link in the bottom bar works as expected, even when coming back to the home page by using Koha's navigation (i.e. not using browser navigation). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 43651] New: Clarify "Expand all" and "Collapse all" link labels in Acquisitions and Funds sections
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43651 Bug ID: 43651 Summary: Clarify "Expand all" and "Collapse all" link labels in Acquisitions and Funds sections Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In the Acquisitions and Funds sections of Koha, there are "Expand all" and "Collapse all" links displayed above the budget table. These links are used to show and hide sub funds. The current labels are too generic and may be misunderstood by users, as they could be interpreted as expanding or collapsing all content on the table rather than specifically sub funds. To make the functionality clearer, the labels should be changed as follows: Expand all → Expand all sub funds Collapse all → Collapse all sub funds Steps to Reproduce: 1. Navigate to the Acquisitions or Funds section in Koha. 2. Locate the "Expand all" and "Collapse all" links above the budget table. 3. Observe that the labels do not clearly indicate that they affect only sub funds -- You are receiving this mail because: You are watching all bug changes.

1 6