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

[Bug 36829] New: Add option to generate hold cancellation request from staff interface
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36829 Bug ID: 36829 Summary: Add option to generate hold cancellation request from staff interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com A hold may be waiting at a different branch or desk, or the staff may not have the time to step away and pull the hold due to a line at the desk. It would be helpful to have an option to do a request instead of just cancelling the hold. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 33646] New: "Cataloging search" missing branch data for not for loan items
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33646 Bug ID: 33646 Summary: "Cataloging search" missing branch data for not for loan items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org In the "Cataloging search" (ie /cgi-bin/koha/cataloguing/addbooks.pl), the branch name doesn't appear for "Not for loan" items, which makes the display nonsensical when there are many not for loan items for many branches. It's also inconsistent with the "Search results" (ie /cgi-bin/koha/catalogue/search.pl). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 46

[Bug 28740] New: Delete old ILL requests with cleanup_database
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28740 Bug ID: 28740 Summary: Delete old ILL requests with cleanup_database Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz, tomascohen(a)gmail.com We should teach cleanup_database to delete old ILL requests after a given period. Over in bug 23391, we introduced a syspref in which one can define statuses for which to hide ILL requests. Following that same idea of allowing whatever statuses a given back-end may use, the cron should take a number of days and a status and delete any request with that status that is more than that many days old. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 42334] New: Introduce Koha::Calendar::DateCalculator for date arithmetic
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42334 Bug ID: 42334 Summary: Introduce Koha::Calendar::DateCalculator for date arithmetic 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 Koha::Calendar currently mixes two concerns: calendar data (which days are closed) and date arithmetic (calculating due dates, counting open days, finding next open day). The arithmetic methods all depend on a days_mode parameter that gets passed into the Calendar constructor even though it has nothing to do with the calendar itself, it's a circulation policy. The goal is to extract the date arithmetic methods into a new Koha::Calendar::DateCalculator class that takes a calendar and a days_mode as constructor parameters: ``` my $calc = Koha::Calendar::DateCalculator->new( calendar => $library->calendar, days_mode => C4::Context->preference('useDaysMode'), ); my $due_date = $calc->add_duration( $start, $dur, 'days' ); ``` Methods to move: addDuration, addHours, addDays, get_push_amt, next_open_days, prev_open_days, days_forward, days_between, hours_between, has_business_days_between. This separates the calendar (what's closed) from the policy (how to handle closed days when calculating dates), and removes the days_mode parameter from Koha::Calendar->new where it never belonged. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 22108] New: Items generated through MARCItemFieldsToOrder do not receive values applied in Item Information and Default Accounting Details
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22108 Bug ID: 22108 Summary: Items generated through MARCItemFieldsToOrder do not receive values applied in Item Information and Default Accounting Details Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When adding titles to a basket from a staged file (acqui/addorderiso2709.pl), item and fund choices can be applied item-by-item on the Select To Import tab or can be applied to all titles at once using the Item Information or Default Accounting Details tabs. However, if the library is using MARCItemFieldsToOrder to pull some of these values from vendor-supplied MARC files, Koha will ignore selections made on the Item Information or Default Accounting Details tabs. Nothing in the interface indicates that values selected on those tabs will not be used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 40869] New: Preserve mandatory fields even if hidden when duplicating item
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40869 Bug ID: 40869 Summary: Preserve mandatory fields even if hidden when duplicating item Change sponsored?: --- 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: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When item fields are mandatory, which usually indicate they are somehow critical for functionality and expected to exist in Koha, it makes sense they should be preserved when duplicating an item, even if the field is hidden. Right now hidden fields are ignored using the "ignore_invisible_subfields" option in the form builder for item. If for current library (holding branch) is hidden (which is the case for our library), the biblio page will crash after duplicating an item, which now has a missing holding branch. Fixing this is simple by adding a check for the mandatory attribute in the check for "ignore_invisible_subfields" (I also renamed this option to "ignore_non_mandatory_invisible_subfields" for clarity. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 37441] New: Sometimes images don't upload in Uploads Tool
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37441 Bug ID: 37441 Summary: Sometimes images don't upload in Uploads Tool Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexandre.noel(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org The file upload tool intermittently fails, causing the selected file to disappear without uploading. The second time we want to upload, it will work. Replicate: 1. Go to Tools > Uploads 2. Click "Choose file" and select any file (png, jpeg, pdf...) 3. Click "Upload" -> The file uploads successfully 4. Click "Delete" to remove the uploaded file. -> The page returns to the upload screen. Repeat steps 2 and 3. -> The selected file is deleted, and is not uploaded, requiring the process to be restarted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 42605] New: Acquisition Items not listed during receipt
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42605 Bug ID: 42605 Summary: Acquisition Items not listed during receipt Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Ensure AcqCreateItem is set to 'placing an order' at syspref or on basket 2 - Open a basket, add an order, and add several items 3 - Close the basket and receive shipments 4 - Select the order and 'Receive selected' or click 'Receive' on the order 5 - No items are listed in the items section -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[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