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

[Bug 40186] New: Show additional fields in search form on acquisition start page
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40186 Bug ID: 40186 Summary: Show additional fields in search form on acquisition start page Change sponsored?: --- 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: clemens.tubach(a)kit.edu, michaela.sieber(a)kit.edu At the moment the search form on the acquisition start page and on the Advanced search page are slightly different: the first is missing the additional fields. It would be nice if the additional fields showed on both search forms or if that was configurable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[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 28071] New: Ability to batch remove titles from a list
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28071 Bug ID: 28071 Summary: Ability to batch remove titles from a list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Sometimes, lists can have a quite large number of titles. With the export option, it's easy to work on this corpus, and, sometimes, find some titles we finally don't want in that list. If they are numerous, it's for now quite painful to find and delete them. A useful option could be, as it exists with the button "Add items", to be able to remove several titles at a time using barcode or biblionumber. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[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 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 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 32092] New: Improve circulation rules cache utilization
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '26

19 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32092 Bug ID: 32092 Summary: Improve circulation rules cache utilization Change sponsored?: --- Product: Koha Version: master 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: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently the cache is bypassed when fetching of circulation rules in a lot of places, calling get_effective_rule instead of get_effective_rule_value which makes use of in-memory cached. Additionally the case where the rule value is an empty string or undefined or no rule is found are not currently cached which results in the database is being queried repeatedly for cases where no results are found (which usually are the majority of calls). For example on the page where items are listed when placing a hold the current hit ratio for the cache in get_effective_rule_value is about 6%, with this patch we instead get a hit ratio of 99.8%, resulting in a whooping 340x less time spent performing the database lookup in get_effective_rule_value. With 150 items (we have serials with up to 1400 items), about 50% of the execution time is spent looking up rules which is practically reduced to zero when also caching empty results (and replacing the uncached direct calls to get_effective_rule with get_effective_rule_value). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55