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

[Bug 32791] New: Log4perl configuration files need a tool for updating on package upgrade
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '26

15 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32791 Bug ID: 32791 Summary: Log4perl configuration files need a tool for updating on package upgrade 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Typically, we update existing log4perl.conf files using debian/koha-common.postinst but it's making that file grow way too much and it's difficult to test. Instead, let's provide a CLI tool that we can more easily test and update without touching debian/koha-common.postinst directly. It should hopefully simplify maintenance. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 42577] New: Gettext.js incorrectly located and tidied
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '26

15 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42577 Bug ID: 42577 Summary: Gettext.js incorrectly located and tidied Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you look at opac-tmpl/bootstrap/js/Gettext.js or its intranet-tmpl equivalent, you'll notice that it's actually a third-party script and not a Koha script, so it should be in the "lib" folder and the license for it should be added to about.tt We've also tidied the file because it wasn't in "lib"... so we might want to undo that. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 32489] New: Add check out date, number of renewals, numbers of overdue days in list of overdues
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '26

14 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32489 Bug ID: 32489 Summary: Add check out date, number of renewals, numbers of overdue days in list of overdues Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In circ/overdue.pl it could be useful to add for each line - the check out date - the number of renewals - the number of overdue days (today - due date) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 27105] New: Add checkout notes from staff client
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '26

13 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27105 Bug ID: 27105 Summary: Add checkout notes from staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com AllowCheckoutNotes allows patrons to add notes for a specific checkout from OPAC. It could be useful we could have the same feature on Staff client. Librarians could add some useful informations for checking (annotated or highlighted text before the checkout, book already damaged, needs a new label after the return, etc.). A good feature to have less litigation with patrons when checking books with some problems ! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 41979] New: Use translation in database updates for authorised_values
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41979 Bug ID: 41979 Summary: Use translation in database updates for authorised_values Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com When new authorized values are added to the database through the database updates (for existing installations), they are inserted in English. This causes problems for non-English installations. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

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

12 Jun '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 19

[Bug 30680] New: Behavior due to MARC Overlay Rules should be reflected in Diff view when staging MARC batches for import
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30680 Bug ID: 30680 Summary: Behavior due to MARC Overlay Rules should be reflected in Diff view when staging MARC batches for import Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 Depends on: 14957 To recreate: - create a rule on /marc-overlay-rules.pl to protect the 050 tag when staging for MARC import - export a record from your collection and remove the 050 outside of Koha - reimport that record, matching your incoming record to the one already in your collection - confirm the Diff view on manage-marc-import.pl says the 050 will be deleted - complete import, confirm the 050 was retained We should somehow denote when a field will not be impacted due to an overlay rule. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 [Bug 14957] Write protecting MARC fields based on source of import -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 38527] New: Add logging of reports (created, run, changed and deleted)
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38527 Bug ID: 38527 Summary: Add logging of reports (created, run, changed and deleted) 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: inkeri.hakulinen+bugz(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org For GDPR reasons it would be good to have Koha to log the use of reports. I suggest that the log should include data about -who created which report and when and what the sql was -who run which report and when and what the sql was (the actual sql that was run, since sometimes you choose / fill in some parameters when you run the report) -who changed which report and when and how the sql was changed (before & after) -who deleted which report and when and what the sql was -probably also the updates to the report descriptions would be good to log? However, the results of the reports should not be saved into logs, of course. This addition would bring transparency about the use of the reports. That would be important for preventing misuse of customer data. Now Koha doesn't collect so detailed data, and it would be easy to collect customer data without a trace in the logs. This data would of course be helpful also in cases, when someone accidentally changes a report so that it doesn't work anymore. You could detect the old report from the logs. Also this would help solving crashes that happened due to running too heavy reports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 37901] New: Pseudonymized_transactions should include ILL requests
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37901 Bug ID: 37901 Summary: Pseudonymized_transactions should include ILL requests Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: andrew.auld(a)ptfs-europe.com, katrin.fischer(a)bsz-bw.de, magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com The pseudonymization process aims to duplicate the transactional circulation data from the statistics table in a way that does not allow borrowers to be identified. The statistics table also includes entries for payments and writeoffs that contain the borrowernumber of the impacted patron. We should also record ILL requests in pseudonymized_transactions when pseudonymization is enabled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 151

[Bug 20252] New: If an EDI orderline is cancelled send a cancellation message
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20252 Bug ID: 20252 Summary: If an EDI orderline is cancelled send a cancellation message Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org On cancelling a order if the order has been submitted as an edifact order an ORDCHG message should be generated and transmitted. ORDCHG will contain the order reference and the ean for the item -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11