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

[Bug 43091] New: Staff-only Vue island chunks are emitted into the OPAC dist directory
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43091 Bug ID: 43091 Summary: Staff-only Vue island chunks are emitted into the OPAC dist directory Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: paul.derscheid(a)lmscloud.de Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 26355 Blocks: 41129 Target Milestone: --- The intranet and OPAC islands builds share the same entry point, koha-tmpl/intranet-tmpl/prog/js/vue/modules/islands.ts, which hardcodes every island in its componentRegistry. The islandsExport() factory in rspack.config.js (introduced by bug 26355) only varies the output path per application, so the OPAC compilation emits a lazy chunk for every registered island into koha-tmpl/opac-tmpl/bootstrap/js/vue/dist/: - acquisitions-menu.[hash].esm.js - vendor-menu.[hash].esm.js - admin-menu.[hash].esm.js On top of that, the OPAC islands.esm.js bundles the staff-side Pinia stores (main, navigation, vendors) because hydrate() imports them unconditionally. These chunks are never executed on the OPAC. hydrate() only fetches a chunk when a matching custom element is present in the DOM, and no OPAC template renders one, so this is not a security issue in itself. But it publishes staff-interface code unauthenticated in the OPAC docroot, wastes build output, and is a leak channel by construction: any future staff-side island whose bundle contains something sensitive would land in the public web root by the same mechanism. The attached patch splits modules/islands.ts into shared machinery and per-application entry points (islands-intranet.ts, islands-opac.ts). Each entry declares its islands as a Map literal and feeds it through registerIsland(), so core islands take the same registration path as plugin islands (bug 42150), and passes its store definitions into hydrate() instead of the shared module importing every store. The plugin import surface of islands.esm.js (registerIsland, hydrate, the Vue re-exports used by the import map) is preserved on both entries via star re-exports. After the patch, the OPAC dist contains only islands.esm.js and the patron-self-renewal chunk. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26355 [Bug 26355] Allow patron account renewals through the OPAC https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41129 [Bug 41129] Migrate place_booking.js to a Vue island. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 43092] New: Koha::File::Transport::change_directory(undef) means three different things across FTP, SFTP and Local
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43092 Bug ID: 43092 Summary: Koha::File::Transport::change_directory(undef) means three different things across FTP, SFTP and Local Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Depends on: 43078 Target Milestone: --- Koha::File::Transport's three backends disagree on what change_directory(undef) means: - FTP: Net::FTP's cwd(undef) defaults to "/" and navigates to the server root. - SFTP: Net::SFTP::Foreign's setcwd(undef) clears client-side tracking, falling back to the SFTP session's own home/default directory. - Local: clears the tracked override, falling back to the configured download_directory, or "." (the Koha process's own working directory) if neither is set. The base class's own test_connection() calls change_directory(undef) unconditionally on every config save (via the auto-enqueued TestTransport background job), for both the download and upload directory checks. For a Local transport configured with only one of download_directory/ upload_directory, the untested direction's change_directory(undef) + list_files() call silently lists the Koha process's own working directory (e.g. the Koha install root) instead of failing cleanly or being skipped - not what any of the three backends' behaviour suggests was intended. Test plan: 1. prove t/db_dependent/Koha/File/Transport/Local.t 2. koha-qa.pl -v 2 --more-tests Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43078 [Bug 43078] File transport SFTP backend returns inconsistent list() structure compared to FTP/Local backends -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 40811] New: Enhance Koha::File::Transport API
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40811 Bug ID: 40811 Summary: Enhance Koha::File::Transport API Change sponsored?: --- 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 Looking at bug 38115, it feels like the code that is required to use a transport is too protocol dependent. The current sequence is: 1) Initialize the transport (->find) 2) Attempt to connect 3) Retrieve the configured base path ($file_server->upload_diectory) 4) Manually set the working dir for uploading $file_server->change_directory) 5) Upload the file I believe we should (keeping only this FTP/SFTP use case in mind) simplify to: 1) Initialize (->find) 2) Upload the file with an optional path parameter Step (2) would attempt to connect if the connection is not active, set the path to the passed path or internally pick the default and use it. Any failed step should raise a specific exception. This schema could work for other protocols like S3, etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 36766] New: Add abilities to use SFTP with export_records.pl
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36766 Bug ID: 36766 Summary: Add abilities to use SFTP with export_records.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz In New Zealand libraries need to be able to SFTP MARC files to a remote server to keep the Te Puna union catalogue up-to-date. It would be nice if NZ libraries could automate sending their MARC files in the following way: 1) Use the runreport.pl cronjob to generate a list of bibliographic numbers. 2) Use export_records.pl cronjob to generate the MARC file for those numbers. 3) Use a new cronjob to SFTP the MARC file to the remote server. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 57

[Bug 43173] New: Terminology: Log viewer - "Modify cardnumber" should be " Modify card number"
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43173 Bug ID: 43173 Summary: Terminology: Log viewer - "Modify cardnumber" should be " Modify card number" Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- "cardnumber" instead of "card number" is used in the log viewer: - Actions section: Modify cardnumber - Log view results action column when a patron's card number is changed: Modify cardnumber See the terminology guidelines https://wiki.koha-community.org/wiki/Terminology#C To reproduce: 1. Edit a patron and change their card number under the library management section. 2. Go to Tools > Additional tools > Log viewer. 3. Note under the actions section that there is an action: Modify cardnumber 4. Click "Submit". 5. In the results there is an entry for the patron card number change with the action: "Modify cardnumber". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 43134] New: Standardize use of colon in OPAC advanced search page
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43134 Bug ID: 43134 Summary: Standardize use of colon in OPAC advanced search page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In the OPAC advanced search page, there are currently section titles that use a colon and others do not. We should strive to have all the section titles match each other. To recreate : 1) Go to the OPAC advanced search page http://kohadev.mydnsname.org:8080/cgi-bin/koha/opac-search.pl 2) Click More options 3) Notice that some section titles use colons and others do not - "Search for:" = colon - "Limit to any of the following:" = colon - "Location and availability:" = colon - "Sort by:" = colon - "Publication range" = no colon - "Language" = no colon - "Audience" = no colon - "Content" = no colon - "Format" = no colon - "Additional content types..." = no colon -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 43103] New: Batch item modification and patron deletion query IDs as OR query chains
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43103 Bug ID: 43103 Summary: Batch item modification and patron deletion query IDs as OR query chains Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- As with bug 43101, these OR chains should be replaced with IN based subqueries for improved performance. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

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

19 Oct '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 21

[Bug 33253] New: 2FA - Form not excluded from autofill
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33253 Bug ID: 33253 Summary: 2FA - Form not excluded from autofill Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: tech.sam(a)salinapublic.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I've been testing the 2FA module in our install, working great so far, but I noticed the authentication form field is not marked to be excluded from auto completion. Because of this, after several weeks of use, every time I click on the field, I see a list of all prior authentication codes used. This might be possible to be used in an attack to reverse-engineer the secret key using past codes and when they were entered. Even if that isn't the case, it means browsers are saving loads of unnecessary data that is one-time use. Information on how to disable auto completion in form fields can be found here: https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Tu… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

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

19 Oct '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 20