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

[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 43088] New: Koha::File::Transport lacks a consistent current_directory() accessor across FTP/SFTP/Local
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43088 Bug ID: 43088 Summary: Koha::File::Transport lacks a consistent current_directory() accessor across FTP/SFTP/Local Initiative type: --- Sponsorship --- status: 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 43078 Target Milestone: --- Koha::File::Transport has no consistent, side-effect-free way to query a transport's current remote working directory. Bug 43078 unified list_files() across FTP/Local/SFTP, but left this gap: Net::SFTP::Foreign's cwd() is a pure read-only accessor, but Net::FTP's own cwd() is a mutator - called with no argument it defaults to "/" and issues a real CWD command, changing the connection's directory as a side effect and returning a boolean rather than a path. This surfaced in the koha-plugin-transport-browser plugin, which read $transport->{connection}->cwd directly to capture the initial working directory for its root/breadcrumb navigation. That happened to work for SFTP, but for FTP it silently reset the connection to the server's root directory and captured "1" (a boolean) as the "path", breaking directory navigation for FTP transports - clicking into a subdirectory just reloaded the same listing instead of navigating in. Depends on bug 43078. Test plan: 1. Apply the attached patch on top of bug 43078. 2. prove t/db_dependent/Koha/File/Transport.t t/db_dependent/Koha/File/Transport/FTP.t t/db_dependent/Koha/File/Transport/Local.t t/db_dependent/Koha/File/Transport/SFTP.t 3. koha-qa.pl -v 2 --more-tests reports [PASS] for all changed files with no critic/pod warnings. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43078 [Bug 43078] File transport SFTP backend returns inconsistent list() structure compared to FTP/Local backends -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 28740] New: Delete old ILL requests with cleanup_database
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28740 Bug ID: 28740 Summary: Delete old ILL requests with cleanup_database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz, tomascohen(a)gmail.com We should teach cleanup_database to delete old ILL requests after a given period. Over in bug 23391, we introduced a syspref in which one can define statuses for which to hide ILL requests. Following that same idea of allowing whatever statuses a given back-end may use, the cron should take a number of days and a status and delete any request with that status that is more than that many days old. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 42881] New: Improve Elasticsearch Indexing performance
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42881 Bug ID: 42881 Summary: Improve Elasticsearch Indexing performance Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified 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: --- An epic bug to collect elasticsearch (re)indexing performance improvements -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 43858] New: Checking in a bundle from patron account does not ask to confirm contents
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43858 Bug ID: 43858 Summary: Checking in a bundle from patron account does not ask to confirm contents Initiative type: --- Sponsorship --- status: 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(a)bywatersolutions.com Target Milestone: --- To recreate: 1. From the Bibliographic record, mark the bib record for bundling by setting the leader position 7 to c. This will be HOST_ITEM 2. Click manage bundle and add two other items, from separate records, to the bundle. CHIILD_ITEM1 and CHILD_ITEM2 3. Now check out the bundle 4. Check it in normally, you'll see a modal asking you to confirm the contents on the bundle 5. Check the bundle out again. 6. From the patron's issue table find the row for the bundle and select check in. 7. Below the table click "Check in selected items", you are not asked to confirm the contents of the bundle. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 43857] New: Inaccurate usage example in holds_reminder.pl
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43857 Bug ID: 43857 Summary: Inaccurate usage example in holds_reminder.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Target Milestone: --- The first usage example in holds_reminder.pl claims that running the cron with no arguments will return the help. This is not true. As the second usage example tells us, running the script with no arguments is the most basic usage and processes hold reminders for all libraries and all waiting holds. We should remove the first example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 42334] New: Introduce Koha::Calendar::DateCalculator for date arithmetic
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42334 Bug ID: 42334 Summary: Introduce Koha::Calendar::DateCalculator for date arithmetic 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Koha::Calendar currently mixes two concerns: calendar data (which days are closed) and date arithmetic (calculating due dates, counting open days, finding next open day). The arithmetic methods all depend on a days_mode parameter that gets passed into the Calendar constructor even though it has nothing to do with the calendar itself, it's a circulation policy. The goal is to extract the date arithmetic methods into a new Koha::Calendar::DateCalculator class that takes a calendar and a days_mode as constructor parameters: ``` my $calc = Koha::Calendar::DateCalculator->new( calendar => $library->calendar, days_mode => C4::Context->preference('useDaysMode'), ); my $due_date = $calc->add_duration( $start, $dur, 'days' ); ``` Methods to move: addDuration, addHours, addDays, get_push_amt, next_open_days, prev_open_days, days_forward, days_between, hours_between, has_business_days_between. This separates the calendar (what's closed) from the policy (how to handle closed days when calculating dates), and removes the days_mode parameter from Koha::Calendar->new where it never belonged. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15