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

[Bug 20813] New: Revamp user permissions system
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20813 Bug ID: 20813 Summary: Revamp user permissions system Change sponsored?: --- Product: Koha Version: master 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Koha's current user permissions system is a bit convoluted and limited due to it's legacy where the permissions system was a simple set of flags. A second layer of sub-permissions were later added complication and obfuscation to the system. We should revamp the permissions system to be a more modern system and open the path to having unlimited nesting of sub-permissions instead of shoe-horning sub-permissions into the limited system we have. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 101

[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 41932] New: Allow optional zero-padding in items.cn_sort
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 Bug ID: 41932 Summary: Allow optional zero-padding in items.cn_sort Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We have callnumbers like 1 A 1, 10 A 10, 100 A 100 and 1000 A 100. Alphabetically sorting those does not work (100 A 100 < 2 A 2) This proposal includes adding a syspref to define callnumber formats that also specify the desired length when zero-padding cn_sort. This would be active when using C4::ClassSortRoutine::Generic. In the above case we would like to sort them with 0001 A 001, 0010 A 010, 0100 A 100 and 1000 A 100. So the first digit block has length 4, the second block 3. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 89

[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 43674] New: ISO 18626 messages are missing the mandatory ISO18626Message envelope
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 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 26

[Bug 43211] New: Koha hungs when receiving order with AcqCreateItem set to 'receiving an order'
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43211 Bug ID: 43211 Summary: Koha hungs when receiving order with AcqCreateItem set to 'receiving an order' Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com Blocks: 41563 Target Milestone: --- Koha hangs when receiving an order with AcqCreateItem set to "receiving an order". The JavaScript console shows: Uncaught TypeError: unique_item_fields.split is not a function This is most likely caused by the changes introduced in bug 41563. Koha.addPrefs({ [...] UniqueItemFields: [% Koha.Preference('UniqueItemFields') ? 1 : 0 | html %], }); UniqueItemFields should not be reduced to a number. It is expected to be a string containing a list of item fields separated by pipes (|), which is why the code later calls split() on it. To reproduce: 1. Create a basket and set "Create items when" to "receiving an order". 2. Add an order and close the basket. 3. Attempt to receive the order. Koha will most likely hang. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41563 [Bug 41563] Tidy kohaTable block - acqui -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 23998] New: Messages REST API
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23998 Bug ID: 23998 Summary: Messages REST API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi Expose messages table via REST API. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 43463] New: Add sip port to system information page
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43463 Bug ID: 43463 Summary: Add sip port to system information page 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Reading the sip config to output the port can be helpful, for example when confirming to a vendor the sip port. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

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

02 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