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

[Bug 43458] New: Inconsistent link/button for restrictions and overdues on the circulation page
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43458 Bug ID: 43458 Summary: Inconsistent link/button for restrictions and overdues on the circulation page Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- If you have overdues and restrictions for a patrons, the screen looks like this: https://snipboard.io/JsH4OZ.jpg "View restrictions" is a button Then Overdues: Patron has ITEMS OVERDUE "See highlighted items below" With "See highlighted items below" is a link to view the checkouts Then "Override restriction temporarily" is a button. It's not consistent. My suggestion would be to have "View restrictions" with a link. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 12620] Proxy Add-on for Koha z39.50/SRU servers
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12620 --- Comment #21 from Adolfo Rodríguez Taboada <adolfo.rodriguez(a)xercode.es> --- Created attachment 206620 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206620&action=e… Bug 12620: (QA follow-up) Add test coverage for http_forward_proxy -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12620] Proxy Add-on for Koha z39.50/SRU servers
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12620 --- Comment #20 from Adolfo Rodríguez Taboada <adolfo.rodriguez(a)xercode.es> --- Created attachment 206619 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206619&action=e… Bug 12620: (follow-up) Move HttpForwardProxy from a system preference to koha-conf.xml -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12620] Proxy Add-on for Koha z39.50/SRU servers
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12620 Adolfo Rodríguez Taboada <adolfo.rodriguez(a)xercode.es> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #201633|0 |1 is obsolete| | --- Comment #19 from Adolfo Rodríguez Taboada <adolfo.rodriguez(a)xercode.es> --- Created attachment 206618 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206618&action=e… Bug 12620: Proxy Add-on for Koha z39.50/SRU servers -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24782] New: Calendar edit only applies to first day
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24782 Bug ID: 24782 Summary: Calendar edit only applies to first day Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)outlook.com QA Contact: testopia(a)bugs.koha-community.org When editing holidays edit only applies to first day (from date). To test: 1. Add holidays on range e.g from 04/03 to 06/03 2. Try edit these holidays so that from date is 04/03 and to date is set to 06/03 3. Save => Only 04/03 is changed There should be option to edit holidays on range. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[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