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

[Bug 43520] New: Replace PatronAutoComplete with PatronSelect in FormElement.vue
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43520 Bug ID: 43520 Summary: Replace PatronAutoComplete with PatronSelect in FormElement.vue Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle(a)bywatersolutions.com Depends on: 43518 Target Milestone: --- Bug 43518 added PatronSelect.vue, a modern Vue 3 / TypeScript patron picker built on vue-select, as a drop-in replacement candidate for the legacy PatronAutoComplete.vue (which wraps jQuery UI's autocomplete widget and the global window.patron_autocomplete()/patron_autocomplete_render_selection() functions). This bug tracks migrating PatronAutoComplete's remaining consumer -- FormElement.vue's generic "patronAutoComplete" driven-form field type -- onto PatronSelect, and closing the gaps that stand in the way: 1. v-model contract mismatch: FormElement.vue binds v-model="resource[attr.name]" as a bare patron ID. PatronSelect's modelValue is a full option object built by patronToOption() (vue/utils/patron-options.js, added in bug 43518). This needs an adapter at the FormElement.vue integration point, or a deliberate decision to change what that field type stores. 2. Initial-selection hydration: PatronAutoComplete fetches and renders the currently selected patron on mount when given an existing ID (used when editing a record that already has a patron attached). PatronSelect has no equivalent built in by design -- it stays side-effect-free -- but bug 43518 added resolvePatronOption() specifically for this: given a bare id it fetches and maps the patron, given an already-embedded patron record it maps only. FormElement.vue's integration needs to call this before/while mounting PatronSelect when editing an existing resource. 3. Confirm parity for anything else FormElement.vue's "patronAutoComplete" field type relies on from PatronAutoComplete (e.g. the patronAutoCompleteOptions "additional-filters" passthrough), and either port it to PatronSelect's query-building convention (reusing the existing buildPatronSearchQuery() global, as bug 41129's booking adapter already does) or document why it does not apply. Out of scope: request.tt calls window.patron_autocomplete() directly (not through the Vue wrapper), so it is unaffected by this migration. Test plan: 1. Apply on top of bug 43518. 2. Find a form rendered via FormElement.vue with a "patronAutoComplete" field (e.g. a plugin custom field, if applicable in your test data), for both create and edit. 3. Verify searching, selecting, and clearing a patron all work, and that an existing selection is shown correctly when editing. 4. Run the existing FormElement.vue Cypress component spec plus any new coverage added for this migration. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43518 [Bug 43518] Add a reusable PatronSelect Vue component with patron search -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[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 33350] New: Show items info several times in notice content
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33350 Bug ID: 33350 Summary: Show items info several times in notice content Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org In Notices such as Overdue notice (ODUE) you may want to show more than once the info of the overdue items. <item>"<<biblio.title>>" by <<biblio.author>>, <<items.itemcallnumber>>, Barcode: <<items.barcode>> Fine: <<items.fine>></item> Some clients may want to have the info in several languages in the same notice, instead of having a different notice for every language. Right now, if you put <item></item> more than once, it doesn't work properly, as the function GetPreparedLetter (C4/Letters.pm) does the following. Example <item>"<<biblio.title>>" by <<biblio.author>>, <<items.itemcallnumber>>, Barcode: <<items.barcode>> Fine: <<items.fine>></item> <item>"<<biblio.title>>" de <<biblio.author>>, <<items.itemcallnumber>>, Código de barras: <<items.barcode>> Sanción: <<items.fine>></item> It picks everything from the first <item> to the last </item> and replaces <<items.>> with their values. "<<biblio.title>>" by <<biblio.author>>, <<items.itemcallnumber>>, Barcode: <<items.barcode>> Fine: <<items.fine>></item> <item>"<<biblio.title>>" de <<biblio.author>>, <<items.itemcallnumber>>, Código de barras: <<items.barcode>> Sanción: <<items.fine>> The result is a mess that looks like this: The following item(s) is/are currently overdue: "Sucker punch " by Hamilton, Laurell K., , Barcode: CPL22090005 Fine: $0.00 Los siguientes ejemplares tienen retrasos: "Sucker punch " de Hamilton, Laurell K., , Código de barras: CPL22090005 Multa: $0.00 "Legion of Super-Heroes" by Levitz, Paul, , Barcode: CPL23010002 Fine: $0.00 Los siguientes ejemplares tienen retrasos: "Legion of Super-Heroes" de Levitz, Paul, , Código de barras: CPL23010002 Multa: $0.00 It should pick the content between the first <item> and the first </item>, and then the same with the second pair, the third pair and so on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 43557] New: Add declarative mutually-exclusive option support to Koha::Script->describe_options
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43557 Bug ID: 43557 Summary: Add declarative mutually-exclusive option support to Koha::Script->describe_options Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Target Milestone: --- Bug 43546 added Koha::Script->describe_options, a thin wrapper round Getopt::Long::Descriptive establishing a declarative convention for command-line option parsing: options can be marked required, and a positional-argument minimum can be declared, both enforced consistently before script logic runs, instead of every script rolling its own post-parse check and error text. Several cron scripts have their own hand-rolled "these two options are mutually exclusive" check, each with slightly different wording and mechanism: - misc/cronjobs/longoverdue.pl: --category/--skip-category, --library/--skip-library, --itemtype/--skip-itemtype (three separate pairs) - misc/cronjobs/membership_expiry.pl: --active/--inactive - misc/cronjobs/update_totalissues.pl: --since/--interval, --use-items/--incremental - misc/cronjobs/process_message_queue.pl: --code/--exclude-code (already converted to describe_options on bug 43551, using a one-off $usage->die() check since this feature didn't exist yet) That is seven pairs across four scripts, all reimplementing the same check. Getopt::Long::Descriptive's own one_of constraint looks like a fit at first glance, but testing shows it does not enforce exclusivity at all when the sub-options are array/repeatable types (e.g. our --code/--exclude-code, which both take multiple values): passing both options together with values is silently accepted, which would be a regression, not a fix. This bug is to add a declarative "exclusive" key to the trailing options hashref of Koha::Script->describe_options, alongside the existing "args" key, e.g.: my $opt = Koha::Script->describe_options( '%c %o', [ 'category|c=s@', 'category codes to include' ], [ 'skip-category|C=s@', 'category codes to exclude' ], { exclusive => [ [qw(category skip_category)] ] }, ); When more than one option in a declared exclusive group is supplied, the script should die with a clear, consistent error and the usage text, the same as a missing required option does today, instead of each script writing its own pod2usage/die/$usage->die variant. Test plan: 1. prove t/Koha/Script.t 2. Add regression tests covering: neither option given, one option given, both options given (dies with a clear message naming both options), and the fact that a bare optional-value flag with no value (see bug 37075) is not treated as "given" for this purpose. 3. koha-qa.pl passes for Koha/Script.pm Sponsored-by: OpenFifth <https://openfifth.co.uk/> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[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

[Bug 7170] Remove use of XML::Simple
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7170 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED -- You are receiving this mail because: You are watching all bug changes.

1 0