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

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

15 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 15 Sep '26

15 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 15 Sep '26

15 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 15 Sep '26

15 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 15 Sep '26

15 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 15 Sep '26

15 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 15 Sep '26

15 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

[Bug 19501] New: New list category to restrict specific lists to staff & hide from OPAC
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19501 Bug ID: 19501 Summary: New list category to restrict specific lists to staff & hide from OPAC 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: Jeremy.evans(a)nibsc.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We are creating various lists of titles that need to be hidden from view in the OPAC for the time being but other staff members need to see them. At the moment the options are Public or Private so this won't do what we require. We would like an additional list category selection of Staff so that those lists are then visible in the staff client (& presumably also to anyone who logs into the OPAC with a staff permissions login) but are not publicly visible in the OPAC. The intention is that multiple staff members may need to add items to some of these lists. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 54