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

[Bug 7972] GUI for Crons
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7972 carthur(a)slolibrary.org <carthur(a)slolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carthur(a)slolibrary.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43608] New: Add preference for cover image hierarchy
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43608 Bug ID: 43608 Summary: Add preference for cover image hierarchy Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: tech.aimee(a)salinapublic.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- When using a paid cover image service, like Syndetics, it would be best for libraries to have the option to prioritize use of these services over other sources for cover images. When libraries pay for services like this, it would be best to use them as much as possible to prove their usefulness, while continuing to keep other servers, like COCE, as a backup. This would allow for more accurate, standard images to be pulled between Koha and discovery layers like Aspen. It seems Koha uses COCE more than other services, while Aspen's behavior is vice versa. The disparity can be confusing for staff. Having a system preference would allow more granular control over the hierarchy of these services, including in cases where there is more than one paid service to consider. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[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 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