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

[Bug 40230] New: Remove FIXME in status column of Holds history tab
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40230 Bug ID: 40230 Summary: Remove FIXME in status column of Holds history tab Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: Slodico(a)knoxlib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There is a stray "(FIXME)" in the status column of the Past holds table in the Holds history tab of the staff interface. I suspect it was used as a placeholder for the Hold cancellation reason as it only appears on the records that have a cancellation reason. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 41694] New: Some Koha::Exception::Object instances fail to produce a full_message
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41694 Bug ID: 41694 Summary: Some Koha::Exception::Object instances fail to produce a full_message Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org The specialization of full_message() in Koha::Exception::Object doesn't cover all possibilities – with no message passed in, and for all types except for the enumerated ones, the message ends up empty, never falling back to the parent's full_message. Patch incoming. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41712] New: Add new field to ILL request
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41712 Bug ID: 41712 Summary: Add new field to ILL request Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: kati.sillgren(a)porvoo.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Due date field would be very useful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41711] New: The function Koha::Notice::Templates::find_effective_template selects a (probably) incorrect notice template
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41711 Bug ID: 41711 Summary: The function Koha::Notice::Templates::find_effective_template selects a (probably) incorrect notice template Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When notice templates of a given type are defined for a specific library, but not in all languages, we would likely expect Koha to select the template of that type for the given library in the default language, rather than a generic template in the requested language. For example, if we are looking for: { branch: 'BRANCH', lang: 'es-ES', code: 'CHECKOUT' } and such a template does not exist, we would prefer: { branch: 'BRANCH', lang: 'default', code: 'CHECKOUT' } over: { branch: '', lang: 'es-ES', code: 'CHECKOUT' }. However, Koha currently prioritizes language matching over library matching and therefore returns the template: { branch: '', lang: 'es-ES', code: 'CHECKOUT' }. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 30025] New: BiblioAddsAuthorities is poorly named
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30025 Bug ID: 30025 Summary: BiblioAddsAuthorities is poorly named Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org What it says it does: When editing records, (allow/don't allow) them to automatically create new authority records if needed, rather than having to reference existing authorities. What is actually does: 1 - Allow user to directly edit authority controlled fields in the cataloging module 2 - Link bibs to authorities when a record is added/updated 3 - Only if AutoCreateAuthorities is enabled are new authorities created, otherwise headings manually added in cataloging will remain unlinked -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 56

[Bug 28795] New: ability to add metadata to lists
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28795 Bug ID: 28795 Summary: ability to add metadata to lists Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It could be useful to add metadata to lists, for sorting and managing them. For example a subject field, or some generic fields customisable by the libray, like in patron records -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 38917] New: Lists should have an Expiration date option
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38917 Bug ID: 38917 Summary: Lists should have an Expiration date option Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: kch-tr.lhl-consortium(a)nhs.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be a good enhancement for Lists to have an Expiration date option, much in the same way that Pages and News items do. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 32440] New: Allow selective deletion of statistics entries based on type by cleanup_database
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32440 Bug ID: 32440 Summary: Allow selective deletion of statistics entries based on type by cleanup_database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 24151 Cleanup_database can delete all statistics entries more than X days old. If one is using pseudonymization to create pseudonymized_transactions data, then one may wish to use that cleanup_database function to delete statistics entries that have been duplicated in pseudonymized_transactions. However, not all types of transactions in statistics are duplicated in pseudonymized transactions. Statistics includes checkouts, returns, renewals, payments, writeoffs, and localuse. Pseudonymized_transactions only includes checkouts, returns, and renewals. It would be helpful to be able to delete only statistics entries more than X days old and in a specified list of types. Approaching this from the other end, Bug 32438 suggests adding payments and writeoffs to pseudonymized_transactions. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24151 [Bug 24151] Add a pseudonymization process for patrons and transactions -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 32686] New: Specify action of action_logs entries to purge
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32686 Bug ID: 32686 Summary: Specify action of action_logs entries to purge Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz It would be helpful if libraries could specify the action of entries in the action_logs table to purge. Use case: Libraries with a patron import overwriting patron records several times a day will likely want to truncate member 'create' entries from the action_logs tables, whilst retaining other patron action_logs entries, like below: ./cleanup_database.pl --logs 30 --log-module=MEMBERS --log-action=CREATE --confirm -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 41708] New: Actual costs on Receiving isn't honoring OrderPriceRounding
by bugzilla-daemon＠bugs.koha-community.org 26 Jan '26

26 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41708 Bug ID: 41708 Summary: Actual costs on Receiving isn't honoring OrderPriceRounding Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org 1. Create a Test Vendor with the following settings: - Vendor is active - List prices include tax - Tax rate 7% - Discount 5% 2. New basket with the test vendor (not a standing order), create items when placing an order. 3. Add order, add from an existing record. 4. Select an item type, add item. 5. Select a fund. 6. Vendor price in the accounting details: 27.90 7. Save. Close basket. 8. Receive shipments - Receive a new shipment, add a vendor invoice 9. Receive the placed order a) no shipping costs b) click on Receive at the item c) The actual cost is 26.505. This is correct so far. d) The imaginary invoice shows 26.50. So we delete the last 5 in 26.505. 10. click "Confirm." 11. In the now displayed overview "Already Received," the actual costs are shown as 26.51 instead of the 26.50 that the vendor charged. (The same result is obtained if you explicitly overwrite the last 5 in step 9d with a 0, i.e., enter 26.500.) 12. Finish receiving. 13. Change the system preference “OrderPriceRounding“ to „Round“ or „Don’t round“, depending on what it was before. Repeat all steps. The (faulty) result for the Actual cost should be the same (which shouldn’t be the case). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0