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

[Bug 42982] New: impossible to scroll down the list of cataloging framework when cataloging
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42982 Bug ID: 42982 Summary: impossible to scroll down the list of cataloging framework when cataloging Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Hi, when we have more than 27 grids and When cataloging a document and wanting to select a specific cataloging framework, it's not possible to see all the Library's cataloging grids. Normally, we should be able to scroll down to see the available options. However, this isn't possible. We must zoom in to access the cataloging grids at the bottom of the list. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 40881] New: Table layout overflow on course interface – table extends beyond container
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40881 Bug ID: 40881 Summary: Table layout overflow on course interface – table extends beyond container Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org The Course interface (Course Reserves) page shows a layout issue: the results table overflows horizontally and extends beyond its container. Steps to reproduce 1. Log in to the staff interface. 2. Go to Course reserves. 3. Click New course, fill in the required fields, and click Save. 4. Click Add reserves, add items or biblionumbers, click Submit, then click Save to add reserve. 5. Click Cancel to see the Course details Table ---> table extends beyond container -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 41717] New: Update PDF::Reuse and PDF::Reuse::Barcode to the latest version
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41717 Bug ID: 41717 Summary: Update PDF::Reuse and PDF::Reuse::Barcode to the latest version Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: chris.nighswonger(a)veritassuperaitsolutions.com QA Contact: testopia(a)bugs.koha-community.org Update PDF::Reuse to the current version 0.43. Update PDF::Reuse::Barcode to the current version 0.09 The existing test suite passes when with both so this should be a pretty straightforward bump. ~/git_repos/koha/Koha(main)$ sg docker -c 'docker exec koha-testing-docker-koha-1 perl -MPDF::Reuse -e "print \$PDF::Reuse::VERSION, chr(10)"' 0.43 ~/git_repos/koha/Koha(main)$ sg docker -c 'docker exec koha-testing-docker-koha-1 perl -MPDF::Reuse::Barcode -e "print \$PDF::Reuse::Barcode::VERSION, chr(10)"' 0.09 ~/git_repos/koha/Koha(main)$ sg docker -c 'docker exec koha-testing-docker-koha-1 bash -c "cd /kohadevbox/koha && prove t/Creators.t t/db_dependent/Labels/t_Label.t"' t/Creators.t ..................... ok t/db_dependent/Labels/t_Label.t .. ok All tests successful. Files=2, Tests=49, 4 wallclock secs ( 0.05 usr 0.01 sys + 3.46 cusr 0.38 csys = 3.90 CPU) Result: PASS -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 42809] New: Notification falls to print back when two messaging preferences are set but only one is valid.
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42809 Bug ID: 42809 Summary: Notification falls to print back when two messaging preferences are set but only one is valid. Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40960#c18 This [Bug 40960] causes problem for patrons with their messaging preferences set to receive both sms and mail and one of the transport types fails. For example when the patron does not have a mail registered but both message types are checked on their account they will receive both sms and printed notices. When using standard/pre-filled messaging preferences based on patron category this can create a large number of unwanted print notices. When a notice is sent with sms OR mail you don't want to create a print notice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[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 01 Oct '26

01 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