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

[Bug 39504] New: Batch record modification 'doesn't exist' condition not checking every matching tag
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '26

06 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39504 Bug ID: 39504 Summary: Batch record modification 'doesn't exist' condition not checking every matching tag Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org I feel like this MARC modification template isn't behaving as I expect it to. I have a biblio record with the following MARC: 700 $a John Smith $e Editor 700 $a Sally Smith I want a template that will add a value in 700$e if 700$e doesn't exist. My MARC modification template action looks like: - Add new field 700$e with value test if 700$e does not exist It doesn't work, probably because the earlier 700 tag does have the $e subfield, so the condition is false and it moves on. I've tried with other variations for the template action, for example - Add new field 700$e with value test2 if 700$e does not match RegEx m/(.*)/ Still doesn't apply, and I think it should be normal to expect that the MARC modification template will look at all 700 tags to apply this action. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 38712] New: Order My Lists options alphabetically
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38712 Bug ID: 38712 Summary: Order My Lists options alphabetically Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: chloe.zermatten(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org In the top header navigation menu on the Koha OPAC, sets the order of the 'My Lists' dropdown to be sorted alphabetically instead of by modification date. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 36682] New: Replace yarn with pnpm
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36682 Bug ID: 36682 Summary: Replace yarn with pnpm Change sponsored?: --- 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: me(a)paulderscheid.xyz QA Contact: testopia(a)bugs.koha-community.org The idea is to deprecate yarn in favor of pnpm as it offers - better disk space efficiency - speed (compared to yarn) - deterministic installs - stricter dependency isolation -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 41069] New: Add a syspref to let libraries provide their desired patron name format
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41069 Bug ID: 41069 Summary: Add a syspref to let libraries provide their desired patron name format 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com >From Bug 30568: I would like to note that we have currently an interesting tree in the queue (under bug 40995) which improve the JS counterpart (patron-format). The inc file is moved to a standalone JS file, Cypress tests are added, and more places are using it. I do understand that we want to make the display more flexible, but here we need to keep the 2 versions in sync: they have the same purpose. However we don't include html tags in the JS function yet (why?) I don't want to block it, but keep in mind that you are not affecting all the occurrences, which introduces more inconsistencies IMO. A better solution seems to have a new syspref to let libraries provide their desire format, you could pick patron's fields, and add punctuation. The both (tt and js) versions of the code will use it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 41934] New: Empty table header in course reserves table causes accessibility error
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41934 Bug ID: 41934 Summary: Empty table header in course reserves table causes accessibility error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: accessibility Severity: normal Priority: P5 - low Component: Accessibility Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org The responsive control column in the OPAC course reserves table contains an empty <th> element. This results in an empty table header and an empty aria-label, which is flagged as an accessibility error by automated testing tools. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 39698] New: Add option to expand responsive datatable rows by default
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39698 Bug ID: 39698 Summary: Add option to expand responsive datatable rows by default Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jake.deery(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org kohaTables on the OPAC are currently configured to display a '+' button, when the table is overflowing. When this '+' is clicked, the overflowing cells are displayed on new lines. I propose a system preference that would control whether this button is a '+' or a '-' by default, and thusly, whether the overflowing cells are shown or hidden. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 42974] New: Acquisitions receiving is not limited by basket owning library
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42974 Bug ID: 42974 Summary: Acquisitions receiving is not limited by basket owning library Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lena.hernandez(a)equinoxoli.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In acquisitions, when receiving order lines and adding them to the invoice, all pending items display, even those from other libraries. It is possible to update and receive items owned by other libraries on baskets managed by other libraries. I would expect that an account with the permissions order_manage and edit_items, but without the permissions order_manage_all or edit_any_item would not be able to receive or modify them. Indeed, the file basket.pl wants order_manage and then farther down it looks like it checks if you own the basket or have the order_manage_all perm, and if not throws the cannot_manage_basket, "You are not authorised to manage this basket." However, it appears that the parcel.pl file for receiving invoices only cares about the order_receive permission and doesn't check any other permissions. This stage of the process should follow other acq permissions and restrict receiving to managing libraries. Bug is applicable for at least versions 24.11 through 26.05. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 41267] New: It should be possible to prevent some itemtypes from filling other biblio level holds
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Bug ID: 41267 Summary: It should be possible to prevent some itemtypes from filling other biblio level holds 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com See bug 40792 and related/dependent bugs. Currently Koha will fill any title level holds on a record when another item on the record is checked out. Some libraries want this behaviour, others don't want it for all item types. E.g. - A library has 'lucky day' item which cannot have holds placed. If a patron finds them in the library they can check them out. In some libraries they have similar circ rules and so the item should fill the hold In other libraries the lucky day items have a shorter circulation period, so the patron may still want the regular book with a longer circ We should add a circulation rule to determine if an item type should or should not fill other biblio level holds Filing as a bug since many libraries consider this a regression -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 55

[Bug 28863] New: Cancel a Pending Notice
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28863 Bug ID: 28863 Summary: Cancel a Pending Notice Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: rcoert(a)arlingtonva.us QA Contact: testopia(a)bugs.koha-community.org We would like the ability to cancel any notice that is currently "Pending" on the Notices tab in a user's account. Also, a record of which librarian cancelled the notice and date/time stamp would be very useful. Use Case: Item is discharged, hold is trapped, & notice is generated. Staff then realizes that the item is badly damaged and reverts the hold to obtain another copy. However, the notice for the original item is now Pending in the account and the email will be sent - even though the item is not on the Hold Shelf. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 40951] New: Optionally show reserve_id to users in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40951 Bug ID: 40951 Summary: Optionally show reserve_id to users in the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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, trevor.diamond(a)mainlib.org The action logs for holds use the reserve_id for "object," which makes the reserve_id necessary for most searching one might want to do in that log. Unfortunately, there's no way to see that reserve_id in the staff interface without a report. For users who spend a lot of time looking at hold logs, it'd be helpful to be able to see the reserve_id from a patron's hold history and a biblio's list of current holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4