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

[Bug 38194] New: Silence console warning about missing .map files
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38194 Bug ID: 38194 Summary: Silence console warning about missing .map files Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Bug 26471 has resurfaced following a DataTables upgrade, and now we have a warning in the console from Bootstrap too: Source map error: request failed with status 404 Resource URL: http://127.0.0.1:8081/intranet-tmpl/lib/bootstrap/bootstrap.bundle.min_24.0… Source Map URL: bootstrap.bundle.min.js.map -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 39756] New: Long overdue cron configuration page
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39756 Bug ID: 39756 Summary: Long overdue cron configuration page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: chloe.zermatten(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Add the configuration for the long overdue cron to the Koha staff interface so that library administrators can makes changes to the long overdue cron settings without needing to use terminal commands or request assistance to do so. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 41294] New: Data not available for certain months should not result in a complete failure of the harvest
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41294 Bug ID: 41294 Summary: Data not available for certain months should not result in a complete failure of the harvest Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk I don't know if it's related to the SUSHI protocol itself (in that case there is nothing to do...) or to Koha, but it's annoying. Ex : for a data source if you try to harvest march and april 2025, and april data are not available, the harvest will fail with this error : Sushi harvesting return an error if some months are not available : Usage Not Ready for Requested Dates - Usage not yet released for the following yearmonths(s): 202504 3031 -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 43710] New: OPAC self-registration crashes with 500 if an attribute type is mandatory+opac_editable but not opac_mandatory
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43710 Bug ID: 43710 Summary: OPAC self-registration crashes with 500 if an attribute type is mandatory+opac_editable but not opac_mandatory 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: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- If a patron attribute type is configured with mandatory=1 and opac_editable=1 but opac_mandatory=0, OPAC self-registration crashes with an uncaught-exception 500 instead of completing. Root cause: opac/opac-memberentry.pl's own CheckMandatoryAttributes() only checks the opac_mandatory flag to decide which fields to require on the registration form. But Koha::Patron->extended_attributes()'s internal mandatory check (Koha/Patron.pm, ~line 2884) uses mandatory + opac_editable instead, and ignores opac_mandatory entirely: if ( $interface eq 'opac' ) { $params->{opac_editable} = 1; } my @required_attribute_types = Koha::Patron::Attribute::Types->search( $params, ... )->get_column('code'); So a type with mandatory=1, opac_editable=1, opac_mandatory=0 is never required by the OPAC form, but IS required by extended_attributes()'s own check. If the patron leaves it blank, Koha::Exceptions::Patron::MissingMandatoryExtendedAttribute is thrown at opac/opac-memberentry.pl's call to $patron->extended_attributes($attributes), which is not caught, and the request dies with a 500. By that point the Koha::Patron row has already been created and stored (a few lines earlier); only the extended-attributes save fails, and that save is wrapped in a DBIx::Class txn_do, so the failure rolls back cleanly with no partially-saved attributes. The account itself is valid — only the attribute type configuration is inconsistent. Steps to reproduce: 1. Administration > Patron attribute types: create or edit a type with Mandatory checked, OPAC editable checked, OPAC mandatory NOT checked. 2. With PatronSelfRegistrationVerifyByEmail disabled, register a new patron via the OPAC self-registration form, leaving that attribute blank. 3. The request crashes with an uncaught-exception 500 instead of completing registration. Proposed fix: wrap the $patron->extended_attributes($attributes) call in opac-memberentry.pl in a try/catch. On Koha::Exceptions::Patron::MissingMandatoryExtendedAttribute specifically, log a warning identifying the misconfigured attribute type and let registration complete normally (the account is already valid) instead of crashing. Other exception types are re-thrown unchanged. Note: an earlier internal write-up of this issue assumed the OPAC form and extended_attributes() disagreed on mandatory+opac_editable directly, but current main already guards that combination via the opac_editable filter above — the actual remaining gap is specifically the opac_mandatory vs mandatory+opac_editable mismatch described here. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 43758] New: Accessibility: Add missing legend to login form fieldset in OPAC
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43758 Bug ID: 43758 Summary: Accessibility: Add missing legend to login form fieldset in OPAC Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org Target Milestone: --- The login form contains a <fieldset> without a corresponding <legend> element. Accessibility testing reports: Fieldset missing legend A fieldset does not have a legend. The affected markup is: <fieldset class="action"> <input type="hidden" name="login_op" value="cud-login"> <input type="submit" value="Log in" class="btn btn-primary"> </fieldset> A <fieldset> should have a <legend> that describes the group of form controls it contains. Without a legend, assistive technologies may not have an accessible description for the grouped controls. Since this fieldset appears to contain only a hidden input and the "Log in" submit button, we should also determine whether a <fieldset> is semantically necessary here. If it is needed, an appropriate <legend> should be added. Otherwise, the fieldset could potentially be replaced with a non-semantic container. Steps to reproduce Navigate to the login page. Run an accessibility check using WAVE or another accessibility testing tool. Inspect the login form. Observe that the <fieldset class="action"> element does not contain a <legend>. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 43150] New: Deleting holidays on range may sometimes delete too many holidays
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43150 Bug ID: 43150 Summary: Deleting holidays on range may sometimes delete too many holidays Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Noticed while working on bug 24782. When modifying holidays on range sometimes those modifications would seep into other holidays that aren't on given timeperiod. Tested some more and this can also happen with deleting holidays on range too. This really tricky to reproduce and it doesn't occur all the time, but here's one way to make this happen. 1. Make sure you have plack running. 2. Create three single holidays on a range. 3. Now delete last two of the just added holidays, use " Delete the single holidays on a range." tool. => Note that all holidays were deleted. => Add holidays for different timeperiods and delete them, note how deleting may affect holidays out of given timeperiod. We had a same problem with adding new holidays and it was fixed on bug 38357. This seems to be a same problem, @holiday_list is not reseted to an empty array so previously created/deleted/modif holidays are never cleared from plack workers memory. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 43486] New: Add permission-gated patron notification info to the checkin hold.patron embed
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43486 Bug ID: 43486 Summary: Add permission-gated patron notification info to the checkin hold.patron embed Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Blocks: 42383 Target Milestone: --- The checkin REST API (bug 24401) can embed the hold's patron via hold.patron, and the Vue checkin page (bug 42383) uses it to render the "Hold found" dialog. Two things are missing compared to the legacy returns.pl dialog: * The embedded patron is not gated by patron-information visibility. The staff interface hides patron identity when the logged-in user can_see_patrons_from() the patron's library returns false (the borrowers => view_borrower_infos_from_any_libraries permission and the ft_hide_patron_info library group feature). The API embed should honour the same rule and redact the patron when the operator may not see it. * There is no way to know, from the API, whether the patron will be notified about the waiting hold and through which method ("Patron is not notified." / "Main contact method:" in returns.pl), because the patron's messaging preferences are not exposed. This bug adds a permission-gated notification summary to the patron as exposed through the checkin embeds, so consumers (starting with the Vue checkin page) can display the same information the legacy page does without leaking patron data. Test plan: 1. Have a waiting-hold-on-checkin scenario for a patron 2. As a user who can see the patron, GET the checkin availability / POST the checkin with the hold.patron embed => SUCCESS: the response includes the patron notification summary 3. As a user who cannot see patrons from that library (view_borrower_infos_from_any_libraries not held, ft_hide_patron_info group), repeat => SUCCESS: the patron identity/notification data is redacted 4. Sign off :-D Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42383 [Bug 42383] Migrate check-in page to Vue -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 43790] New: EDIFACT messages Import button always runs the invoice importer, even for quotes
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43790 Bug ID: 43790 Summary: EDIFACT messages Import button always runs the invoice importer, even for quotes Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The EDIFACT messages page (acqui/edifactmsgs.pl) shows an Import button for any message whose status is 'new', whatever its type, and op=import always calls process_invoice(). The button was added by Bug 23682 for invoices when EdifactInvoiceImport is set to 'manual', but nothing restricts it to invoices. If an inbound QUOTE (or ORDRSP) is left at status 'new' -- for example because edi_cron.pl did not get as far as processing it -- the button appears and clicking it runs the invoice importer on the quote. Quote lines carry RFF+QLI rather than RFF+LI, so every line is skipped with "Skipped invoice line N, missing ordernumber" in the EDI errors, an empty aqinvoices row is created for the quote's BGM document number on every click, and the message is marked 'received' without ever creating a basket. Further problems in the same code path: - op=import is a GET link rather than a cud- POST with a CSRF token, unlike the Delete button next to it. - The script does not check the message is still 'new', so a repeated or stale request imports it again and creates duplicate invoice headers. Proposed fix: offer Import for any unprocessed inbound message (QUOTE, INVOICE, ORDRSP) and dispatch on message_type to process_quote, process_invoice or process_ordrsp via a new Koha::EDI::process_message. Outbound ORDERS messages are not importable. Make the action a cud-import POST with CSRF token and only act on messages still in status 'new'. Test plan: 1. Enable EDIFACT. Insert (or download) an EDI message of type QUOTE with a valid quote in raw_msg, status 'new', for a vendor with an EDI account. 2. Go to Acquisitions > EDIFACT messages. 3. Without the patch: click Import. The invoice importer runs: an aqinvoices row is created, "missing ordernumber" errors are recorded and no basket exists. 4. Restore the message to status 'new' and apply the patch. 5. Reload: Import is shown for QUOTE, INVOICE and ORDRSP messages with status 'new' and not for ORDERS or already processed messages. 6. Click Import on the QUOTE: a basket is created from the quote and no invoice or error rows are created. Check an INVOICE (manual import mode) and an ORDRSP are processed by their own importer as well. 7. prove t/db_dependent/Koha/EDI.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 43435] New: opac-detail.pl crashes with "Can't call method itemtype on an undefined value" — repeated occurrences correlate with Starman worker panics (fold_constants JMPENV_PUSH) and worker process death
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43435 Bug ID: 43435 Summary: opac-detail.pl crashes with "Can't call method itemtype on an undefined value" — repeated occurrences correlate with Starman worker panics (fold_constants JMPENV_PUSH) and worker process death Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: HP OS: Linux Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: rafiqur83(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 204573 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204573&action=e… opac-detail.pl crashes with "Can't call method itemtype on an undefined value" — repeated occurrences correlate with Starman worker panics (fold_constants JMPENV_PUSH) and worker process death We are running Koha 25.11.04.000 in production and are experiencing a recurring, ongoing issue where OPAC requests to opac-detail.pl trigger a Perl runtime error, and — when this error coincides with a Plack/Starman graceful shutdown signal (e.g. from log rotation, worker recycling via max_requests, or a manual/automated restart) — the affected worker child processes crash with a low-level Perl interpreter panic instead of shutting down cleanly. This causes our Starman worker pool to gradually shrink over time (sometimes down to 0-1 active workers out of a configured 6), resulting in severe OPAC slowness/unavailability until Plack is manually or automatically restarted. Error 1 — recurring, very frequent (multiple times per hour under normal traffic) Can't call method "itemtype" on an undefined value at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 749. We have NOT been able to isolate this to one specific biblionumber or item record: item-level_itypes system preference = 1 (item-level, not biblio-level) No items found with NULL/empty itype (checked via SQL) Only 2 biblio records had NULL biblioitems.itemtype (21729, 31981) — expected/normal since item-level_itypes=1 Correlating access logs against error log timestamps did not reliably identify a single problem record; the error occurs across many different requests over time, suggesting it may be triggered by a specific (but not-yet-identified) data condition (e.g. an item with missing/orphaned data referenced transiently, or a race condition in item retrieval) rather than one permanently broken record. We would appreciate guidance on what conditions cause an item object to be undefined at opac-detail.pl line 749, so we can identify the underlying data issue on our end, and suggest the code add a definedness check before calling ->itemtype to avoid the fatal error regardless of data condition. Error 2 — Perl interpreter panic, occurs specifically when a shutdown/restart signal arrives during request handling panic: fold_constants JMPENV_PUSH returned 2. panic: gen_constant_list JMPENV_PUSH returned 2. Child process XXXXX exited with status 29 Sample from our plack-error.log (timestamps redacted for brevity, full log available on request): 2026/09/01-09:48:27 Received QUIT. Running a graceful shutdown Sending children hup signal panic: fold_constants JMPENV_PUSH returned 2. panic: fold_constants JMPENV_PUSH returned 2. panic: fold_constants JMPENV_PUSH returned 2. panic: fold_constants JMPENV_PUSH returned 2. Child process 8344 exited with status 29 Child process 8343 exited with status 29 Child process 8347 exited with status 29 Child process 8345 exited with status 29 2026/09/01-09:48:27 Worker processes cleaned up 2026/09/01-09:48:27 Server closing! This panic appears to occur when Starman sends a QUIT/graceful-shutdown signal to workers while a worker is in the middle of handling a request that would otherwise trigger the "itemtype on undefined value" error above (or similar warning/exception). Instead of a clean shutdown, the child process panics and exits with an abnormal status (4 or 29), rather than completing its current request and exiting normally. Observed effect Because our environment restarts Plack periodically (via our own monitoring script when worker count drops, and previously via routine log rotation / max_requests recycling), the panic gets triggered repeatedly throughout the day, each time killing multiple worker children simultaneously. Over hours, this depletes the worker pool faster than it can be replenished, causing severe performance degradation for library patrons. Steps to Reproduce Run Koha 25.11.04.000 under Plack/Starman with max_requests set (we use 60; also reproduced with 200 and 1000) Allow normal OPAC browsing traffic (including search engine/social media crawlers hitting opac-detail.pl for various biblionumbers) to occur At some point, the "Can't call method itemtype on an undefined value" error will appear in plack-error.log for some biblionumber (we have not found a 100% reliable manual reproduction step — it appears data/record-dependent and we could not pin down the exact triggering record despite investigation) If a Plack restart (graceful QUIT signal) occurs at approximately the same time as one of these errors is being processed by a worker, that worker (and often several others active at that moment) will panic with fold_constants JMPENV_PUSH returned 2 instead of shutting down gracefully Expected behavior opac-detail.pl should not throw a fatal "Can't call method itemtype on an undefined value" error for any valid request — it should handle missing/undefined item data gracefully (e.g., skip display of item-level details, or show a "not available" message) rather than crashing the whole request. A graceful shutdown signal (QUIT) arriving during request/error handling should never cause a Perl-level panic that kills the worker process abnormally. Actual behavior opac-detail.pl fatally errors on line 749 for certain (unidentified) records/requests. When a shutdown signal coincides with this error being raised, the worker process panics and dies abnormally (exit status 4 or 29) instead of shutting down cleanly, contributing to a shrinking worker pool over time. Environment Koha version: 25.11.04.000 OS version (uname -a): Linux localhost 6.12.100+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.100-1 (2026-07-30) x86_64 Perl interpreter: /usr/bin/perl Perl version: 5.040001 MySQL version: 11.8.6-MariaDB-0+deb13u1 from Debian Apache version: Apache/2.4.68 (Debian) PSGI: Plack (deployment) Zebra version: Zebra 2.2.8, Using ICU Message broker: RabbitMQ Plack configuration: plack_workers: 6 plack_max_requests: 60 (also reproduced at 200 and 1000) Additional notes We suspect this may be related to running on a relatively new/bleeding-edge stack (Perl 5.40.1 on Debian 13 "Trixie") — the fold_constants JMPENV_PUSH panic is a historically rare Perl-core-level issue previously seen with older Perl+Plack/Starman combinations; we are not certain if it is specific to Perl 5.40 or triggered by something in Koha's exception-handling path. We are happy to provide additional diagnostic information, full log excerpts, or test on our instance if that would help narrow down the root cause. This is a production library catalog (OPAC) serving real patrons, so we would appreciate any guidance on a temporary code-level workaround (e.g., a defensive if (defined $item) check around line 749) while a permanent fix is developed. Thank you for your time reviewing this report. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 34671] New: Collapsing fields in patron form allows saving without mandatory fields
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34671 Bug ID: 34671 Summary: Collapsing fields in patron form allows saving without mandatory fields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We've had cases where user has been able to save patron without address. It turned out that if one collapses patron entry fields validating those fields no longer works even if they are marked as mandatory. To reproduce: 1. Make sure you have "Main address" fields set as mandatory with BorrowerMandatoryField syspref (address, city, zipcode) 2. Add new patron, fill in some info, but leave "Main address" fields empty. 3. Attempt to save. => "This field is mandatory" should be displayed next to the address fields. 4. Collapse "Main address" section. 5. Attempt to save again. => Patron is saved successfully without address information. I'm using address section as an example here, but this happens with every other fields as well. I was able to save patron without surname and date of birth this way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 69