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

[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 43714] New: stockrotation.pl runs out for memory when rotas have too many ites
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43714 Bug ID: 43714 Summary: stockrotation.pl runs out for memory when rotas have too many ites Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- To recreate: 0. Enable StockRotation 1. Add a rota 2. Give the rota at least 2 stages 3. The rota needs lots of items, 1500+ ( i will add a small script to help build this ) 4. Got Cataloging -> Manage -> Items for that rota 5. The page will not load, or it will take a very long time to do so. ( in KTD with my hardware, my laptop crashed at 2x at this step ) 6. Eventually in the plack logs I see: Child process 3370045 exited with status 1 Out of memory! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[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

[Bug 35937] New: Add hourly support to Bookings
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '26

05 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35937 Bug ID: 35937 Summary: Add hourly support to Bookings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 29002 Bug 29002 adds the ability to book items ahead of time. It works at the daily loan level, but stores hours with the intention of expanding it to support hourly bookings. We should expose these hourly bookings as an option to end users. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002 [Bug 29002] Add ability to book items ahead of time -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 04 Oct '26

04 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 Philip Orr <philip.orr(a)lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff --- Comment #170 from Philip Orr <philip.orr(a)lmscloud.de> --- Hi Thibaud, I wanted to try a signoff but the newest addition (203407 - (follow-up) Fix QA test failures) seems to not apply. I get the following: ´´´ Error: Apply failed: Git command (git am -3 /tmp/p44q0MwO5a/0004-203407.patch) failed: error: sha1 information is lacking or useless (Koha/CirculationRules.pm). error: could not build fake ancestor ``` -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40258] New: Option to only use item-level recalls and disable record-level recalls
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '26

03 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40258 Bug ID: 40258 Summary: Option to only use item-level recalls and disable record-level recalls Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be good to essentially hide the "Recall next available item" options for libraries who do not want record-level recalls -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19