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

[Bug 43192] New: Lists cannot be deleted 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=43192 Bug ID: 43192 Summary: Lists cannot be deleted from OPAC Initiative type: --- Sponsorship --- status: 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: david.roberts(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Lists cannot be deleted from the OPAC if they contain items. To reproduce: Log into the OPAC and add a list Add an item to that list. Try to delete it - nothing happens. It generates the following errors in the browser console: Uncaught TypeError: s.escapeHtml is not a function at escape_str (global_25.1106000.js:53:26) at HTMLButtonElement.<anonymous> (opac-shelves.pl:2094:81) at HTMLButtonElement.dispatch (jquery-3.6.0.min_25.1106000.js:2:43064) at v.handle (jquery-3.6.0.min_25.1106000.js:2:41048) To get around this, it is necessary to delete all the items from the list first before you can successfully delete the list -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 43177] New: Use archived link for Bridge Material Type Icon Set
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43177 Bug ID: 43177 Summary: Use archived link for Bridge Material Type Icon Set Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: About Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The page for the Bridge Material Type Icon Set no longer exists, but the Internet Archive has a saved version: https://web.archive.org/web/20240729104520/https://apps.carleton.edu/campus… -- You are receiving this mail because: You are watching all bug changes.

1 15

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

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

[Bug 43168] New: Incorrect error output when staging a file
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43168 Bug ID: 43168 Summary: Incorrect error output when staging a file 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To recreate: 1 - tail -f /var/log/koha/kohadev/intranet-error.log 2 - Stage a marc file 3 - Note the error: ==> /var/log/koha/kohadev/intranet-error.log <== [2026/07/23 19:11:37] [WARN] The following error(s) occurred during ISO2709 record import: ERROR: Koha::ImportBatch::try {...} /kohadevbox/koha/Koha/ImportBatch.pm (105) It seems we get errors as a return from C4::ImportBatch::RecordsFromISO2709File in the routine we define the array variable, and return a ref - which evaluates as 'true' perl -e 'my @errors; $errors = \@errors; warn $errors if $errors;' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

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

14 Sep '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 14

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

14 Sep '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 16

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

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

[Bug 43088] New: Koha::File::Transport lacks a consistent current_directory() accessor across FTP/SFTP/Local
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '26

14 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43088 Bug ID: 43088 Summary: Koha::File::Transport lacks a consistent current_directory() accessor across FTP/SFTP/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 has no consistent, side-effect-free way to query a transport's current remote working directory. Bug 43078 unified list_files() across FTP/Local/SFTP, but left this gap: Net::SFTP::Foreign's cwd() is a pure read-only accessor, but Net::FTP's own cwd() is a mutator - called with no argument it defaults to "/" and issues a real CWD command, changing the connection's directory as a side effect and returning a boolean rather than a path. This surfaced in the koha-plugin-transport-browser plugin, which read $transport->{connection}->cwd directly to capture the initial working directory for its root/breadcrumb navigation. That happened to work for SFTP, but for FTP it silently reset the connection to the server's root directory and captured "1" (a boolean) as the "path", breaking directory navigation for FTP transports - clicking into a subdirectory just reloaded the same listing instead of navigating in. Depends on bug 43078. Test plan: 1. Apply the attached patch on top of bug 43078. 2. prove t/db_dependent/Koha/File/Transport.t t/db_dependent/Koha/File/Transport/FTP.t t/db_dependent/Koha/File/Transport/Local.t t/db_dependent/Koha/File/Transport/SFTP.t 3. koha-qa.pl -v 2 --more-tests reports [PASS] for all changed files with no critic/pod warnings. 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 25

[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