October 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 43848] New: Share SIP request parsing and building between server, emulator and tester
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43848 Bug ID: 43848 Summary: Share SIP request parsing and building between server, emulator and tester Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 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: 42769 Target Milestone: --- Bug 42769 adds a tool to the staff interface that runs a SIP2 message through the real SIP handlers (Koha::SIP2::MessageTester). To do that it has to parse a request and build a server context the way the SIP server does, and build requests the way a terminal does. All of this is currently buried in code that also does something else, so each caller ends up with its own copy: - C4::SIP::Sip::MsgType::handle both parses a request and answers it. - C4::SIP::Sip::MsgType::login_core both authenticates a terminal and builds the account, institution, policy and ILS connection it works with. - misc/sip_cli_emulator.pl builds every request a terminal sends, but as subs inside a script, so nothing else can use them. This bug pulls the shared parts out, so the SIP server, the SIP command line emulator and the SIP2 message tester use the same code: - MsgType::parse_message: the part of handle() that sets the field delimiter, checks and removes the error detection suffix and splits a message into fixed and variable length fields. handle() calls it, a caller that only wants the parsed message can get it without anything being printed. - MsgType::build_session: what login_core does once a terminal has authenticated. login_core calls it. - Koha::SIP2::RequestBuilder: the request builders of the emulator, now shared by the emulator and the message tester. - The message tester then reads a request exactly as the handler does (error detection suffix, checksum) and builds requests with the shared builders. There is no change in behaviour for the SIP server. Two small fixes to the emulator come with the move: the item information request carried a language field that the server's template for that message does not have (so the institution field was lost), and a field value of 0 was sent as an empty value. The new tests build each request and have the SIP server's own parser read it back. Test plan: 1. Apply the patches of bug 42769 and then the patches of this bug 2. Run prove t/db_dependent/SIP/ t/SIP/ t/Koha/SIP2/ t/db_dependent/Koha/SIP2/ t/db_dependent/api/v1/sip2_account_test_message.t 3. Confirm that all tests pass 4. Optionally run misc/sip_cli_emulator.pl against a SIP server (-a host -p port -su user -sp password -l institution --patron X --item Y -m patron_status_request -m patron_information -m item_information -m checkout -m checkin) and confirm login and every message still gets a response, and that the item information response names the institution 5. Sign off :-D Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42769 [Bug 42769] Add a SIP testing tool to the staff web interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[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 43310] New: Migrate members/two_factor_auth.tt to use api-client.js
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43310 Bug ID: 43310 Summary: Migrate members/two_factor_auth.tt to use api-client.js Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: martin.renvoize(a)openfifth.co.uk CC: dpavlin(a)rot13.org Depends on: 34451 Target Milestone: --- members/two_factor_auth.tt uses raw jQuery.ajax() for POST calls to /api/v1/auth/two-factor/registration and /api/v1/auth/two-factor/registration/verification. These need to be migrated to api-client.js for proper CSRF token handling (bug 34451). This is also needed for t/db_dependent/selenium/authentication_2fa.t to pass with CSRF protection enabled. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 43391] Add POD to all private subroutines/methods
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43391 Tomás Cohen Arazi (tcohen) <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize(a)openfifth.c | |o.uk -- You are receiving this mail because: You are watching all bug changes.

1 0

[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