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

[Bug 43082] New: Flaky action_logs.t object filter test due to default LIKE matching
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43082 Bug ID: 43082 Summary: Flaky action_logs.t object filter test due to default LIKE matching Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- This patch fixes an intermittent failure in t/db_dependent/api/v1/action_logs.t. The 'object filter returns rows for object 42' assertion queries the REST API with ?object=42. Koha's REST API defaults every typed query parameter, including integer columns, to _match=contains, which builds a LIKE '%42%' query (Koha/REST/Plugin/Query.pm). This means the filter also matches any object value that merely contains "42" as a substring, e.g. 420, 142, 1042. The test's own fixture data uses a dynamically assigned patron borrowernumber (auto_increment, never reset by transaction rollback) as the object value for other rows logged in the same subtest. When that value drifts into a range containing "42" as a substring during a full CI run, the assertion intermittently counts an extra row and fails, even though the test passes reliably in isolation. The fix adds _match=exact to the object filter request, matching the test's actual intent of an exact object id match. Test plan: 1. Run prove t/db_dependent/api/v1/action_logs.t - it passes. 2. To see the underlying bug, insert an action_log row with object 42 and another with object 420, then query GET /api/v1/action_logs?object=42 without _match=exact - both rows are incorrectly returned. 3. Apply the patch and repeat step 1 - only the exact-match row is expected and returned. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 43078] New: File transport SFTP backend returns inconsistent list() structure compared to FTP/Local backends
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43078 Bug ID: 43078 Summary: File transport SFTP backend returns inconsistent list() structure compared to FTP/Local backends Initiative type: --- Sponsorship --- status: 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 Target Milestone: --- The polymorphic file transport classes (FTP, SFTP, Local) are intended to provide a consistent API across transport backends, wrapping existing CPAN modules (Net::FTP, Net::SFTP::Foreign) alongside a local filesystem implementation. The list() method on the FTP and Local backends returns an array of flat hashrefs, each containing file metadata (filename, size, modification time, etc.). The SFTP backend, however, returns metadata partially nested inside Net::SFTP::Foreign::Attributes objects, as this is the native return structure from Net::SFTP::Foreign. This means callers of list() currently need to know which backend they're talking to in order to correctly extract file metadata, which defeats the purpose of the shared API. Steps to reproduce: Instantiate the FTP or Local transport class and call list() on a directory Instantiate the SFTP transport class and call list() on the same logical directory Compare the structure of returned metadata — SFTP results include nested attribute objects; FTP/Local do not Expected behaviour: All three backends return metadata in the same flat hashref structure for a given list() call. Suggested fix: Flatten the relevant fields out of Net::SFTP::Foreign::Attributes (size, mtime, permissions, etc.) into the same flat hash shape used by the other two backends, within the SFTP wrapper class. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 43053] New: Vendor payment methods are not displaying correctly
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43053 Bug ID: 43053 Summary: Vendor payment methods are not displaying correctly 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: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To recreate: 1) Add multiple vendor payment method authorised values 2) Create a vendor and add multiple payment methods 3) Click to edit, the payment method will be displaying one option of a "|" concatenated string -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 42845] New: Access to ILL requires parameters => 'manage_sysprefs'
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42845 Bug ID: 42845 Summary: Access to ILL requires parameters => 'manage_sysprefs' Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: nugged(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 Depends on: 37762 Target Milestone: --- The ILL Vue app reads `ILLModule` and `ILLPartnerCode` through the system preferences service when it starts. That service requires `parameters/manage_sysprefs`, so a staff user with ILL permissions but without system preference administration permissions cannot load the ILL module. Steps to reproduce: 1. Enable `ILLModule`. 2. Set `ILLPartnerCode` to an existing patron category used for ILL partners. 3. Create a staff user with ILL permissions, but without `parameters/manage_sysprefs`. 4. Log in with that staff user. 5. Go to the staff ILL module at `/cgi-bin/koha/ill/ill.pl`. Expected result: The ILL module loads for a staff user with ILL permissions. Actual result: The ILL module cannot load its runtime configuration because the system preferences service returns an authorization failure. Depending on the UI path, the user may see an error such as `Something went wrong when loading the table. 401: Unauthorized`, followed by JavaScript errors caused by missing configuration data. Technical note: This is the same class of issue as bug 33606 for ERM. The proposed patch adds a module-specific `/ill/config` endpoint protected by the `ill` permission. It returns only allow-listed, non-secret ILL configuration values needed by the ILL Vue app. It does not expose the generic system preferences API, and `/api/v1/sysprefs` remains restricted to `parameters/manage_sysprefs`. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37762 [Bug 37762] Expand ILL to allow for supplying agency/lending library workflows -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 41116] New: Selectors are inconsistently structured in hold found modals
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41116 Bug ID: 41116 Summary: Selectors are inconsistently structured in hold found modals Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The hold found modals (#hold-found-modal for not-yet-waiting holds, #hold-found1 for holds already at Waiting status) have clear selectors for most parts of the patron contact info, but the patron's phone number doesn't get any class or id of its own and the patron's email has an id that excludes the bullet point. That makes these two values harder to hide or style with CSS. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 30759] New: Add hint about the data that is sent via the Google Books API to OPACSuggestionAutoFill
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30759 Bug ID: 30759 Summary: Add hint about the data that is sent via the Google Books API to OPACSuggestionAutoFill Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 14242 On bug 14242 Victor suggested to add a hint to the OPACSuggestionAutoFill system preference that explains about possible implications to data privacy and lists which data is sent via the Google Books API: (In reply to Victor Grousset/tuxayo from comment #118) > And meanwhile, should a small warning in the syspref description be added? > So the library can update their documents about their personal data > processing. > > Something like «Personal data processing: Google will receive the following > data: IP address, OS name, web browser version, preferred languages, and the > ISBNs of the books suggested.» Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14242 [Bug 14242] Use ISBN-field to fill out purchase suggestions using Google Books API -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 40668] New: Library groups and seperateholdings with itemgroups prevents adding items to itemgroup
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40668 Bug ID: 40668 Summary: Library groups and seperateholdings with itemgroups prevents adding items to itemgroup Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1. On a single record, create at least 20 items at Centerville, 10 at Fairfield, 10 at Fairview 2. create a library group that has Fairfield and Fairview and check Limit item editing to items owned inside of this group. 3. Enable EnableItemGroups & SeparateHoldings 4. Set a patron (I used Henry) to have a password you know and the following permissions: -Staff access (catalogue) -Edit Catalog -Edit Items -Create, update and delete item groups, add or remove items from an item group 5. Set their library to Fairfield 6. Create an item group on your record. 7. In another browser/guest window, log in as your patron from step 4. 8. Navigate to your record. 9. Navigate to the "Other holdings" page, there should be no checkboxes. 10. Use the filters or the table search to filter to Fairview, there should now be checkboxes. 11. If you click a checkbox, you are not shown the section: Actions: Add/move to item group Remove from item group The check only happens when the table loads based on if the first page of results has s selectable items or not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 40201] New: Subscription search form on the start page is missing additional fields
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40201 Bug ID: 40201 Summary: Subscription search form on the start page is missing additional fields Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: clemens.tubach(a)kit.edu, michaela.sieber(a)kit.edu The searchable additional fields for subscriptions are not shown in the search form on the start page and it's easy to miss, that they can be searched from the "advanced search" that is reachable through the "more options" in the top search bar. It would be better if both forms would be consistent. To test: - Add at least one additional field for subscriptions that is searchable - Go to the serials module start page - Confirm the search form doesn't show the additional field - Click on the "More options" icon at the end of the top search bar - Click on the "Advanced search" link - Confirm that the additional fields display on this form. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 42314] New: Add `Koha::Library->calendar`
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42314 Bug ID: 42314 Summary: Add `Koha::Library->calendar` 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be handy to have such method, as calendars are always scoped to a library. It would save some includes and circular dependency risks too. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 35797] New: REST API: Add GET route for patronimage
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35797 Bug ID: 35797 Summary: REST API: Add GET route for patronimage 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: shi-yao.wang(a)inLibro.com CC: tomascohen(a)gmail.com Add GET route to get patronimage database table data -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 95