November 2025 - Koha-bugs - lists.koha-community.org

[Bug 27691] New: allow HTML in Notes output on guided_reports_start.tt
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '25

29 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27691 Bug ID: 27691 Summary: allow HTML in Notes output on guided_reports_start.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some reports have a long and detailed notes section pertaining to a given report. With the html filter it can be very difficult to parse out those notes. Is there any reason we cannot use a $raw filter in this situation? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 41006] New: Shelving location style changed in many places since Bug 40606
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '25

29 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41006 Bug ID: 41006 Summary: Shelving location style changed in many places since Bug 40606 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Shelving location style changed in many places since Bug 40606 See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40606#c9 -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 37666] New: Make additional fields available via Template Toolkit in notices
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '25

29 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37666 Bug ID: 37666 Summary: Make additional fields available via Template Toolkit in notices Change sponsored?: --- 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: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It seems that is not possible today (or in a complex way?) to display in notices information stored in additional fields defined in admin/additional-fields.pl It could be nice to add this feature, in the same spirit as https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30657 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 40918] New: Invoice Adjustment Reason always "No reason" even if report shows a saved reason
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40918 Bug ID: 40918 Summary: Invoice Adjustment Reason always "No reason" even if report shows a saved reason Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Go to Acquisition. 2. Create a vendor. 3. Click "Receive Shipment" 4. Enter an invoice number and save. 5. Go to Administration->Authorized Values->Add A Category 6. Name it ADJ_REASON 7. Put in 2 options 8. Go to invoices in Aqusition 9. Add an adjustment (enter an amount and select a reason, then save) 10. The reason is set to "no reason" 11. Go to reports 12. new sql report select * from aqinvoice_adjustments 13. Run the report and see your reason is saved. 14. go back to the invoice and click save adjustments 15. run the report again, see there's no longer a reason. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 40292] New: SQL syntax error when upgrading to 25.05 on MariaDB 10.3, RENAME COLUMN unsupported
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40292 Bug ID: 40292 Summary: SQL syntax error when upgrading to 25.05 on MariaDB 10.3, RENAME COLUMN unsupported Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Got this report on Mattermost for 25.05: Configurando koha-common (25.05.01-1) ... Upgrading database schema for biblio Upgrade to 24.12.00.042 [07:56:03]: Bug 39838 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39838) - Rename alias_id -> vendor_alias_id ERROR: {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'COLUMN alias_id TO vendor_alias_id' at line 1 at /usr/share/koha/lib/C4/Installer.pm line 825 After investigation and confirmation, the usage of RENAME COLUMN is the problem. This syntax is unsupported in versions of MariaDB prior to 10.5.3, here's the relevant documentation for reference: mariadb dot com/docs/server/reference/sql-statements/data-definition/alter/alter-table#rename-column The solution is to fix the usage of RENAME COLUMN in the current db_revs and to write a coding guideline and a QA test to accompany it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 74

[Bug 37643] New: Check for NaN instead of truthiness if calendar.inc accepts_time
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37643 Bug ID: 37643 Summary: Check for NaN instead of truthiness if calendar.inc accepts_time Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org The check for truthiness in case calendar.inc accepts time (accepts_time = true) has one flaw: we can't set the time to 00:00. Let's fix it. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 40423] New: Handling x-koha-request-id relies on wrong data structure
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40423 Bug ID: 40423 Summary: Handling x-koha-request-id relies on wrong data structure Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Processing the `x-koha-request-id` header relies on the fact the header is added to the 'reserved_params' earlier by the use of `$c->validation->output`. This is fragile as it relies on an internal data structure from the `Mojolicious::Plugin::OpenAPI` plugin that is not safe or intended to be accessed. Bug 40417 deals with removing that last use in `objects.search_rs` but highlights this situation. In order to keep things clear, I file this bug for dealing with this particular situation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 40424] New: Handling query in body relies on wrong data structure
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40424 Bug ID: 40424 Summary: Handling query in body relies on wrong data structure Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Similar to `x-koha-request-id` handling, it relies on `extract_reserved_params` and the use of `$c->validation->output`, which is incorrect. We need tests for the feature. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 39091] New: Cash registers should have a list API endpoint
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39091 Bug ID: 39091 Summary: Cash registers should have a list API endpoint Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: pedro.amorim(a)ptfs-europe.com Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Blocks: 37893 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37893 [Bug 37893] Migrate some SIP configuration into the staff interface -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 40983] New: Remove deprecated syntax for 'after_biblio_action' hooks
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40983 Bug ID: 40983 Summary: Remove deprecated syntax for 'after_biblio_action' hooks Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 36343 Following the work on bug 36343, which aimed to improve the consistency of our plugin hook signatures, we introduced a new syntax for the after_biblio_action hooks that includes a payload parameter. To ensure backward compatibility, the older signature was maintained but marked as deprecated, with warnings logged when it is used. The purpose of this bug is to complete the deprecation cycle by removing the code that handles the older style syntax and the associated deprecation warnings. This will involve: Removing the compatibility code that checks for and handles the old hook signature (without the payload key). Removing the Koha::Logger warnings that are triggered when the old signature is detected. Updating any relevant documentation to reflect that only the new signature is supported. This will help to clean up the codebase, reduce complexity, and ensure that all plugins are using the modern, consistent hook signature. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36343 [Bug 36343] The 'after_biblio_action' hooks have an inconsistent signature compared to before_biblio_action, and actions in reserves and items -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17