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

[Bug 42351] New: Add header for tracing API requests
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42351 Bug ID: 42351 Summary: Add header for tracing API requests 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com For debugging purposes, it would be useful to have Koha generate a UUID and send it in a header with each API request. It seems that X-Request-ID is a commonly used header. It might be useful to also send a header that indicates that Koha itself is making the request since X-Request-ID may imply that, but isn't explicit. Maybe we add an X-Koha-Origin header with a value of "koha", or maybe a single header with a more Koha-specific name like X-Koha-Request-ID. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 42375] New: Add OpenTelemetry to Koha
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42375 Bug ID: 42375 Summary: Add OpenTelemetry to Koha Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We should add option support for OpenTelemetry instrumentation to Koha for tracing, metrics, and observability. Koha has no request-level observability. When a page is slow or a SIP connection hangs, the only option is manually correlating timestamps across Apache logs, Plack logs, MySQL slow-query logs, and syslog. This is painful, cumbersome, and often inaccurate or impossible. For example, the apache and plack logs aren't written to until the process is complete, so we can't use that to know which process/request has gone haywire and had to be killed. The closest we've come is to use strace to try divining what the process was doing based on the SQL queries we see in the strace output. Scripts can silently trigger hundreds ( or even hundreds of thousands ) of SQL queries for a single request. Without per-request profiling in production, these can go unnoticed until they cause outages ( Bug 42373 is an example of that ). Starman worker memory leaks and pool exhaustion are diagnosed post-mortem, not proactively. SIP2 is a black box. No per-message latency, no pool utilization metrics, and no trace linking SIP operations to underlying DB calls. Existing profiling tools (NYTProf et al) can't be used in production. Ideas: * Koha::Middleware::OpenTelemetry — Plack middleware creating a root span per request with HTTP semantic convention attributes plus Koha-specific context (koha.instance, koha.interface, koha.borrowernumber). Gated behind an OpenTelemetryEnabled system preference — zero cost when off. * DBI/DBIC span wrapping — child spans for database calls with query counts, timing, and sanitized statements. * Subsystem instrumentation SIP2, connex, background jobs, external HTTP calls. * External stuff like memcached, elastic, zebra, etc? Need to see what's out there for monitoring these already. * RED metrics per interface, worker pool gauges, connection pool utilization for plack/starman, sip, et al All configuration should follow standard OTel environment variables (OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_TRACES_SAMPLER, etc.). We might even add OpenMetrics support if necessary, but I think OpenTelemetry is a good first step. OpenTelemtry creates metrics, but OpenMetrics does not do things like observability. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 42593] New: Add ability for background reports ( and saved reports ) output to be stored on the filesystem instead of the database
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42593 Bug ID: 42593 Summary: Add ability for background reports ( and saved reports ) output to be stored on the filesystem instead of the database Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Reports can output any amount of data which is now currently stored in the database. It seems like a good idea to be able to store that output on the filesystem instead of in the database. Maybe with a syspref for "never/always/ask" or something along those lines. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 42358] New: Add support to Plack::Middleware::SizeLimit
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42358 Bug ID: 42358 Summary: Add support to Plack::Middleware::SizeLimit Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It seems like Plack::Middleware::SizeLimit would be useful to allow higher max requests while keeping memory usage down. It should be implemented in an optional manner. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 43116] New: Repeatable Settings Not Retained When Updating Subfield Order in Frameworks
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43116 Bug ID: 43116 Summary: Repeatable Settings Not Retained When Updating Subfield Order in Frameworks Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: PC OS: Windows Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: mspinney(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 202192 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202192&action=e… Shows the incorrect repeatable settings for MARC Tag 376 after subfields 4 and i were moved The repeatable settings for subfields in frameworks do not update correctly after dragging and dropping them into a new order. This could cause data loss if a subfield is improperly kept as not repeatable. Koha should only update a subfield's repeatable setting when it's edited. To recreate: 1. View the constraints column for the specific MARC tag in the framework you are about to edit, e.g. MARC21 Update 41 from Bug #41702. Note which subfields are repeatable and which are not repeatable. 2. Add the new subfields and save. Note that the new subfields have been appended to the bottom of the list, and all repeatable settings are still correct in the constraints column. 3. Drag and drop the new subfields into the appropriate order and save. 4. View the constraints column again and note which subfields are repeatable and which are not. Notice the repeatable settings are no longer correct. 5. Fix the repeatable settings for all affected subfields and save. Check the constraints column again and confirm the repeatable settings have been properly retained. The attached screenshot shows the incorrect repeatable settings after $4 and $i were dragged and dropped for MARC tag 376. $4, $d, and $i should be repeatable and $6, $s, and $t should not be repeatable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 42373] New: Add ability to disallow unbounded patron api searches
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42373 Bug ID: 42373 Summary: Add ability to disallow unbounded patron api searches Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com In a Koha instance with multiple hundreds of thousands of patrons, a patron api search with _per_page=-1 can cause a single worker to query the database for all patrons, then query the database multiple times for each of those patrons to decorate the resulting patrons ( fees owed, etc ). If the _per_page size is greater than the limit we specify, Koha should refuse the request and emit an http status code 400, with a clear error body explaining the max allowed _per_page value. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 41048] New: Add ability to disallow empty patron searches
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41048 Bug ID: 41048 Summary: Add ability to disallow empty patron searches Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In high traffic environments with large numbers of patrons, empty patron searches can take a very long time and cause over-use of resources. It would be good to have the option to require search criteria for patron searches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 37541] New: Changing PIN after turning on forced PIN reset results in setting of NEVER
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37541 Bug ID: 37541 Summary: Changing PIN after turning on forced PIN reset results in setting of NEVER Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: chanel.wheeler(a)yavapaiaz.gov QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org We set up a new patron category with an expiration date of 90 days. We then moved the shared staff accounts over to this new category and set a manual expiration date of a few weeks out. We then went into one of these staff accounts and manually changed the PIN. Now on the patron detail page, it shows their PIN Expires as NEVER. It should show either the manual expiration date we'd already set, or a new date 90 days out. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 41920] New: Limit number of concurrent reports that can be run simultaneously for an instance of Koha
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41920 Bug ID: 41920 Summary: Limit number of concurrent reports that can be run simultaneously for an instance of Koha Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com As a continuation of bug 41919, we should limit the total number of simultaneous reports that can be run at a time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 63

[Bug 41750] New: ForcePasswordResetWhenSetByStaff prohibits login via CAS
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41750 Bug ID: 41750 Summary: ForcePasswordResetWhenSetByStaff prohibits login via CAS Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org When ForcePasswordResetWhenSetByStaff is set to "enforce" and staff adds creates a new patron account, login by CAS is impossible. It took us a while to figure this out, since it just "won't work" without any helpful error message. I think there are different ways this could be handled. We could not check the password expiration date if a user authenticates through another external system (LDAP, CAS, OAuth2), since they cannot change the password then. The smallest solution might be warning on the pref, to not enable this for patron categories that use external authentication. I think in general it would be nicer to allow external authentication and still enforce if local login is used - there might be cases where both are the same patron category now and this would keep things more flexible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2