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

[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 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 40422] New: Remove Greybox assets from the staff interface
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40422 Bug ID: 40422 Summary: Remove Greybox assets from the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 40366, 40412, 40418 Blocks: 8290 Once the last few instances of Greybox usage have been removed we can remove the assets. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8290 [Bug 8290] Replace usage of Greybox modals with Bootstrap modals https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40366 [Bug 40366] Update the label export process to avoid Greybox modal https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40412 [Bug 40412] Update the patron card export process to avoid Greybox modal https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40418 [Bug 40418] Update the item type translation process to avoid Greybox modal -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 39488] New: Update Koha::Object(s) to allow for polymorphic classing
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39488 Bug ID: 39488 Summary: Update Koha::Object(s) to allow for polymorphic classing Change sponsored?: --- Product: Koha Version: unspecified 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org This splits out the proof of concept code in bug 39190 that allows for polymorphic Koha Object classing. We update our Koha::Object(s) classes to pass back $result and propose a signature for class selection with resultsets. This allows for subclassing of an object based on a field in a shared table so one can keep methods grouped for their tasks more easily. Example use cases are (S)FTP where we want to store the basic transport details in one table and then dynamically load the right set of transport protocol specific methods based on the transport type. We might also want to update the Account Line classes to work in a similar way, where we store both debits and credits in one table and would want some shared and some specific methods based on the account line type. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 40850] New: Add `Koha::ILL::Request->add_or_update_attributes`
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40850 Bug ID: 40850 Summary: Add `Koha::ILL::Request->add_or_update_attributes` Change sponsored?: --- 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Currently, ILL backends and plugins must implement custom logic to update existing extended attributes on ILL requests, as the core extended_attributes() method only supports adding new attributes and throws duplicate key errors when attempting to update existing ones. This has led to code duplication across multiple ILL plugins (Rapido, INNReach, SLNP) that all implement identical add_or_update_attributes() methods, and forces the Standard backend to use error-prone patterns when managing request metadata. The proposed `add_or_update_attributes()` method in Koha::ILL::Request would provide a safe, efficient way to add new attributes or update existing ones in a single operation, eliminating duplicate key errors and reducing code duplication. This enhancement would immediately benefit the Standard backend (which currently as 6+ locations using the problematic pattern), allow existing plugins to remove their custom implementations, improve performance by only updating attributes when values actually change, and provide a cleaner API for all ILL backend developers. The implementation follows proven patterns already tested in production plugins an d maintains full backward compatibility while solving a common pain point in ILL development. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 40809] New: JS warning should make Cypress tests fail
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40809 Bug ID: 40809 Summary: JS warning should make Cypress tests fail Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 40434] New: Add maxLength to the vendor definition
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40434 Bug ID: 40434 Summary: Add maxLength to the vendor definition Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17