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

[Bug 37985] New: Extend geo-search to support areas, not just points (MARC 034 subfields defg)
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37985 Bug ID: 37985 Summary: Extend geo-search to support areas, not just points (MARC 034 subfields defg) Change sponsored?: --- 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: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org Bug 31652 ("Add geo-search") implements indexing geographic coordinates (034s,t) in Elasticsearch to enable searching for records referring to specific coordinates. Some records (or authorities) will refer to whole areas, which MARC encodes as north/south/east/westmost points. Since elasticsearch supports indexing shapes, not just points, it would be a nice improvement to be able to index this as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 42777] New: Authority linker cron job removes punctuation
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42777 Bug ID: 42777 Summary: Authority linker cron job removes punctuation Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mnero(a)oslri.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We have AutoLinkBiblios enabled, so when we save a bib record, the headings are automatically linked. When doing this, if there is a period at the end of a field being linked, the $9 appears after the period. We also have a cron job that runs once a week to run general authority linking on our system. During that process, if there is a period at the end of the field, it removes it when adding the $9. This is causing an issue with the same heading appearing with the period if it was linked upon saving and without the period if it was linked during the cron job. If the period is before a $2 (Fantasy fiction.$2lcgft for example), the cron job will change it to Fantasy fiction$2lcgft, removing the period. While this doesn't seem to affect access or indexing, it creates a problem when searching for specific strings in the fields or sorting exported information from any of those controlled fields. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 36633] New: Support anti-the at REST API level
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36633 Bug ID: 36633 Summary: Support anti-the at REST API level Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com CC: tomascohen(a)gmail.com Coming from bug 35560. If we migrate UI tables to DT using the REST API we need support the anti-the sorting type. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 36829] New: Add option to generate hold cancellation request from staff interface
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36829 Bug ID: 36829 Summary: Add option to generate hold cancellation request from staff interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com A hold may be waiting at a different branch or desk, or the staff may not have the time to step away and pull the hold due to a line at the desk. It would be helpful to have an option to do a request instead of just cancelling the hold. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 33646] New: "Cataloging search" missing branch data for not for loan items
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33646 Bug ID: 33646 Summary: "Cataloging search" missing branch data for not for loan items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org In the "Cataloging search" (ie /cgi-bin/koha/cataloguing/addbooks.pl), the branch name doesn't appear for "Not for loan" items, which makes the display nonsensical when there are many not for loan items for many branches. It's also inconsistent with the "Search results" (ie /cgi-bin/koha/catalogue/search.pl). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 46

[Bug 42880] New: Avoid the USMARC round-trip when building ES documents
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42880 Bug ID: 42880 Summary: Avoid the USMARC round-trip when building ES 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: --- For every record, marc_records_to_documents serializes the record to USMARC and then re-parses it with MARC::Record->new_from_usmarc, purely to "prove it will round-trip" before storing marc_data (Koha/SearchEngine/Elasticsearch.pm). Profiling shows this re-decode is roughly 20-25% of the per-record mapping CPU. The round-trip is a safety net to fall back to MARCXML storage when a record cannot be represented as USMARC (e.g. length > 99999). That check could run only when the encode actually fails, rather than decoding every record on the happy path. Test plan: 1. prove t/db_dependent/Koha/SearchEngine/Elasticsearch.t 2. Confirm marc_data is unchanged for normal records. 3. Confirm an over-long record still falls back to MARCXML storage. 4. Benchmark 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 15

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

20 Oct '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 11

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

20 Oct '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 9

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

20 Oct '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 8

[Bug 38666] New: New feature: closed stack requests
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38666 Bug ID: 38666 Summary: New feature: closed stack requests Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A closed stack request is a special kind of hold that can only be placed on a closed stack item. A closed stack item is an item that is not available publicly in the library but can be made available on demand. When a request is made, a librarian will print a slip then will go retrieve the document and place the slip in place of the document. -- You are receiving this mail because: You are watching all bug changes.

1 127