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

[Bug 42742] New: delete_records_via_leader.pl cronjob should log
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42742 Bug ID: 42742 Summary: delete_records_via_leader.pl cronjob should log Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz misc/cronjobs/delete_records_via_leader.pl should produce an entry in the logs, right now it just prints to stdout. We run this on a schedule and it'd be useful to see that it ran and its results ("DELETED N of X total records"). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 41849] New: Cancelling filled hold from group does not delete remaining holds from group
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41849 Bug ID: 41849 Summary: Cancelling filled hold from group does not delete remaining holds from group Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 50

[Bug 30834] New: Trigger nightly reindex with a syspref
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30834 Bug ID: 30834 Summary: Trigger nightly reindex with a syspref Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Reindexing (at least with Zebra) leads to search not working for some duration of time, depending on the size of the catalogue. So often you want to do reindexing at night, when use of Koha is low. But remembering to start the indexing process before you go to bed at night is error prone. We could have a syspref called something like "DoReindexInTheMiddleOfTheNight", and a cronjob that runs "in the middle of the night", and checks the syspref. - If it has been set to "on", a reindex is triggered and the syspref is reset to "off". - If it is set to "off", nothing happens. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 40898] New: Add ability to limit the number of columns a patron search api request can sort by
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40898 Bug ID: 40898 Summary: Add ability to limit the number of columns a patron search api request can sort by 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 Patron API searches can order by any borrowers column and can specify any number of columns to order by as well. Given sufficient numbers of patrons and unindexed columns sort by, the search query generated will create a temp table so large it can fill up the temp disk and prevent the db server from functioning. A reasonable solution would be to create a system preference to set a maximum number of columns to sort by. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[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