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

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

19 Aug '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 2

[Bug 41029] New: Add option for marc overlay rules to apply when adding to a basket
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41029 Bug ID: 41029 Summary: Add option for marc overlay rules to apply when adding to a basket Change sponsored?: --- 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently, adding to a basket from a staged file uses the same overlay rules as 'Staged marc import' - per bug 20817 some libraries would like to preserve certain fields during import into a basket. It would be nice to make the rules more granular and allow for rules to apply only when adding to a basket -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

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

19 Aug '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 20

[Bug 43217] New: Allow MARC mod templates to edit existing items in batch record modification
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43217 Bug ID: 43217 Summary: Allow MARC mod templates to edit existing items in batch record modification Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools 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: --- See also bug 43216, which documents the current limitation this bug proposes to actually fix: batch record modification with a MARC modification template can only ever create brand new items on the target biblios (bug 26869), never edit fields on items that already exist, even though the template engine already has the primitives needed to do so. Background C4::MarcModificationTemplates already supports applying an action (add_field, update_field, copy_field, move_field, delete_field) to a single matching field occurrence or to every occurrence of a repeatable field (the field_number = 0 "all" mode, resolved in ModifyRecordWithTemplate and carried out in Koha::SimpleMARC). For update_field specifically, Koha::SimpleMARC::_update_subfield already does exactly what bulk item editing needs: for each matching field occurrence it sets the subfield if present or adds it if absent, per field, driven by the same conditional matching (field/subfield/value/regex) already available to any template rule. That primitive is inert for items today for two reasons: - Koha::BackgroundJob::BatchUpdateBiblio fetches the record with Koha::Biblio::Metadata->record and no embed_items, so a biblio's existing 952/995 fields are never present in the record the template runs against. There is nothing there for update_field's "all occurrences" mode to match. - Even if the fields were present, the only post-template handling of 952/995 data is can_add_item_from_marc_record + C4::Items::AddItemFromMarc, i.e. "treat this as a new item and validate mandatory subfields." There is no path that recognizes a field as belonging to an already-existing item and updates just the touched Koha::Item column(s) instead. Koha already has the reconciliation half of this elsewhere: C4::Items::ModItemFromMarc (used by cataloguing/additem.pl when the full-record item edit form is submitted) updates an existing item from a MARC field carrying its items.itemnumber subfield (per the framework's items.itemnumber mapping, GetMarcFromKohaField), as opposed to C4::Items::AddItemFromMarc for a field with no itemnumber. Batch record modification does not currently use this function at all. Proposed design 1. When a template applied by batch record modification contains a 952/995 action, fetch the biblio record with embed_items so existing items are represented as real 952/995 fields (each carrying the framework's items.itemnumber subfield). Keep the current bare-record fetch for templates that do not touch the item tag, to avoid the extra overhead of embedding items on every run. 2. After the template runs, split the resulting 952/995 fields by whether they carry an itemnumber: - Fields with an itemnumber are existing items. Route them through C4::Items::ModItemFromMarc, updating only the columns the template actually touched. No mandatory-subfield validation is needed since the item already exists and was validated at creation time. - Fields with no itemnumber are new items, unchanged from today: C4::Items::AddItemFromMarc, with the existing can_add_item_from_marc_record mandatory-field check (homebranch, holdingbranch, itemtype). 3. Report per-item results (updated / created / rejected for missing mandatory fields) alongside the existing per-biblio success/error messages, so a biblio can partially succeed (record modified, most items updated, one new item rejected). Open questions to resolve during implementation, not before filing - What should a delete_field action targeting an existing item's 952 mean. Recommend it never deletes the Koha::Item row itself (batch item deletion already exists for that); either restrict delete_field's effect on item-tagged fields to individual subfields, or explicitly disallow/ignore whole-field deletes on fields carrying an itemnumber. - Confirming which fields count as "new" vs "existing" must rely solely on presence of the itemnumber subfield after the template runs, not on which action produced the field, since add_field, copy_field and move_field can all interact with the item tag. - Permission parity: batch record modification currently gates on catalogue edit permissions; bulk-editing arbitrary item columns should probably also require the item-edit subpermission that manual item editing requires. - Preview (svc/records/preview) should be updated in step with this so it reflects the same embed_items + split logic, otherwise the preview/execution mismatch described in bug 43216 will simply move to a new form. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 43237] New: 'Expand' column header doesn't appear consistently for collapsed responsive tables in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43237 Bug ID: 43237 Summary: 'Expand' column header doesn't appear consistently for collapsed responsive tables in the OPAC Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 39698 Target Milestone: --- With the responsive tables introduced by Bug 39698, the Course Reserves table has an 'Expand' column header for the column with the '+' button, but others tables I've observed do not. All of them should have the 'Expand' header. Tables without the Expand header include: Holdings Patron's current checkouts Patron's current holds Patron's clubs Patron's checkout history Patron's search history Patron's charges (That list may not be exhaustive as I've only noted the tables that I've found are responsive.) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39698 [Bug 39698] Add option to expand responsive datatable rows by default -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 38196] New: Filter out concerns by specific status does not include concern without status
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Bug ID: 38196 Summary: Filter out concerns by specific status does not include concern without status Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 35628 You can filter out concerns by status (ie. linked with TICKET_STATUS AV). But if you use this "Filter" link on top of the page to remove the concerns with this specific status, it will also remove the concerns without a specific status. concern 1 | Open concern 2 | Resolved concern 3 | status_1 concern 4 | status_2 "Filter status_1" should remove concern 3 only. However it will only show concern 4. This is because the query is ([-and => {status => { '!=' => "status_1" }}]) And does not include status that are NULL in DB. use Koha::Tickets; my $t = Koha::Tickets->search; say $_->status // "undefined" for $t->as_list; say "==="; $t = Koha::Tickets->search([-and => {status => { '!=' => "status_1" }}]); say $_->status for $t->as_list; undefined undefined status_1 status_2 === status_2 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 [Bug 35628] Add optional statuses to catalog concerns -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 carthur(a)slolibrary.org <carthur(a)slolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carthur(a)slolibrary.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41706] New: "Use of uninitialized value..." warning in C4/Record.pm
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41706 Bug ID: 41706 Summary: "Use of uninitialized value..." warning in C4/Record.pm Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org The warning: [WARN] Use of uninitialized value $2 in split at /kohadevbox/koha/C4/Record.pm line 924. appears in the plack-opac-error.log file. To reproduce in KTD: 1. Observe plack-opac-error.log 2. In OPAC go to record with one word author like Aristophanes, Aristotle or Xenophon (biblionumbers: 64, 176, 254) 3. Show it in any of "detail" view (Normal, MARC, ISBD) 4. Warning appears in plack-opac-error.log It happens during the preparation of data for the "Cite" feature in OPAC. The warning appears because of the overlap of two regular expression matches - the variable captured from the first regular expression match is changed (by the second regular expression match) before it is used. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 43340] New: Koha's SMTP connection rate can trigger errors
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43340 Bug ID: 43340 Summary: Koha's SMTP connection rate can trigger errors Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- When sending email, Koha creates a new SMTP connection for each message. Every single notice does a full connect: EHLO => STARTTLS => auth => send => quit A burst of notices means dozens of connections in seconds from one IP. In practice, this seems to trigger Goggole's Google's per-IP connection rate limiting, which responds with 421-4.7.0 at EHLO. Koha doesn't limit simultaneous connections. There's only ever one connection at a time (the cron is a single sequential process). The problem is connection rate, and Koha has no throttle, delay, or connection-reuse. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43313] New: Item's permanent location not shown when item's location is set to CART
by bugzilla-daemon＠bugs.koha-community.org 19 Aug '26

19 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43313 Bug ID: 43313 Summary: Item's permanent location not shown when item's location is set to CART Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- In 25.11 and previous, when items.location and items.permanent_location do not match, Koha shows the permanent_location value followed by the location value in parentheses. This is most often due to the library using UpdateItemLocationOnCheckin to set the location to CART at checkin. In 26.05 and later, the permanent_location value is not displayed. Instead, one is shown only the location in parentheses. So where we would have seen Adult fiction (Shelving cart) We now see (Shelving cart) We should show both values. Inserting a line break between them while we're at it would be nice: Adult fiction (Shelving cart) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11