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

[Bug 42879] New: Avoid per-record plugin lookup in ES marc_records_to_documents
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42879 Bug ID: 42879 Summary: Avoid per-record plugin lookup in ES marc_records_to_documents Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- marc_records_to_documents invokes Koha::Plugins->call('elasticsearch_to_document', ...) once per record. Each call discovers the plugins implementing the hook, which runs a query against plugin_data -- even when no plugin implements the hook or plugins are disabled. In a batch reindex this is one extra query per record purely to discover there is nothing to call. The set of implementing plugins is constant for the batch. Resolve it once (or short-circuit when plugins are disabled / none implement the hook), then dispatch per record. Test plan: 1. prove t/db_dependent/Koha/SearchEngine/Elasticsearch.t 2. With a plugin implementing elasticsearch_to_document, confirm the hook still fires for every record. 3. Count DB statements during a batch reindex before/after. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 42878] New: Batch the available-item check in ES marc_records_to_documents
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42878 Bug ID: 42878 Summary: Batch the available-item check in ES marc_records_to_documents Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When building Elasticsearch documents, marc_records_to_documents runs one query per record to set the 'available' flag: SELECT COUNT(*) FROM items WHERE biblionumber=? AND onloan IS NULL AND itemlost=0 (Koha/SearchEngine/Elasticsearch.pm, the "at least one available item" block). marc_records_to_documents is normally given a whole batch of records, so this is N queries per batch. Availability for every biblionumber in the batch could be fetched with a single grouped query instead. This matters most on a networked database, where it is one extra round-trip per record during reindex. Test plan: 1. prove t/db_dependent/Koha/SearchEngine/Elasticsearch.t 2. Confirm the 'available' flag is unchanged for records with/without available items. 3. Count DB statements during a batch reindex before/after. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 42877] New: Memoize _get_marc_mapping_rules to speed up record indexing
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42877 Bug ID: 42877 Summary: Memoize _get_marc_mapping_rules to speed up record indexing Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::SearchEngine::Elasticsearch::_get_marc_mapping_rules() rebuilds the whole mapping ruleset (regex-parsing every search_marc_map entry) on every call to marc_records_to_documents, and is not memoized. For a bulk reindex (large batches) this is amortized over the batch. But for incremental indexing -- every AddBiblio/ModBiblio enqueues a background job that indexes a single record -- the full rebuild runs for every record. Profiling on 435 records (KTD, Elasticsearch): - _get_marc_mapping_rules alone: ~10.7 ms/call - per-record mapping otherwise: ~3.6 ms So rule rebuilding is roughly 75% of the CPU for a single-record index job. The parsed rules are deterministic per (marcflavour, index). Caching them, the same way _foreach_mapping already uses a 'state' cache, would make single-record indexing roughly 3.5x faster and remove the cost from every code path. Test plan: 1. prove t/db_dependent/Koha/SearchEngine/Elasticsearch.t 2. Reindex a single biblio (or edit one) and confirm it still indexes correctly. 3. Benchmark single-record marc_records_to_documents before/after. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 37940] New: [OMNIBUS] All modification logged via action logs should include original to create JSON diff
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 Bug ID: 37940 Summary: [OMNIBUS] All modification logged via action logs should include original to create JSON diff Change sponsored?: --- Product: Koha Version: unspecified 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 Now that we can store action logs as a JSON diff of changes, we should implement this for all action logs where we can ( creation and modification ). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 2505] Omnibus: Enable Perl warnings in all modules and scripts
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2505 Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|26.11 |Future -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36046] New: Choose staff interface homepage default action
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36046 Bug ID: 36046 Summary: Choose staff interface homepage default action Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirjam.vantieghem(a)etf.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently the default action for the top search box on the staff interface homepage is "Check out". This makes sense for library staff working at the circulation desk. However, for libraries using a self-checkout module, that might not be the desirable default action. We would prefer to have "Search catalog" as default action on the homepage. Would it be possible to have libraries choose the default action on the homepage? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 42626] New: Allocate and track acquisitions funds per vendor in additions to per fund code
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42626 Bug ID: 42626 Summary: Allocate and track acquisitions funds per vendor in additions to per fund code Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries allocate and track spending in acquisitions per vendor in addition to per fund code. We could like to add the ability to do so within Koha with an option Vendor Allocation system (enabled by a system preference). This system would use the same budgets (budget_periods) as the fund structure, but allocate that total across vendors. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 18760] New: printable checkin alerts
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18760 Bug ID: 18760 Summary: printable checkin alerts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Our options right now to display messages at check in are as follow : - put a note in itemnotes, which will display in red in the checked in items table - write something in materials, which will display a proper alert, but dedicated to accompanying materials A new feature is on the way to allow patrons to write notes themselves, on a specific issue but not on the item if i understood correctly, that's bug 14224. This feature will create a new field in the items table: checkin_alert, to allow librarians to have arbitrary alerts displaying at checkin. These alerts will be printable. Use case: the item is an ILL item, and when checking it back in, the librarian wants to have a printed slip with the address of the partner library the item should be sent back to. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 38978] New: [24.05.x] Can't hide column in holdings table from Table settings
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38978 Bug ID: 38978 Summary: [24.05.x] Can't hide column in holdings table from Table settings Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. In 24.05.x, hide some columns via Table settings. 2. The columns do not hide properly, you cannot hide any columns via Table settings on this table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 42872] New: Other reason input field in suggestions management should be a textarea
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42872 Bug ID: 42872 Summary: Other reason input field in suggestions management should be a textarea Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: philip.orr(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In Suggestions management, when changing a suggestion, librarians can choose to give a reason for their change. The "Others..." selection causes an input field to open, allowing the librarian to describe why exactly they are making the change. However, since the input field is not a textarea, it's really annoying to give a reason that is longer than just a couple of words. This input is only meant for text and should be a textarea for ease of use. To recreate: 1. Go to any patron's account 2. Go to the tab "Purchase suggestions" 3. Add a purchase suggestion for any random title 4. From the start page, go to "Suggestions pending approval" 5. At the bottom of the page, choose "Others..." in the selection for "With this reason:" 6. The field shown is an input field -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0