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

[Bug 41984] New: The biblio title should include 245$h when displayed in the patron-hold-table
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41984 Bug ID: 41984 Summary: The biblio title should include 245$h when displayed in the patron-hold-table Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1. Have a biblio with a 245$h ( biblio.medium ) 2. Place a hold on that title 3. Visit both members/moremember.pl and circ/circulation.pl to view the patron hold table. 4. Go to the Holds tab 5. Notice the title displays but not the 245$h. biblio-title.inc includes the 245$h, so for consistency we should also display it here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 4858] Ability to Charge for Print Notices
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4858 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas(a)bywatersolutions.com Keywords| |release-notes-needed -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 33738] New: Add bookings to the OPAC
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33738 Bug ID: 33738 Summary: Add bookings to the OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, testopia(a)bugs.koha-community.org Depends on: 29002 As part of the bookings workflow, we should add support for making bookings from the OPAC as a patron. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002 [Bug 29002] Add ability to book items ahead of time -- You are receiving this mail because: You are watching all bug changes.

1 62

[Bug 43795] New: Add REST API routes for MARC modification templates (read-only)
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43795 Bug ID: 43795 Summary: Add REST API routes for MARC modification templates (read-only) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Koha has no REST API for MARC modification templates (the marc_modification_templates and marc_modification_template_actions tables, managed in Tools > MARC modification templates and applied by C4::MarcModificationTemplates). Anything that needs to offer or display a template has to load the list server-side in a Perl script and embed it in the page. A concrete example: bug 30800 (a management page for MARC import staging profiles) needs a template dropdown in a Vue form, and the profiles REST resource (/import_batch_profiles) only returns the bare template_id. Proposal Add a read-only REST resource: - GET /marc_modification_templates (list, with the usual query, pagination and ordering support) - GET /marc_modification_templates/{marc_modification_template_id} Fields to expose: marc_modification_template_id (template_id) and name. The actions belonging to a template could be exposed later through ?_embed, but are out of scope for this bug. Implementation notes - There are DBIC result classes (Koha::Schema::Result::MarcModificationTemplate and ...Action) but no Koha::Object wrappers yet; add Koha::MarcModificationTemplate and Koha::MarcModificationTemplates. - Add the swagger definition and paths, and a Koha::REST::V1 controller. - Add unit tests for the object classes and REST tests under t/db_dependent/api/v1/. Open questions 1. Permissions. Managing templates uses the tools: marc_modification_templates permission, but a cataloguer staging records (tools: stage_marc_import) or doing batch modifications must be able to choose a template. Reading should probably be allowed with any of these; how best to express that in x-koha-authorization? 2. Write operations (add/edit/delete) and the template actions are deliberately left to later bugs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 43794] New: Add REST API routes for record matching rules (read-only)
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43794 Bug ID: 43794 Summary: Add REST API routes for record matching rules (read-only) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Koha has no REST API for record matching rules (the marc_matchers table, managed in Administration > Record matching rules and consumed by C4::Matcher). Anything that needs to offer or display a matching rule has to get the list some other way, by loading it server-side in a Perl script and embedding it in the page, or by querying the database directly. A concrete example: bug 30800 (a management page for MARC import staging profiles) needs a matching-rule dropdown in a Vue form, and the profiles REST resource (/import_batch_profiles) only returns the bare matcher_id. Proposal Add a read-only REST resource: - GET /record_matchers (list, with the usual query, pagination and ordering support) - GET /record_matchers/{record_matcher_id} Fields to expose: record_matcher_id (matcher_id), code, description, record_type, threshold. The matchpoints and match checks (the detailed rules) are out of scope for this bug. Implementation notes - There is a DBIC result class (Koha::Schema::Result::MarcMatcher) but no Koha::Object wrapper yet; add Koha::RecordMatcher and Koha::RecordMatchers. - Add the swagger definition and paths, and a Koha::REST::V1 controller. - Add unit tests for the object classes and REST tests under t/db_dependent/api/v1/. Open questions 1. Permissions. The matching rules page uses the manage_matching_rules parameters permission, but a cataloguer staging records (tools: stage_marc_import) must be able to choose a rule. Reading should probably be allowed with either; how best to express that in x-koha-authorization? 2. Naming: record_matchers, or matching_rules? 3. Write operations (add/edit/delete) are deliberately left to a later bug. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 27364] New: Making previous patron cardnumbers searchable
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27364 Bug ID: 27364 Summary: Making previous patron cardnumbers searchable Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: fiona.borthwick(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 18626 introduced the logging of changes to patron cardnumbers which is great, but this still does not link together previous cardnumbers. Imagine this scenario: A library patron loses their library card. They are issued with a replacement. Old and new cardnumbers are recorded in the Modification log. The old card is found (doesn't matter who finds it) and brought to the library. A member of library staff scan the barcode - get no results. This means they are none the wiser as to who this card belonged to. Would it not be a good idea to allow previous cardnumbers to be searchable? Some libraries may record this information somewhere in the patron record, but a search by cardnumber would be extremely helpful. It would be useful if the cardnumber moved into a linked field automatically when a new cardnumber was entered. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 6532] Way to move items to another record in batches
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas(a)bywatersolutions.com Keywords| |release-notes-needed -- You are receiving this mail because: You are watching all bug changes.

1 0

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

21 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 27

[Bug 43553] New: Convert misc/cronjobs/holds/holds_reminder.pl to the Getopt::Long::Descriptive convention (see bug 43546)
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43553 Bug ID: 43553 Summary: Convert misc/cronjobs/holds/holds_reminder.pl to the Getopt::Long::Descriptive convention (see bug 43546) 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 Depends on: 43546 Target Milestone: --- This is one of a set of bugs filed alongside bug 43546 (Standardize command-line scripts on Getopt::Long::Descriptive) to convert individual, commonly-used cron scripts to whatever declarative option-parsing convention that bug settles on. Depends on 43546. Current state: holds_reminder.pl uses plain Getopt::Long (GetOptions call around line 176). No option is required: --days defaults to 0, meaning all waiting holds, if omitted (around line 195); --library defaults to all branches if omitted; --date defaults to today and is only format-validated if actually supplied; --lettercode defaults to 'HOLD_REMINDER'. What this bug covers: convert the GetOptions call to the new convention purely for consistency and self-documenting --help output, matching bug 43546's convention. No behavior change is expected, since nothing here is actually a missing-required-option bug to fix. Test plan: - --help output covers all documented options and matches current behavior - Running with no options still behaves exactly as before (all branches, all waiting holds, today's date) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43546 [Bug 43546] Standardize command-line scripts on Getopt::Long::Descriptive for safer, more consistent option handling -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 43782] New: GenerateCSRF caches token with global key causing cross-session CSRF 403 errors on Plack workers
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43782 Bug ID: 43782 Summary: GenerateCSRF caches token with global key causing cross-session CSRF 403 errors on Plack workers Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: johan(a)imcode.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 35955 (commit 108c955ea) introduced caching of the CSRF token in Koha::Template::Plugin::Koha::GenerateCSRF using Koha::Cache::Memory::Lite. The cache uses a static key "CSRF-TOKEN" shared across all sessions served by a Plack worker. Because Koha::Cache::Memory::Lite is a package-level in-process hash that is NOT flushed between requests (despite what its documentation says), the cached token from the first session persists and is returned to all subsequent sessions on the same worker process. When session B receives session A's token and submits a form, CSRF validation compares the token against session B's session_id — it was generated for session A — and returns 403. Symptoms: - Intermittent "Invalid CSRF token" 403 errors - Reproducible as "first request after idle period" (e.g. every morning) - Affects both intranet login and OPAC self-checkout (sco-main.pl) - Works on the second attempt (the second request gets the correct session's token because the old cached value is still returned — but a reload generates a new session and fresh token) The 8-hour CSRF_EXPIRY_HOURS (Bug 17110) made the window smaller. After Bug 42924 increased it to 168 hours, a worker running more than ~7 days could additionally serve a near-expired token with less than 1 hour remaining. Note: Bug 18124 correctly made CSRF tokens cryptographically session-specific. The cache layer introduced by Bug 35955 bypasses that protection. The issue can be hard to reproduce, so I have been using reports from customers to piece this together. -- You are receiving this mail because: You are watching all bug changes.

1 13