- 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 43584] New: Elasticsearch mapping changes that require a full reindex silently leave the live index broken until an admin manually reindexes
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43584 Bug ID: 43584 Summary: Elasticsearch mapping changes that require a full reindex silently leave the live index broken until an admin manually reindexes Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching 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: --- When a library admin changes a search field's mapping in Administration > Search engine configuration (Elasticsearch) (admin/searchengine/elasticsearch/mappings.pl) in a way that isn't purely additive (e.g. changing a field's type), Koha does not reindex or roll back - it leaves the live Elasticsearch index in a broken, mismatched state indefinitely, with no visible warning to end users and no automatic recovery. The only fix is a library admin/sysadmin noticing the problem and manually running a full misc/search_tools/rebuild_elasticsearch.pl -d (or -r), which for a large catalogue can mean a long window of degraded/incorrect search results. Root cause (traced in Koha/SearchEngine/Elasticsearch/Indexer.pm and admin/searchengine/elasticsearch/mappings.pl): 1. Saving the mappings form immediately calls Indexer->update_mappings(), which issues a live Elasticsearch PUT _mapping against the existing index (Indexer.pm update_mappings, around line 262). 2. Elasticsearch's put_mapping API can only add genuinely new fields - it cannot change an already-mapped field's type/analyzer. When the change isn't purely additive, put_mapping throws. Koha catches this, sets the index status to "recreate required" (INDEX_STATUS_RECREATE_REQUIRED), and shows an error banner - but only on the mappings.pl admin screen itself. 3. That index status is never checked anywhere else in the codebase - not in search.pl, not in the OPAC, not in the live cataloguing indexing pipeline (Koha::SearchEngine::Elasticsearch::Indexer::update_index, called on every biblio/item save). So cataloguing and searching both continue to hit the now-inconsistent index with no gating or warning. 4. Nothing schedules or forces the required full reindex. It's entirely a manual, unscheduled, blocking operation the admin must remember to run. I reproduced this on main (2026-09-21, es8) as follows: Test plan / reproduction steps: 1. Set up KTD with Elasticsearch (e.g. ktd --search-engine es8 up -d), set the SearchEngine system preference to "Elasticsearch", and run a full reindex (misc/search_tools/rebuild_elasticsearch.pl -r -v) so the index and DB mapping config agree. 2. Confirm a normal search works, e.g. search for a known title in the OPAC or staff interface. 3. Go to Administration > Search engine configuration (Elasticsearch) > Bibliographic records. 4. Edit an existing, already-mapped field that has real indexed data - for example change "title" from type "String" to type "Number" - and save. 5. Observe: the page reports an error and Koha logs (or, reproduced directly in Perl): Unable to update mappings for index "koha_<instance>_biblios". Reason was: "mapper [title] cannot be changed from type [text] to [integer]". Index needs to be recreated and reindexed 6. Note that this error is only visible on the mappings.pl page itself. Go to the OPAC or staff client and search - searches continue to run against the still-mismatched index with no warning to the person searching, and results/behaviour for the affected field are now undefined/inconsistent with the field's newly configured type and options (facets, sort, filters depending on the field silently misbehave). 7. The only way to recover is for someone to notice the admin banner and run, e.g.: misc/search_tools/rebuild_elasticsearch.pl -d -b -v (drop & recreate + reindex biblios), which for a large catalogue can take a long time, during which search functionality for the affected field(s) stays broken. Note this isn't limited to "hard failure" cases like the type-change example above. Even a purely additive mapping change (e.g. adding a new facet on an existing field) succeeds immediately at the Elasticsearch level, but every record indexed before the change has no value in the new field - so facets/filters/sort on it are silently incomplete for the whole existing catalogue until a full reindex populates it. There is no indication to a searching user (or even the admin) that results are incomplete. Suggested directions (for discussion, not yet implemented): A. Blue/green reindex via index aliases: point the Elasticsearch index name Koha reads/writes as an alias (rather than the literal <instance>_biblios index it uses today - see Koha::SearchEngine::Elasticsearch::Indexer create_index/update_mappings/index_name) at a concrete versioned index (<instance>_biblios_v3). When a mapping change requires a rebuild, build a new concrete index with the new mappings in the background, reindex into it, then atomically flip the alias once it's caught up (capturing any records changed during the rebuild window in a final catch-up pass), and drop the old index. This is the standard Elasticsearch zero-downtime reindex pattern and would mean searches keep working against the old, still-consistent index throughout, with no admin-visible downtime at all. B. Scheduled off-hours full reindex with fallback: rather than applying an incompatible mapping change immediately, queue it, keep serving searches against the current (old-mapping) index/config, and run the full reindex as a background/cron job during a configured off-hours window, then apply the new mapping config atomically once the reindex completes. B is strictly weaker than A (still involves a window where either old or new config must be chosen, and doesn't help instances that want the change live sooner), so A is the preferred direction, but is a bigger architectural change (introducing alias-based indices, a background full-reindex job, and a "reindex in progress" status) than B. Either would be a large enough change to warrant an RFC / community discussion before a patch is written - filing this now primarily to document the problem, root cause, and reproduction steps, and to open discussion on which direction (or another one entirely) the community prefers. At minimum, independent of A/B, two smaller, cheap wins are worth considering regardless of the larger direction chosen: - Surface the "recreate required" / "reindex required" index status somewhere visible beyond the mappings.pl page (e.g. a staff client system alert), so admins aren't only warned if they happen to revisit that specific screen. - Have mappings.pl warn before saving when a proposed type change is likely to be non-additive (best-effort - comparing old vs new type), rather than only after the fact. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[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 --- Comment #15 from carthur(a)slolibrary.org <carthur(a)slolibrary.org> --- +++++++1 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[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