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

[Bug 37624] New: Link system preference to entry in the manual
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '26

08 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37624 Bug ID: 37624 Summary: Link system preference to entry in the manual Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Each system preference in the manually can directly be linked to. So wouldn't it be nice if we could link to the entry directly from each system preference in the administration module? Maybe with a small icon or similar, separate from the help link on top of the page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 35452] New: Provide more info when using Link authorities automatically
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35452 Bug ID: 35452 Summary: Provide more info when using Link authorities automatically Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl There are records with many entries that can be linked to authorities, be it secondary authors (7xx) or subjects (6xx) As it is, when you use "Automatic authority link" the results list only indicate the field number, so you see something like this. * 650 - More than one local match found. Possibly a duplicate authority! * 650 - More than one local match found. Possibly a duplicate authority! * 650 - More than one local match found. Possibly a duplicate authority! * 700 - No matching authority found. * 700 - No matching authority found. * 700 - No matching authority found. To figure out which are the entries the results refer to you have to manually check the fields in the record. I think this could improved by adding info about the entries. Something like this. * 650 - Rock music. - More than one local match found. Possibly a duplicate authority! * 650 - Alternative rock music. - More than one local match found. Possibly a duplicate authority! * 650 - Country music. - More than one local match found. Possibly a duplicate authority! * 700 - Ikeda, Elaiza - No matching authority found. * 700 - Okada, Nana - No matching authority found. * 700 - Tsuchiya, Anna - No matching authority found. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 41070] New: No warning when filling no fund while importing in a basket from a file
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41070 Bug ID: 41070 Summary: No warning when filling no fund while importing in a basket from a file Initiative type: --- Sponsorship --- status: 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: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Steps to reproduce. 1 - Go to any record and click save -> marc (Unicode/utf8) 2 - Go to any vendor and add a basket 3 - In this basket, create a new order from file, use the generated file and wait for the end of the import. Click on add staged files to basket. 4 - Select the record, fill in the required information and make sure no Fund is filly, neither in first or third tab. 5 - Validate: There will be no error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 40225] New: The --send-all option in the stockrotation job fails if there are no items to rotate at all
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40225 Bug ID: 40225 Summary: The --send-all option in the stockrotation job fails if there are no items to rotate at all Change sponsored?: --- 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The send-all option claims to send notices even if there are no items to rotate for the given branch; However, if there are no items to action anywhere on the system we skip all notices entirely, not respecting the send-all option. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 36988] New: PUT for patrons requires full borrowers permission, but should only require 'edit_borrowers'
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36988 Bug ID: 36988 Summary: PUT for patrons requires full borrowers permission, but should only require 'edit_borrowers' Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com CC: tomascohen(a)gmail.com On the staff side, a user with only edit_borrowers can make changes to a patron account - for PUT access we require borrowers=>1 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 33991] New: Inventory tool should be run in the background for performance reasons
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33991 Bug ID: 33991 Summary: Inventory tool should be run in the background for performance reasons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The inventory tool takes a long time to run even for small batches of barcodes. This can lead to timeouts and other undesirable user behaviour. It would make sense to perform this computationally heavy workload via the background jobs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 41313] New: When querying for available pickup locations for a biblio, invalid choices are provided
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41313 Bug ID: 41313 Summary: When querying for available pickup locations for a biblio, invalid choices are provided Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When branch transfer limits are in use, the call to /biblios/[id]/pickup_locations gives available pickup locations for all items, regardless of the holdability of the items. This can lead to have wrong choices provided by the api. Since reserve/request.pl also rely on the api to display the available pickup location this can lead to show record-level hold as possible with some available pickup locations although no items are available due to branch transfer limits. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 29016] New: viewlog.pl - Problem with many entries
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29016 Bug ID: 29016 Summary: viewlog.pl - Problem with many entries Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: vitorfernandes87(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The script viewlog.pl it's very slow because it retrieves all action logs at the same time. It should use KohaTables with pagination/number max of returning entries like other Koha tables (API + AJAX wrapper). Test plan: - We need a database with a large number of entries in the action_logs table (200k for example) - Open view logs tool (viewlog.pl) - Select all modules and search - Timeout or a long waiting time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 93

[Bug 41416] New: Poor performance when clicking 'Update hold(s)' on request.pl for records with many holds
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41416 Bug ID: 41416 Summary: Poor performance when clicking 'Update hold(s)' on request.pl for records with many holds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When updating holds priority or other fields on a record with many holds it can take a long time for the server to return. Looking at the code we call ModReserve for each hold on the page - ModReserve call _FixPriority for each hold - _FixPriority loops through every hold on the record an updates the priority to ensure correct ordering. The same outcome can be achieved in less time by calling _FixPriority a single time (per bib) after the loop -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 41048] New: Add ability to disallow empty patron searches
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '26

07 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41048 Bug ID: 41048 Summary: Add ability to disallow empty patron searches Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com In high traffic environments with large numbers of patrons, empty patron searches can take a very long time and cause over-use of resources. It would be good to have the option to require search criteria for patron searches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 54