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

[Bug 40901] New: koha-common.service bundles all sub-daemons under one systemd service instead of per-instance services
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40901 Bug ID: 40901 Summary: koha-common.service bundles all sub-daemons under one systemd service instead of per-instance services Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tristin.stagg(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 217

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

08 Jul '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 5

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

08 Jul '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 3

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

08 Jul '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 4

[Bug 38050] New: Add REST endpoints for working with "lists"/"virtual shelves"
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38050 Bug ID: 38050 Summary: Add REST endpoints for working with "lists"/"virtual shelves" Change sponsored?: --- 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com We don't yet expose the lists functionality over API's, this would be a beneficial enhancement both for internal use and thrid party integrations wishing to integrate with this functionality. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 71

[Bug 41931] New: While creating EasyAnalitics empty subfields are created
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41931 Bug ID: 41931 Summary: While creating EasyAnalitics empty subfields are created Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: januszop(a)gmail.com Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl While creating EasyAnalitics empty subfields are (often) created. In C4::Biblio::PrepHostMarcField a whole set of subfields is addes to the field 773 regardless if a respective value exists or not. This often creates empty subfields and generates warnings. To reproduce: 1. Set EasyAnalyticalRecords to Show. 2. Go to biblio #1, copy the barcode. 3. Go to biblio #2, chose Edit > Link to host record > enter the barcode. 4. Examine the biblio #2: a) a new "virtual" item from biblio #1 is being displayed; b) a 773 field has been inserted, but with empty subfields $d & $x). 5. There should be warnings in plack-intranet-error.log like: [WARN] Use of uninitialized value in join or string at /usr/share/perl5/MARC/Field.pm line 696. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 42332] New: Remove conditional TT tags from tables thead
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42332 Bug ID: 42332 Summary: Remove conditional TT tags from tables thead Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 41604 Tables that are configurable (admin/columns_settings.pl) cannot have conditional TT tags in their thead. The same number of columns must always be in the DOM when DataTables is initialized. Then we hide the column in the JS part. This depends on the visibility_condition flag added by bug 41604. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41604 [Bug 41604] Impossible to hide Checkin column in issues-table in circ/circulation.pl -- You are receiving this mail because: You are watching all bug changes.

1 77

[Bug 34482] New: Improve MARC21 7xx linking fields in bibliographic records [Omnibus]
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34482 Bug ID: 34482 Summary: Improve MARC21 7xx linking fields in bibliographic records [Omnibus] Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 27507] New: Search host record using control number identifier / organization code
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27507 Bug ID: 27507 Summary: Search host record using control number identifier / organization code Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 11175 In /cgi-bin/koha/catalogue/detail.pl currently if you are viewing a record with 773w field the page shows "In: XXXX" with a search link to the host record. Currently when the 773w field format is in the LOC format of (OrgCode)ControlNumber we only search using the ControlNumber part. When importing records to Koha from different databases it is necessary to search also using the organization's code that is in the parentheses – otherwise we get in the results also unrelated records from other organizations. We need the 003 / Control-number-identifier search addition from bug 11175 to implement this. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 [Bug 11175] Show the parent record's component parts in the detailed views -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 21820] New: Zebraqueue should not be added to
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21820 Bug ID: 21820 Summary: Zebraqueue should not be added to Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com In bug 20244 we identified that the zebraqueue is still being appended to when the searchengine preference is set to ElasticSearch.. unfortunately zebra may still be in use in parallel to Elastic to provide a public SRU/z3950 gateway.. as such we can't bind on just the syspref to know whether we should stop adding to the zebraqueue or not. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53