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

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

03 Aug '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 23

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

03 Aug '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 22

[Bug 43216] New: Clarify batch record modification: 952/995 rules only create new items
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43216 Bug ID: 43216 Summary: Clarify batch record modification: 952/995 rules only create new items Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools 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: --- When using Batch record modification together with a MARC modification template that adds a 952 (MARC21) or 995 (UNIMARC) field/subfield, staff routinely expect this to modify existing items on the target biblios (e.g. add a collection code to items that already exist). That is not what happens. Batch record modification and its preview (svc/records/preview) both operate on the biblio's stored MARC record without embedding existing items (Koha::Biblio::Metadata->record is called without embed_items). Existing items are therefore completely invisible to the template - the template only ever sees a record with no 952/995 fields, so any 'add field' action for 952/995 produces a brand new, standalone field. At execution time (Koha::BackgroundJob::BatchUpdateBiblio), if the resulting record contains a 952/995 field the job treats it as a request to create a new item (bug 26869) and requires the mandatory subfields (homebranch, holdingbranch, itemtype) to be present, or the record fails with an error such as 'No homebranch subfield found'. The preview step applies the same template but skips this validation entirely, so staff see what looks like a harmless 952$8 being added and are then surprised when the real batch job reports per-record failures. There is currently no UI hint, warning, or documentation calling out that: - 952/995 actions in a batch record modification template only ever create new items, never edit existing ones - mandatory item fields must be supplied by the template itself or the job will fail for every affected record - the preview does not reflect this validation, so a clean preview is not a reliable indicator of success This bug is to track adding a clear warning (in the UI when 952/995 actions are configured in a template used for batch record modification, and/or in the preview screen) plus documentation, so staff are not caught out by this distinction. Batch item modification (tools/batchMod.pl) remains the correct tool for editing fields on already-existing items. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 40817] New: Holds charges should be accessible from Holds
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40817 Bug ID: 40817 Summary: Holds charges should be accessible from Holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, testopia(a)bugs.koha-community.org, tomascohen(a)gmail.com Depends on: 3492 It should be easy to get from a hold to it's associated charges.. i.e. Hold fee, Cancellation fee, any processing fees. This would be useful for API responses and display purposes. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3492 [Bug 3492] Move hold fee setting into circulation rules -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 52

[Bug 43214] New: Could the ILL_PICKUP_READY -notice be sent as a print (by mail)?
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43214 Bug ID: 43214 Summary: Could the ILL_PICKUP_READY -notice be sent as a print (by mail)? Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- The ILL_PICKUP_READY message can be sent by email and/or SMS. Could it also be sent by mail? If the interlibrary loan pickup notification method (email, text message) is not selected and the pickup notification is sent in the interlibrary loan module, no notification goes to the patron at all. It would be great if the ILL-pickup notification was sent to the patron by mail in that case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43140] New: Add possibility to edit the ILL pickup message before sending
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43140 Bug ID: 43140 Summary: Add possibility to edit the ILL pickup message before sending Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: inkeri.hakulinen+bugz(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- Koha ILL module lets user to edit the (email) message you send to another library to order an ILL from them. There is a ready default message (ILL_PARTNER_REQ) for that, but you can edit the message on the go, before sending it. It would be great to be able to edit the pickup message for patron, too. When you send notice for patron, that their ILL is ready for pick-up, Koha just sends it, without any preview, even. It's great that you have a default (ILL_PICKUP_READY) for that, in different languages at best, but sometimes you need to add some information to it, so editing would make this more useful. Please note the bug about the language of the ILL_PARTNER_REQ message is chosen on wrong basis: (We don't want to copy same mistake for this.) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42501 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43213] New: Holds API should have search_limited by library
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43213 Bug ID: 43213 Summary: Holds API should have search_limited by library Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- As noted on bug 18523, with IndependentBranches/Library Groups, you shouldn't be able to see the "Existing holds" for branches you're not allowed to see. Bug 23269 allows you to see all existing holds, however. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 18523] New: Filter Circulation lists on home library
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18523 Bug ID: 18523 Summary: Filter Circulation lists on home library Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using IndependentBranches, items of other sites should not be seen in this Circulation lists for staff users (except for superlibrairians) : - Holds awaiting pickup - Pending on-site checkouts -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 43181] New: Change "Import" to "Stage" on Z39.50/SRU UI
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43181 Bug ID: 43181 Summary: Change "Import" to "Stage" on Z39.50/SRU UI Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Every time I'm giving training for Koha, I have to say "Import" in the Z39.50/SRU UI does not actually import your record into Koha. It stages it for editing. If you don't save the record, it won't be imported - it'll just sit in the reservoir. So I think a better label would be "Stage" instead of "Import", but I'm open to ideas! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 43182] New: Add <<USER_LIBRARY>> to editor substitutions
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '26

03 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43182 Bug ID: 43182 Summary: Add <<USER_LIBRARY>> to editor substitutions Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Currently, <<YYYY>>, <<YY>>, <<MM>>, <<DD>>, and <<USER>> get replaced in the bib and item editors. It would be useful to have <<USER_LIBRARY>> as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7