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

[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

[Bug 40755] New: Hold cancellation requests cause error 500 on holds waiting page
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40755 Bug ID: 40755 Summary: Hold cancellation requests cause error 500 on holds waiting page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression, rel_25_05_candidate Severity: major Priority: P5 - low Component: Hold requests Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 38714 To reproduce: 1. Enable hold cancellation requests from the OPAC i. Go to Administration > Circulation and Fines rules ii. In the "Default waiting hold cancellation policy" section, add the rule: All / All / Yes 2. Place at least two holds for pickup at the logged-in library (for ease of testing, place both holds for the same patron) 3. Check in items for both holds and confirm to set holds to Waiting 4. Log into the OPAC as the patron from step 2 5. Go to the patron's holds tab and request cancellation for both holds 6. In the staff interface, go to Circulation > Holds awaiting pickup ==> Error 500! :( Also, the logs contain the error: ==> /var/log/koha/montgomerytest/plack-error.log <== Template process failed: undef error - The method Koha::Hold::CancellationRequest->0 is not covered by tests! Trace begun at /usr/share/koha/lib/Koha/Object.pm line 1042 Koha::Object::AUTOLOAD('Koha::Hold::CancellationRequest=HASH(0x55609e31c2c0)') called at /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/includes/waiting_holds.inc line 40 It looks like this was caused by a typo in bug 38714 - cancellation_request.0 (object) instead of cancellation_requests.0 (list). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38714 [Bug 38714] Adjust templates for prettier -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 34596] New: Items in transit should not show up in the holds queue
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34596 Bug ID: 34596 Summary: Items in transit should not show up in the holds queue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Libraries have reported that items are still showing up in their holds queue hours after they have been marked as "in transit". Only holds that are ready to be found should be showing up in the holds queue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 41262] New: Duplicate import in Koha::Patron
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41262 Bug ID: 41262 Summary: Duplicate import in Koha::Patron Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor 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 There's two `use C4::Log qw( logaction );`. The newest coming from bug 26744. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12