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

[Bug 29997] New: Allow to send email notification when a serial issue is late
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29997 Bug ID: 29997 Summary: Allow to send email notification when a serial issue is late Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Serials Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 43336] New: Remove support for LibrisSpellcheck
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43336 Bug ID: 43336 Summary: Remove support for LibrisSpellcheck Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The Swedish National Library has discontinued the "bibspell" API that used to live at http://api.libris.kb.se/bibspell/ on which the LibrisSpellcheck feature was built, so we need to remove this feature from Koha. This should include at least: - The code - The sysprefs LibrisKey and LibrisURL - Settings for LibrisSpellcheck in the syspref OPACdidyoumean MariaDB [koha_kohadev]> select * from systempreferences where variable = 'opacdidyoumean'\G *************************** 1. row *************************** variable: OPACdidyoumean value: [{ "name": "AuthorityFile"}, { "name": "ExplodedTerms"}, { "name": "LibrisSpellcheck"}] options: NULL explanation: Did you mean? configuration for the OPAC. Do not change, as this is controlled by /cgi-bin/koha/admin/didyoumean.pl. type: Free $ grep -rn LibrisSpell * Koha/SuggestionEngine/Plugin/LibrisSpellcheck.pm:1:package Koha::SuggestionEngine::Plugin::LibrisSpellcheck; Koha/SuggestionEngine/Plugin/LibrisSpellcheck.pm:27: return 'LibrisSpellcheck'; Koha/SuggestionEngine/Plugin/LibrisSpellcheck.pm:68:Koha::SuggestionEngine::Plugin::LibrisSpellcheck koha-tmpl/intranet-tmpl/prog/en/modules/admin/didyoumean.tt:24: [% CASE 'LibrisSpellcheck' %] -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 43364] New: Add a maintenance script to find dead links in biblio records, items or authorities
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43364 Bug ID: 43364 Summary: Add a maintenance script to find dead links in biblio records, items or authorities Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Target Milestone: --- Allow to regularly run such a script to find dead links and notify library staff. It may be sufficient to do a HTTP HEAD request. (Perl modules like LWP::UserAgent allow specifying the number of redirects to follow.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 36165] New: Update "Tools" landing page to be more consistent with 'Cataloging' and 'Circulation' landing pages
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36165 Bug ID: 36165 Summary: Update "Tools" landing page to be more consistent with 'Cataloging' and 'Circulation' landing pages 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 36164 We should take inspiration from existing landing pages, Cataloging, Circulation, Reports, and Administration all come to mind. It would be great to have all of these manifest in a more consistent form. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36164 [Bug 36164] Bring more consistency to our module landing pages -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 42504] New: Remove totalissues from stored MARC, embed at index time
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42504 Bug ID: 42504 Summary: Remove totalissues from stored MARC, embed at index time 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 ## Problem update_totalissues.pl can run for 4+ hours on large installations. The root cause is that totalissues is stored in the MARC record (942$0), requiring the full ModBiblio pipeline per biblio: MARC XML deserialization, field update, serialization, TransformMarcToKoha, DB updates, search engine reindexing, cataloguing log entries, plugin hooks, OAI sets updates. The existing UpdateTotalIssuesOnCirc syspref provides real-time updates on checkout but is disabled by default because it triggers this same expensive ModBiblio pipeline on every checkout. Bug 36474 improved things by skipping unchanged records, but every changed record still pays the full cost. ## Proposal Stop storing totalissues in the MARC record. Instead: 1. UpdateTotalIssues becomes a lightweight DB-only operation: just UPDATE biblioitems SET totalissues = ? WHERE biblionumber = ? plus queue a search index update. No MARC parsing, no ModBiblio. 2. Inject 942$0 at index time via Koha::Biblio::metadata_record: Add an embed_total_issues parameter (following the existing embed_items pattern). Both search engine indexers call metadata_record to get the MARC before indexing. The value gets injected from biblioitems.totalissues on the fly, just like items are embedded today. The stored MARC in biblio_metadata stays clean. Both the ES indexer (_get_record) and Zebra's rebuild_zebra.pl -d (which already pre-processes records before sending to Zebra) would pass this flag. 3. UpdateTotalIssuesOnCirc becomes cheap enough to enable by default: A DB column update plus a reindex queue entry per checkout is trivial. The Elasticsearch indexer already batches indexing tasks efficiently. 4. update_totalissues.pl is simplified: It recalculates biblioitems.totalissues from statistics/items data and triggers batch reindexing. It no longer touches MARC records at all. It should also gain a --commit option to control batch sizes for the reindex step. ## Expected impact - Real-time totalissues updates on checkout with negligible performance cost - update_totalissues.pl runtime reduced from hours to minutes (DB updates + batch reindex vs per-record ModBiblio) - No more MARC record churn for a derived counter value - Reduced action_logs noise (no cataloguing log entries for counter updates) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 43569] New: update_index masks per-document ES failures; reindex reports silent success
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43569 Bug ID: 43569 Summary: update_index masks per-document ES failures; reindex reports silent success Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Elasticsearch indexing can silently drop records: update_index() masks per-document bulk failures, and rebuild_elasticsearch.pl reports success even when records fail to index. This is a follow-up to bug 42669, which fixed the es_indexer_daemon.pl silent job failure and NoNodes recovery. That fix only handles thrown exceptions (whole-operation failures). It does not address the case where the ES bulk request returns HTTP 200 but individual documents fail (mapping conflicts, strict_dynamic_mapping_exception, field-too-long, etc.). Those per-item failures are currently swallowed. == Current behavior == Koha::SearchEngine::Elasticsearch::Indexer::update_index(): - On a bulk response with $response->{errors} true, it only carp()s "One or more ElasticSearch errors occurred when indexing documents" and returns the raw response as if successful. - Callers cannot easily tell which records failed or act on them. misc/workers/es_indexer_daemon.pl: - Ignores the update_index() return value entirely; relies only on try/catch for exceptions. A partial bulk failure leaves the batch marked 'finished', so the affected records are silently missing from search. misc/search_tools/rebuild_elasticsearch.pl: - The buffered commit is wrapped in try/catch that only logs and continues; dropped records are never retried. - The final commit (uncommitted tail) is NOT wrapped, so under 'use autodie' an exception there kills the process mid-slice. - _handle_response() prints per-item error detail only at verbosity level 2, and even the summary line is suppressed at the default verbosity used by cron. Reindex cronjobs therefore report success while records fail. - Exit status is always 0, so cron wrappers cannot detect failures. - With --processes, child exit status is not propagated (wait() ignores $?), so a failed slice is invisible to the parent. == Proposed change (two-phase implementation on this bug) == Phase 1: Surface per-document bulk failures. - update_index() returns a Koha::Result::Boolean instead of the raw ES response. False when any bulk item errored; one message per failed record via add_message({ type => 'error', message => reason, payload => { record_id => id, error => ... } }). - Empty-body case returns a true Boolean (removes the current undef return and the undef-deref hazard in callers). - Whole-operation failures (bulk call throws, NoNodes) keep throwing Koha::Exceptions::Elasticsearch::BadResponse, so the daemon NoNodes reset path from bug 42669 stays intact. Exceptions mean "could not run"; the Boolean means "ran, some documents failed". - Migrate callers: * es_indexer_daemon.pl: inspect the Boolean; on false set index_ok = 0 so the batch is marked 'failed' instead of 'finished'. NOTE: this makes previously-hidden partial failures visible as failed jobs (intended). * rebuild_elasticsearch.pl: minimal migration so _handle_response does not break on the new return type (full hardening is Phase 2). * index_records() and bulkmarcimport.pl currently ignore the return; left as-is in Phase 1, noted as optional future work. - Tests: update t/db_dependent/Koha/SearchEngine/Elasticsearch/Indexer.t (the existing update_index assertion) and add all-success, partial-failure, empty-body, and whole-op-throws cases. Phase 2: Harden rebuild_elasticsearch.pl (depends on Phase 1). - Track failed/skipped counts; exit non-zero on any failure so cron wrappers can detect trouble. (Visible behavior change for existing automation.) - Wrap the final commit in the same try/catch as the buffered one, honoring the NoNodes-vs-real-error distinction so a hard outage is not masked as a soft warning under autodie. - Propagate child exit status in the --processes path (children exit non-zero on failure; parent aggregates $? from wait()). - Report fetched vs indexed vs failed vs skipped at the end; the current "Total N records indexed" line overstates success. == Out of scope == Standardizing logging across the ES indexing stack (Carp vs Koha::Logger alignment) will be handled in a separate report. == Open questions for QA == - Should index_records() aggregate and return a combined Boolean, or stay fire-and-forget for now? - Does the daemon 'finished' -> 'failed' semantic shift for partial failures warrant a release note? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 22972] New: Proposal for enriching the bibliographic records with standard identifiers from authority data
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22972 Bug ID: 22972 Summary: Proposal for enriching the bibliographic records with standard identifiers from authority data Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Thinking in terms of linked data, it would be of profit to have as much of standard identifiers in the bibliographic data produced by the library as possible. Libraries use authority data coming from official sources (like LoC, SUDOC, etc.) or enrich their locally created authority records with standard identifiers (e.g. viafId, ISNI, Wikipedia). This information is linked to the bibliographic record by the Koha-specific subfield $9 which is illegal in terms of MARC 21 and does not mean anything outside of the local Koha ecosystem. A record moved out of a local Koha catalogue (downloaded, exported) loses the linked-data connection to other objects (like authors, subjects etc.), which are then identified only by strings. To make this connection between bibliographic access point and objects identified by universal identifiers more permanent outside of the local environment, the standard MARC 21 $0 subfield could be used. (UNIMARC has to be examined - $3 subfield?) The required changes would include at least: C4::AuthoritiesMarc::merge function, the authority plugin, some new system preferences, optionally display templates and also a script to update the existing biblio records. New possible system preferences needed: - switch the feature on/off - source of the standard IDs (possibly different for different biblio fields?) (standard in MARC 21 authority: 024, but may be also 010/035) (a list) - how many ids should be copied (= how may $0 added): only the first found or all of them - if an extra link/icon should be generated in display (OPAC / librarian) Please, share your comments about this idea. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 71

[Bug 41980] New: SIP codes in the new SIP Config UI could have better descriptions
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41980 Bug ID: 41980 Summary: SIP codes in the new SIP Config UI could have better descriptions Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 37893 Now we have a nice systems librarian facing SIP configuration page, it would be nice to improve the field descriptions from many simple SIP codes to something a little more understandable for the person doing the configuration should they not be a SIP expert. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 [Bug 37893] Migrate some SIP configuration into the staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 41181] New: SIP2 module should auto-complete (search) patron attribute types for new patron attribute
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41181 Bug ID: 41181 Summary: SIP2 module should auto-complete (search) patron attribute types for new patron attribute Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org When creating/editing an account, under 'SIP response mappings', the "Add new patron attribute" relationship widget should provide a auto-complete (search) for existing patron attribute types for the 'code' input field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 43671] New: Holds impair SCO module load time
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43671 Bug ID: 43671 Summary: Holds impair SCO module load time Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In a large system, holds can have a significant impact on the amount of time it takes for the main page to load in the SCO module. In our system during busy times, patrons with many holds see load times of 20 seconds or more after logging into the SCO Module and after each checkout. We can already avoid the impact of existing checkouts on SCO Module load times, because the system preference SCOLoadCheckoutsByDefault allows the patron's existing checkouts to be loaded on-demand. We should have the option to delay the loading of holds as well. -- You are receiving this mail because: You are watching all bug changes.

1 12