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

[Bug 42700] New: In C4/SIP/ILS/Patron.pm, hold_items only counts waiting holds
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42700 Bug ID: 42700 Summary: In C4/SIP/ILS/Patron.pm, hold_items only counts waiting holds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I can't find good documentation on this, but I think this is a bug: hold_items => $flags->{WAITING}->{itemlist}, holds_items is currently a count of waiting holds, when it should total holds. Meanwhile unavail_holds is a count of all holds except waiting holds. Some 3rd party SIP machines use this calculation to get a count of "holds to pick up": holds ready for pickup = hold_items - unavail_holds Currently this can produce a negative number. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

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

07 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 32

[Bug 40096] New: Add salutation/ borrowers.title to batch patron modification
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40096 Bug ID: 40096 Summary: Add salutation/ borrowers.title to batch patron modification Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: PC OS: Windows Status: NEW Severity: enhancement Priority: P1 - high Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com, sonia.bouis(a)univ-lyon3.fr CC: sonia.bouis(a)univ-lyon3.fr Salutation/ borrowers.title is an older field that libraries sometimes have data in as a result of migrated data or prior library policy, but it's not the easiest to get in and modify out once they no longer want it. It would be nice if salutation was a field in batch patron modification, either for the ability to update in bulk if a library IS using titles, or to be able to easily blank out values there if the library no longer wants them. Perhaps the field could only display if BorrowersTitles is enabled, at least until 11815 is unblocked, and then conditions could be revisited. --- Comment #1 from Sonia Bouis <sonia.bouis(a)univ-lyon3.fr> --- + 1 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 20638] New: Log actions on API keys
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20638 Bug ID: 20638 Summary: Log actions on API keys 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Actions on API keys shoudl be logged and auditable (i.e. who creates the API keys, who revokes, etc). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 98

[Bug 41902] New: Allow configuration of bibliographic information to be shown on new record duplicate check
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41902 Bug ID: 41902 Summary: Allow configuration of bibliographic information to be shown on new record duplicate check Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In cataloging, when Koha suspects a newly-created record is a duplicate it gives just the title of the existing record. We'd like a system preference in which to use Template Toolkit to define parts of the biblio object to be shown here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 37557] New: Hiding whole fields in MARC bibliographic frameworks
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37557 Bug ID: 37557 Summary: Hiding whole fields in MARC bibliographic frameworks Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliotheca(a)klastervyssibrod.cz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I based a new MARC bibliographic framework on the default one and don´t need most of the fields there, but do not want to delete them, because it´s possible that I´ll want to use them in the future, so I would rather just hide them. But unluckily it´s only possible to hide the subfields one by one and the whole field disappears only after I hid all of the corresponding subfields - which takes very much time to do and is pretty tedious. So what I suggest is to make it possible to hide whole fields in a MARC bibliographic framework with one click (or even to be able to select more of them at once and then hide them all) without having to hide all the subfields one by one first. (By hiding I mean to uncheck all the visibility options by a subfield, or to check the "Flagged" option there.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 41343] New: Overdue report is too intensive on systems with many overdues
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41343 Bug ID: 41343 Summary: Overdue report is too intensive on systems with many overdues Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 35729] New: Coce Should Account for New ISBN 979*
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35729 Bug ID: 35729 Summary: Coce Should Account for New ISBN 979* Change sponsored?: --- 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: kalleen(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, I noticed that there was a cover mismatch with a coce_amazon cover because the new 2024 title has an ISBN of 9798885795692 (using the 979 instead of 978). There is an Italian title with an ISBN of 8885795692 that is showing instead. It looks like they have updated the valid ISBN standards: https://isbn.org/about_isbn_standard and it seems like coce should be updated to recognize this new standard and not match 9798885795692 to be the same as 8885795692. Thanks! Kal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 98

[Bug 42769] New: Add a SIP testing tool to the staff web interface
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42769 Bug ID: 42769 Summary: Add a SIP testing tool to the staff web interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Now that the SIP configuration is mostly in the staff interface, it would be very useful to have a tool not for testing SIP connectivity, but for checking the response value for the various custom template fields we have. I'm imagining a tab within the account editor ( for saved accounts ) where we can enter things like patron and item barcodes to test the generated response. It would be even better if we could wrap that in a transaction so it doesn't actually do anything, but I have the feeling that may prove infeasible. Such a testing tool would eliminate the need for someone to know the password for the SIP account in order to develop and test the various templates and options for that account. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 38655] New: e-books (PDF) to be readable only to authenticated users, Stop download and Print
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38655 Bug ID: 38655 Summary: e-books (PDF) to be readable only to authenticated users, Stop download and Print Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: ujkhatry(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Dear Koha friends, I have a request from a small library. They would like their e-books to be readable only to authenticated users…. The user should not be able to download, print or save the PDF locally. This is to stop the one authenticated users from distributing a e-book among friends. I have searched and searched in Koha and it seems we don’t have such controls. It would be wonderful if the Koha community could guide me on this. Thanks, Ujwal -- You are receiving this mail because: You are watching all bug changes.

1 26