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

[Bug 43740] New: Notice module "Patrons (custom slip)" is sometimes "Patron (custom slip)"
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43740 Bug ID: 43740 Summary: Notice module "Patrons (custom slip)" is sometimes "Patron (custom slip)" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- The notice module "Patrons (custom slip)" reads "Patron (custom slip)" in the notice creation/edit screen. To recreate: 1 - go to Tools, Notices and Slips 2 - click New notice 3 - select "Patrons (custom slip)" 4 - in the notice creation screen, see the module reads "Patron (custom slip)" 5 - save your notice 6 - in the list of existing notices, see your notice shows "Patrons (custom slip)" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 43734] New: koha-create requires --create-db despite the documentation saying it's the default
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43734 Bug ID: 43734 Summary: koha-create requires --create-db despite the documentation saying it's the default Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: robin(a)kallisti.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Target Milestone: --- The documentation for koha-create says: DB usage mode: --create-db Create a new database on localhost. (default). however if you don't include this, no operation is defined inside koha-create and it just errors. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 43732] New: koha-create doesn't output a message about enabling email
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43732 Bug ID: 43732 Summary: koha-create doesn't output a message about enabling email Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: robin(a)kallisti.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Target Milestone: --- koha-create is supposed to output a message telling you that email isn't enabled and how to enable it. Due to a bug, it doesn't. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 43665] New: Fix HTML entities in fields filled by marc21_linking_section.pl
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43665 Bug ID: 43665 Summary: Fix HTML entities in fields filled by marc21_linking_section.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Hello, When selecting a record with the marc21_linking_section.pl plugin, values copied into the linking field (773$t, $a, $b, $d, $k...) show literal HTML entities (&, ", ') whenever the source record contains special characters. The values were written in a JavaScript string with the "html" filter. The browser does not decode entities inside a <script> block, so they ended up as text in the subfield. The plugin also escaped ' as \' in Perl, which made the output worse. This became visible with bug 29733, which copies many more subfields from the source record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 43548] New: Convert misc/cronjobs/runreport.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=43548 Bug ID: 43548 Summary: Convert misc/cronjobs/runreport.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: runreport.pl uses plain Getopt::Long (GetOptions call around line 210). No option here is actually mandatory -- --format defaults to 'text' if omitted (around line 237); --to/--from/--email are only meaningful together and default from the KohaAdminEmailAddress system preference if unset. The script's real "you must supply something" requirement is a positional argument, not a named option: at least one saved report ID must be passed via @ARGV, enforced by "unless (scalar(@ARGV)) { pod2usage(1); }" around line 268. What this bug covers: convert the GetOptions call to the new convention, declaring each option's type and description explicitly, with none marked required (matching current behavior -- nothing here is a false negative to fix). Note for whoever picks this up: the positional report-ID requirement doesn't map onto a simple per-option required flag, so it will likely need to stay as manual validation after parsing, unless the convention from bug 43546 ends up handling leftover/positional arguments some other way -- check against whatever pattern that bug lands on. Test plan: - --help output covers all documented options and matches current behavior - Running with one or more report IDs still behaves exactly as before - Running with zero report IDs still fails with a clear error 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 the assignee for the bug. You are watching all bug changes.

1 23

[Bug 43540] New: Switching OPAC language loses /bib/<id> short URLs, redirects to homepage
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43540 Bug ID: 43540 Summary: Switching OPAC language loses /bib/<id> short URLs, redirects to homepage 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When switching the OPAC interface language on a page reached via Koha's own /bib/<biblionumber> short URL (see the RewriteRule shipped in apache-shared-opac.conf / etc/koha-httpd.conf), the user is redirected to the OPAC homepage instead of staying on the record they were viewing. The same applies on the staff side for /bib/<biblionumber> against catalogue/detail.pl. Root cause: the /bib/ RewriteRule uses the [PT] flag, meaning it is an internal rewrite - the browser's address bar and Referer header keep showing /bib/<id>, never /cgi-bin/koha/opac-detail.pl. Koha::Util::Navigation::local_referer() (used by opac-changelanguage.pl and changelanguage.pl to work out where to send the user back to after a language switch) treats a referer as local only if it matches the site's OPACBaseURL/staffClientBaseURL AND contains the literal substring /cgi-bin/koha/. Since /bib/<id> never contains that substring, local_referer() falls through to its fallback (the site root), so the language switch drops the user on the homepage. This patch extends local_referer()'s recognized local-path pattern to also accept Koha's own /bib/<digits> short URL, in both the OPACBaseURL/staffClientBaseURL branch and the no-base-URL fallback branch. Test plan: 1. Enable mod_rewrite and confirm the /bib/<biblionumber> short URL works for an OPAC record (e.g. /bib/123 loads the same page as opac-detail.pl?biblionumber=123). 2. On that page, switch OPAC language using the language selector in the header or footer. 3. Before this patch: you are redirected to the OPAC homepage, losing the record. 4. After this patch: you are redirected back to /bib/123, now in the newly selected language. 5. prove t/Koha/Util/Navigation.t - all tests pass, including two new /bib/ short url cases. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 42860] New: UNIVERSAL::require is deprecated and should be replaced
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42860 Bug ID: 42860 Summary: UNIVERSAL::require is deprecated and should be replaced Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- UNIVERSAL::require is used only for the SIP server and nowhere else. We should be able to replace it with Module::Load which is already used in Koha elsewhere. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 39160] New: Mojolicious::Plugin::OAuth2 is loaded suboptimally
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39160 Bug ID: 39160 Summary: Mojolicious::Plugin::OAuth2 is loaded suboptimally Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial 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 This is a deep cut, but the following line is not optimal: $self->plugin( 'Mojolicious::Plugin::OAuth2' => $oauth_configuration ); Mojolicious will first try to load that as Mojolicious::Plugin::Mojolicious::Plugin::OAuth2 before it realises that we've already loaded Mojolicious::Plugin::OAuth2 earlier in Koha::REST::V1. I reckon that should say: $self->plugin( 'OAuth2' => $oauth_configuration ); -- In the grand scheme of things, it's not a big deal, but we can save ourselves 26 system calls by changing 1 line. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 42180] New: Add borrower lookup tool to SIP2 Account Creation
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42180 Bug ID: 42180 Summary: Add borrower lookup tool to SIP2 Account Creation 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: eric(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org With the move to storing the sip accounts in the database rather than in SIPconfig.xml I think it would be nice to have a borrower account lookup tool in the SIP account creation form rather than the standard textbox. Currently, the field "Staff userid for SIP2 authentication" does have a tooltip that explains the userid needs to match an existing account, but the ability to search and find it would help eliminate a possible point of human error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 43859] New: [NEW MODULE] Complaint and Glitch Management for Libraries
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43859 Bug ID: 43859 Summary: [NEW MODULE] Complaint and Glitch Management for Libraries 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: snehasishpaul71(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 208520 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=208520&action=e… To integrate in KOHA module PROBLEM ======= Koha currently has no dedicated module for managing operational complaints and glitches reported by library patrons or staff. When a patron encounters a system issue (e.g. OPAC search failure, circulation error, catalogue inconsistency), there is no structured way to: - Log the glitch with proper categorisation and priority - Assign it to the responsible staff member - Track resolution progress through defined workflow states - Record prevention notes on the patron record for future reference Libraries resort to ad-hoc methods: email threads, paper logbooks, or spreadsheets — all of which lack accountability, traceability, and integration with the Koha ecosystem. PROPOSED SOLUTION ================= A new "Complaint Management" module under Tools, providing: 1. Raise complaint — staff or patron submits a ticket with title, category (Catalogue, Circulation, Acquisitions, Serials, Reports, System, Other), priority (Critical/High/Medium/Low), description, and the page/module location where the glitch occurred. 2. Assign — supervisor assigns the ticket to the correct staff member. 3. Track — status workflow: Open → In Progress → Resolved → Closed. 4. Resolve — staff records a resolution note and optional patron remarks (prevention notes visible on the borrower record). 5. Comment thread — staff can add timestamped comments for discussion. 6. Dashboard — filterable list with status tabs, DataTables sorting, and per-status counts. TECHNICAL DETAILS ================= - 2 new database tables: complaints, complaint_comments - 4 new Perl modules: Koha::Complaint, Koha::Complaints, Koha::Schema::Result::Complaint, Koha::Schema::Result::ComplaintComment - 1 CGI controller: complaints/complaints.pl - 1 Template Toolkit view: complaints/complaints.tt - 1 DB revision: installer/data/mysql/db_revs/ - 1 system preference: ComplaintManagement (YesNo) - 1 sub-permission: tools > complaints - Full unit test: t/db_dependent/Koha/Complaints.t (5 subtests, 23 assertions) All code follows Koha coding guidelines: - cud- prefix on all POST operations - CSRF token validation on every form - Post-Redirect-Get pattern after mutations - i18n-ready template with [% t("...") %] wrappers - Proper DBIx::Class schema with belongs_to / has_many relationships Initial patches are ready. RFC page will be created on the wiki. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2