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

[Bug 14806] Action Log for Modifying borrower messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14806 --- Comment #21 from Lari Strand <lmstrand(a)gmail.com> --- You need to set up default messaging preferences by patron category in Modify category in administration-> Patron categories. When you create a new patron with some defaults set, the stored defaults should show in action logs. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34304] New: Use "days in advance" for hold reminder notice
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34304 Bug ID: 34304 Summary: Use "days in advance" for hold reminder notice 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment the "days in advance" for the HOLD_REMINDER notice can only be configured via command line options. It would be much nicer if we could use the setting in the messaging preferences (same as for the pre-due notice). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 42661] New: Redudant repetition in "Patron: %s Patron's home library: (%s /%s )" when HidePatronName is activated
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42661 Bug ID: 42661 Summary: Redudant repetition in "Patron: %s Patron's home library: (%s /%s )" when HidePatronName is activated Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When making a reservation for a patron whose home library differs from the library where the staff member is logged in, the current notification contains redundant repetition when system preference HidePatronName is "Don't show". Steps to Reproduce: 1. Log in as staff to a library. 2. Set HidePatronName as "Don't show" 3. Attempt to reserve an item for a patron whose home library is different from the current logged-in library. 4. Observe the notification: Pickup library is different. Patron: A patron from library Midway Patron's home library: (Midway / MPL ) This text comes from the string Patron: %s Patron's home library: (%s /%s ) (%1$s: INCLUDE 'patron-title.inc' patron => patron no_title => 1 no_cardnumber => 1 hide_patron_infos_if_needed => 1 %2$s: Branches.GetName(patron.branchcode) | html %3$s: patron.branchcode | html) And the '%s' has it's own translation: %1$s: - Branches.GetName( patron.branchcode ) | html - A patron from library %s Can these sentences be clarified in any ways to avoid repeating the library name? It is okay when the sentence contains the patron name but when HidePatronName is activated it gets confusing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 43694] New: Koha::REST::V1::to_xml emits child elements in random order, producing schema-invalid XML
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43694 Bug ID: 43694 Summary: Koha::REST::V1::to_xml emits child elements in random order, producing schema-invalid XML Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: minhpq(a)tinhvan.com QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Koha::REST::V1::to_xml builds XML by walking Perl hash keys: sub to_xml { # V1.pm line 240 my $root_key = ( keys %$json )[0]; # line 244 ... sub _json_to_xml { # line 261 foreach my $key ( keys %$json ) { # line 265 Perl randomises hash key order per process (PERL_PERTURB_KEYS, default since 5.18), so the order of child elements differs from one run to the next. The ISO 18626 schema uses xs:sequence, not xs:all, so element order is significant: a message whose children are emitted in the wrong order is invalid and a conformant receiver rejects it at parse time. The same applies to the root element: line 244 takes ( keys %$json )[0], which is only correct because these payloads happen to have exactly one top-level key. It is fragile for the same reason. How to reproduce: Run this five times on a Koha instance and compare the output lines. use Modern::Perl; use XML::LibXML; use Koha::REST::V1; my $json = { supplyingAgencyMessage => { header => { supplyingAgencyId => { agencyIdType => 'ISIL', agencyIdValue => 'X' }, requestingAgencyId => { agencyIdType => 'ISIL', agencyIdValue => 'Y' }, timestamp => '2026-09-30T00:00:00Z', requestingAgencyRequestId => '1', supplyingAgencyRequestId => '2', }, messageInfo => { reasonForMessage => 'StatusChange' }, statusInfo => { status => 'Loaned', lastChange => '2026-09-30T00:00:00Z' }, }, }; my $doc = XML::LibXML->new->parse_string( Koha::REST::V1::to_xml($json) ); my $root = $doc->documentElement; say join( ', ', map { $_->nodeName } $root->findnodes('./*') ); Observed on Koha 26.05.02, Perl v5.38.2 — five consecutive runs: header, statusInfo, messageInfo header, messageInfo, statusInfo messageInfo, header, statusInfo statusInfo, header, messageInfo messageInfo, statusInfo, header The schema requires header, messageInfo, statusInfo, deliveryInfo, returnInfo in that order (ISO-18626-v1_2.xsd), so only the second run above is valid. Nested elements are scrambled the same way: header itself must be supplyingAgencyId, requestingAgencyId, multipleItemRequestId, timestamp, requestingAgencyRequestId, supplyingAgencyRequestId, requestingAgencyAuthentication. Why this has not been noticed: 1. ISO 18626 testing so far appears to have been Koha-to-Koha. The inbound side, Koha::REST::V1::parse_xml/_parse_node, builds a hash and therefore does not care about element order, so two Koha instances understand each other whatever order they emit. 2. Koha does validate these payloads — Koha::ILL::ISO18626::is_invalid resolves the swagger definition and calls $schema->validate($json). But that validates the JSON structure, and JSON objects are unordered by definition, so the check passes while the XML that goes out on the wire is invalid. The validation gives false confidence here rather than catching the problem. This makes the defect worse than an ordinary bug: it is not deterministic. Testing an integration once and seeing it work says nothing, because the next message may be ordered differently. How it was found: Interoperability testing between Koha 26.05.02 and a third-party ISO 18626 implementation written in .NET, generated directly from the official v1.2 XSD (https://illtransactions.org/schemas/ISO-18626-v1_2.xsd) The first supplyingAgencyMessage Koha sent was rejected at XML deserialisation; retrying produced a different failure position, which is what led to the hash ordering. Suggested fix: to_xml has no way to know the required order on its own, so it needs the order to come from somewhere. Two options that both avoid changing every caller: a. Derive the order from the OpenAPI definition that already describes each message. JSON::Validator keeps the properties in the order they appear in the spec file, so the swagger definition can supply the sequence. This also keeps the spec as the single source of truth. b. Let callers pass an explicit ordering, e.g. to_xml($json, { order => {...} }), and have the ISO 18626 code supply the sequences from the XSD. Whichever is chosen, it is worth adding a test that serialises a known payload and asserts the resulting XML validates against the official XSD — a JSON-level check cannot catch this class of bug. Related: bug 43674 (ISO 18626 messages are missing the mandatory ISO18626Message envelope), also in Koha::REST::V1. Fixing either one alone still leaves Koha unable to exchange ISO 18626 messages with a conformant implementation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 43442] New: Staff patron accounts should include prompt to assign permissions if none are set
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43442 Bug ID: 43442 Summary: Staff patron accounts should include prompt to assign permissions if none are set Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: laura(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- We get support tickets from libraries fairly frequently that say something like this: "I'm onboarding a new staff person. I created an account and set a password for them, but they can't log into the Koha staff interface." It's almost always because they haven't assigned the new person any permissions. If a staff person has a Staff patron category type and no permissions are assigned, it would be nice if there was some kind of alert on moremember.pl that would prompt the administrator to assign permissions. The alert would be present upon saving the new account, and also anytime the account is viewed on any later date. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 40500] New: Include credit/debit type code in runtime parameter selection dropdown for reports
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40500 Bug ID: 40500 Summary: Include credit/debit type code in runtime parameter selection dropdown for reports Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com When one sets a runtime parameter in a report for credit or debit type, the dropdown one gets at runtime only includes the description. In many cases it'd be helpful to also include the code itself. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 40537] New: Sum total cost in ordered / foreign currency on invoice summary page
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40537 Bug ID: 40537 Summary: Sum total cost in ordered / foreign currency on invoice summary page 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org On the invoice summary, the individual prices in the foreign currency are now shown, however there is no total for the foreign currency prices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 33501] New: Cashup amount should be configurable
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Bug ID: 33501 Summary: Cashup amount should be configurable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It seems the Cashup summary only accounts for the cash payment type. We have a check payment type that should also be included. Am I missing a configuration somewhere, or do we need some way to define what should be included in the summary and intake balance? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 51

[Bug 43697] New: Link to Edit HTML content (OpacLibraryInfo) on Modify library page incorrect
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43697 Bug ID: 43697 Summary: Link to Edit HTML content (OpacLibraryInfo) on Modify library page incorrect Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: david_liddle(a)sil.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Bug 39482 addressed this issue for 26.05.00 and 25.11.01. It was not applied to 25.05 because of issues. 24.11 LTS was not mentioned. We run 24.11 LTS on both our live and test servers. I find that the link for _Edit HTML content_ does not point to the ID of the configured entry in _HTML customizations_. Instead, it points to a non-existent ID (a new entry) that doesn't even use the next incremental ID in the table _additional_contents_. I also see this behavior with new entries, whether they are started from the library's details page or from the HTML customization tool. I can't reproduce the error in KTD running 24.11.19, which is what our live and test servers are running. However, each is still affected; the link _Edit HTML content_ leads to a new entry, not to the existing one. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 28897] New: Allow library limits in cities and towns administration
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '26

01 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28897 Bug ID: 28897 Summary: Allow library limits in cities and towns administration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In a multi branch setting there may be cities/towns that only apply to certain branches. It would be nice if we could add library limits to each city/town, much like we already do in authorized value administration. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1