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

[Bug 43760] New: Add the ability for staff to send pending notice immediately
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43760 Bug ID: 43760 Summary: Add the ability for staff to send pending notice immediately Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- It would be useful if staff members could immediately send pending notice (listed in Notice tab) to user. It could by done by "Send immediately" button at notice preview. Sometimes a librarian needs to send a (predefined) message to a user they are currently talking with in the library (e.g., message with a specially prepared link). Currently, a predefined message (like many others) is added to the queue and will be sent according to the cron job schedule (usually every 15 minutes). Adding a "Send Immediately" button (similar to the "Resend" button for messages that have already been sent) could be good solution. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 41246] New: Deleting patron categories can leave orphaned rules in the overduerules table
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41246 Bug ID: 41246 Summary: Deleting patron categories can leave orphaned rules in the overduerules table 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 To recreate: 1. Add or have a patron category. 2. Go to Tools > Overdue notice/status triggers 3. Set some rules for that category. 4. Delete the patron category 5. Now do "select distinct categorycode from overduerules;" 6. The rule remains with a non-existent categorycode -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 8726] Did you mean? plugin for broader/narrower/related terms
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8726 Irene Tortorella <i.tortorella(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |i.tortorella(a)arts.ac.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39962] New: Recalled status does not show properly on staff interface record detail page
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39962 Bug ID: 39962 Summary: Recalled status does not show properly on staff interface record detail page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To reproduce: 1. Enable the UseRecalls system preference and set the recalls-related circulation and fines rules. 2. Search for an item. 3. Check out an item to Patron B. 4. Log into the OPAC as Patron A. 5. Request a record-level recall on the record. 6. View the record on the staff interface and look at the holdings table. Notice that the checked out item shows no indication of being recalled, but the recall request does show on the Recalls tab. --> BUG 7. Go to the Recalls tab and cancel the recall. 8. Go back to the OPAC and request an item-level recall on the checked out item. 9. View the record on the staff interface and look at the holdings table. Notice that the checked out item now shows the recalled status, twice. "Recalled by koha (42) on DATE" --> BUG -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 Irene Tortorella <i.tortorella(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |i.tortorella(a)arts.ac.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

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

1 0

[Bug 42170] New: Librarian-Controlled AI Crawler and Search Traffic Management for OPAC Search Page
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42170 Bug ID: 42170 Summary: Librarian-Controlled AI Crawler and Search Traffic Management for OPAC Search Page Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: vimalibre(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I would like to propose a feature for Koha to help libraries manage excessive automated traffic, especially on the OPAC search endpoint such as: opac.yourdomain.com/cgi-bin/koha/opac-search.pl In some cases, this page is being heavily accessed by AI crawlers and other automated agents, which can consume significant server resources and affect normal library service performance. At present, libraries may control this only through external tools such as Cloudflare, Fail2ban, firewall rules, or reverse proxy configurations. However, these approaches often require dedicated IT support, which many libraries may not have. It would be very helpful if Koha could provide built-in tools, configurable from the librarian/staff interface, to allow libraries to manage this traffic based on their own capacity and policy. Requested Functional Requirements: Enable/Disable AI crawler access to OPAC search page Provide an option in the staff interface to allow or disallow AI crawlers from accessing the OPAC search page. This should be manageable by authorized library administrators without requiring server-level intervention. Allow selected crawlers only Provide a configurable allowlist option so that the library may permit only selected crawlers or bots while blocking others. This would help libraries that want discovery/indexing benefits from specific services without opening access to all automated agents. Rate limiting for OPAC search endpoint Provide an option to enable configurable rate limiting specifically for high-hit pages such as opac-search.pl. This may help reduce server load caused by repeated automated queries. Challenge or verification for suspicious/concurrent hits Provide an option to trigger a challenge or verification step when unusually high concurrent requests are detected from the same IP or user agent. This may help distinguish genuine users from abusive automated access. Traffic monitoring and analytics Provide a simple monitoring dashboard or reporting tool within Koha to show: hit counts to the OPAC search page, top requesting IPs, top user agents, frequency trends, possible abusive patterns. This would help librarians or library administrators understand how the page is being used and identify resource-heavy access. View hit count by IP Provide an interface to view the number of requests coming from a specific IP address over a defined period. This would support easier investigation of suspicious traffic. Optional blocklist integration Provide an option for authorized administrators to add suspicious IPs to a Koha-managed deny list. Where feasible, Koha could also support optional mapping/export of such IPs for OS firewall or reverse proxy blocking. Optional Cloudflare/API-based rule integration For libraries already using Cloudflare or similar services, an optional integration could be provided where administrators enter API credentials and enable predefined protection rules from within Koha. This could simplify deployment of recommended protections without requiring advanced IT intervention. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 43792] New: Staging/commit should honour LDR/5 = d (deleted) in incoming records
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43792 Bug ID: 43792 Summary: Staging/commit should honour LDR/5 = d (deleted) in incoming records Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import 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 21 defines leader position 05 ("record status") with the value 'd' meaning the record has been deleted. Sources of bibliographic data use this to tell consumers a record should be removed. For example, the National Library of Sweden's Libris MARC21 export API can mark deleted records this way (deleted=export). Koha does not act on this when importing. C4::ImportBatch and the staging code never read LDR/5, so a staged record with 'd' is matched and then added or overlaid like any other. If it overlays an existing record, it replaces the live record with a copy marked as deleted. The only existing handling is misc/cronjobs/delete_records_via_leader.pl (bug 11084). It runs after the fact, by a text search of stored MARCXML for 'd' at leader position 5. Integrations that want to keep a catalogue in sync therefore have to work around it. We currently split deleted IDs out of the export separately and delete them ourselves. Proposal Add an import profile option, along the lines of "Records with LDR/5 = d", with values: - Import as normal (the current behaviour, which stays the default) - Ignore these records - Delete the matched record For "delete the matched record": - Matching uses the profile's normal matching rule. - A 'd' record with no match is ignored, not added. - A matched record is only deleted when DelBiblio allows it, so one that still has items is reported and left alone. - The outcome appears in the batch report and is reversible by the usual "undo import" where possible. Related bugs - Bug 25465 asks for a "delete matched record" action for batches of deletion records. This would provide the same action, triggered by LDR/5. - Bug 42044 and bug 42039 (Koha::Util::MARC::update_record_status) make Koha write LDR/5 consistently. This is the consumer side, and could reuse that helper to read the status. - Bug 11084 and bug 42742 cover the existing cron script. Open questions 1. Should the option live in the import profile, on the batch, or both? 2. Should matched records with items be deleted when an option such as "delete items too" is chosen, as delete_records_via_leader.pl --delete-items does? 3. Authority records have the same convention (see bug 33609). Should this be limited to bibliographic records at first? Test plan 1. Create an import profile with a matching rule on 001 and the new option set to "Delete the matched record". 2. Create a bib with 001 = A and no items, one with 001 = B and an item, and stage a file containing records A, B and C (no match), each with LDR/5 = d. 3. Commit the batch. Expect A deleted, B kept and reported as having items, C ignored (not added). 4. Repeat with "Import as normal". Expect the old behaviour. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43802] New: Koha::Config is missing a "config_dir" method
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43802 Bug ID: 43802 Summary: Koha::Config is missing a "config_dir" method Initiative type: --- Sponsorship --- status: 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- At the moment, Koha::Config can only find and read koha-conf.xml, but there are times like in bug 43463 where you might want to access a different Koha configuration file. In fact, locally I already do this with Koha::Prosentient::Config... I think it's more effective than when we do this in C4/SMS.pm: my $sms_send_config = C4::Context->config('sms_send_config'); -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 33259] New: Optionally set SameSite attribute of cookie to Strict
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33259 Bug ID: 33259 Summary: Optionally set SameSite attribute of cookie to Strict Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSi… We should offer a system preference so that libraries who'd like to increase their security can set the SameSite attribute of the session cookie to Strict, rather than the default Lax. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 103