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

[Bug 43763] New: Hold cancellation request via API does not respect waiting hold cancellation policy
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43763 Bug ID: 43763 Summary: Hold cancellation request via API does not respect waiting hold cancellation policy Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Koha's API is able to cancel holds and create a hold cancellation requests when the hold policies say such a request is not allowed. To recreate: - have a waiting hold - set waiting hold cancellation policy to No - attempt to cancel via API without x-koha-override value - your holds is cancelled - create a new waiting hold - waiting hold cancellation policy still at No - attempt to cancel via API with x-koha-override value "cancellation-request-flow" - hold cancellation request is created If the API is meant to be equivalent to a user in the staff interface, then it should be allowed to cancel a waiting hold but not allowed to create a cancellation request regardless of the hold cancellation policy. If the API is meant to be equivalent to a user in the OPAC, then it should not be allowed to cancel a waiting hold and should only be allowed to create a cancellation request if the waiting hold cancellation policy is set to Yes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 40660] New: Authority record needs a link to modification log
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40660 Bug ID: 40660 Summary: Authority record needs a link to modification log Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Modification logs are available in many places in Koha. However, there is no link to a modification log when viewing an authority record. In order to look at an authority log, the user has to go to Tools > Logs, select authorities and then enter the object (authority record number). Not a big deal, but maybe not as convenient as accessing the log from the authority record where the record number is automatically entered into the object field. It would be nice if the modification log was accessible from the authority record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43762] New: FilterSearchResultsByLoggedInBranch needs more information when hiding info
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43762 Bug ID: 43762 Summary: FilterSearchResultsByLoggedInBranch needs more information when hiding info Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- FilterSearchResultsByLoggedInBranch, whether set to hide or show other library copies, needs to show: Local Copies / Other Copies / Available Available should ALWAYS show the same number, or should be configurable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 42350] New: modborrowers.pl needs to include options for preferred & other name, and middle name field
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42350 Bug ID: 42350 Summary: modborrowers.pl needs to include options for preferred & other name, and middle name field 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Batch patron modifications should include a preferred name and other name reset options next to the first name field. I'm also noticing that middle name is not provided in the batch modification. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 41688] New: Refund modal and amount as NaN, rejected comma separator
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41688 Bug ID: 41688 Summary: Refund modal and amount as NaN, rejected comma separator Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Hello @ll The problem here is on the refund modal, when retrieving the default value before being modified it is NaN because in some cases for decimal separators with comma, the recovery fails due to formatting a value already formatted in js. After a quick search I think it's a return of bug 31513 fix -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 43761] New: Labelling phones
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43761 Bug ID: 43761 Summary: Labelling phones 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Most contact databases these days allow you to indicate what a phone number is (cell, home, office, etc). Should we update Koha to include these identifiers? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 21309] New: Add flag to change password
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21309 Bug ID: 21309 Summary: Add flag to change password Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We should add a flag to patron accounts that, if checked, would require the patron to sign in to their account and change their password. This option could incorporate the following functionality: * Allow patron to sign in with old password then prompt for a new password. * E-mail patron notifying them with the need to change. * When active, it would block checkouts and sip authentication until done. * Anytime a password is changed in the account, whether staff side or opac, the change would clear the flag in the patron account. * Date of change should be time stamped. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 42255] New: Grouped holds counted inconsistently for circ rules
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42255 Bug ID: 42255 Summary: Grouped holds counted inconsistently for circ rules Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 15516 With grouped holds enabled, Koha sometimes counts all holds individually and sometimes counts all of the holds in a group as just 1. To confirm: Enable 1 - set a circ rule with: -- Holds allowed (total): Unlimited -- Holds allowed (daily): Unlimited -- Holds per record (count): 2 2 - Place 2 holds on the same record for the same patron 3 - Try to place a 3rd hold, get an error "too many holds" 4 - group your 2 existing holds 5 - try to place a 3rd hold; it works! 6 - set a circ rule with: -- Holds allowed (total): Unlimited -- Holds allowed (daily): 2 -- Holds per record (count): Unlimited 7 - Place 2 holds in the same day for the same patron 8 - Try to place a 3rd hold, get an error "too many holds" 9 - group your 2 existing holds 10 - try to place a 3rd hold; it works! 11 - set a circ rule with: -- Holds allowed (total): 2 -- Holds allowed (daily): Unlimited -- Holds per record (count): Unlimited 7 - Place 2 holds in the same day for the same patron 8 - Try to place a 3rd hold, get an error "too many holds" 9 - group your 2 existing holds 10 - try to place a 3rd hold; still get an error "too many holds" Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 [Bug 15516] Allow to place a hold on first available item from a group of titles -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 43745] New: Category defaults doesn't work when some checkboxes are disabled
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43745 Bug ID: 43745 Summary: Category defaults doesn't work when some checkboxes are disabled Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: shipra.poojary(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- To create: 1.Navigate to Administration > Patron categories 2.Set up a category with no messaging preferences(inactive) 3.Create a second category with messaging preferences enabled (Advance notice with days in advance, SMS, Email and Digests set up) 4.Open a patron account, change their patron category to the inactive one, check "Reset messaging preferences to category defaults" and save. Confirm no messaging preferences are selected. 5.Change the patron category to the second category(with preferences),check "Reset messaging preferences to category defaults" and save. SMS and email checkboxes are left unchecked, while Digest is checked, failing to apply the category defaults correctly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 43674] New: ISO 18626 messages are missing the mandatory ISO18626Message envelope
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 Bug ID: 43674 Summary: ISO 18626 messages are missing the mandatory ISO18626Message envelope Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: minhpq(a)tinhvan.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- Koha's ISO 18626 implementation sends and expects the message type as the XML document element — <request>, <supplyingAgencyMessage>, <requestingAgencyMessage> — with no enclosing element. The schema at https://illtransactions.org/schemas/ISO-18626-v1_2.xsd defines a single root element: <xs:element name="ISO18626Message"> ... <xs:attribute name="version" use="required"/> and makes request / supplyingAgencyMessage / requestingAgencyMessage children of it. So a conformant implementation rejects Koha's messages at deserialisation, before any business logic runs, and Koha in turn rejects a conformant partner's messages. What Koha sends today: <?xml version="1.0" encoding="UTF-8"?> <request> <header> <requestingAgencyRequestId>2</requestingAgencyRequestId> ... What the schema requires: <?xml version="1.0" encoding="UTF-8"?> <ISO18626Message xmlns="http://illtransactions.org/2013/iso18626" version="1.2"> <request> <header> <requestingAgencyRequestId>2</requestingAgencyRequestId> ... Where this comes from: * Koha::REST::V1::to_xml builds the document element from the first key of the JSON structure, with no wrapper and no namespace. * Koha::REST::V1::parse_xml / _parse_node read an incoming document the same way. * Koha::REST::V1::ILL::ISO18626::message determines the message type with my ($messageType) = keys %$json, i.e. from the document element name, and Koha::ILL::ISO18626::message_types lists the six message types as though each were a root element. A side effect is that there is currently no way for a Koha instance to state which revision of ISO 18626 it speaks, since the version attribute lives on the envelope. How it was found: Testing a Koha 26.05.02 instance against a third-party ISO 18626 implementation written in .NET, generated directly from the official v1.2 XSD. Every message was rejected in both directions until a wrapping/unwrapping shim was added on the third-party side. With that shim, and with three conformance fixes applied to the koha-ill-iso18626 plugin (reported upstream at https://github.com/openfifth/koha-ill-iso18626/pull/5) the full round trip works: Koha sends request, the partner replies requestConfirmation with messageStatus OK, the partner sends supplyingAgencyMessage, vand the Koha ILL request moves to ExpectToSupply with the partner's supplyingAgencyRequestId stored. The envelope was the only remaining deviation. This has probably gone unnoticed because ISO 18626 testing so far appears to have been Koha-to-Koha — the recreation steps on bug 43003, for example, stand up two Koha instances with the same plugin on both. Two endpoints that share the same deviation understand each other perfectly; the problem only appears against an implementation built from the schema. Suggested fix: Handle the envelope in the core XML middleware — add it in to_xml on the way out, and unwrap it in the around_action hook on the way in — so every ISO 18626 route keeps working unchanged and nothing needs to know about it. Accepting both wrapped and unwrapped input for a transition period would avoid breaking anyone mid-upgrade. Related: bug 37762 (supplying agency workflows, where the core ISO 18626 handling was added) and bug 41091 (ISO18626 for borrowing). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42