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

[Bug 43766] New: Performance issues when staging a large file into a basket
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43766 Bug ID: 43766 Summary: Performance issues when staging a large file into a basket Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 Target Milestone: --- Noting issues here that we can fix, I am still profiling to look for more, but some low hangning fruit: Koha/Import/Record.pm: sub _get_syspref_mappings { fetches the same yaml pref for each biblio - can be fetched and passed through to reduce call This sub also calls: sub _verify_number_of_fields { Which loops through the record to count the fields - we verify the count, then return to the caller and loop through the fields again to store them - we should store during the count and pass back We call 'GetBudgetByCode' for each record/item - and we don't cache or reuse - we should do this to reduce calls (especially as orders are often grouped by budget) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43518] New: Add a reusable PatronSelect Vue component with patron search
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43518 Bug ID: 43518 Summary: Add a reusable PatronSelect Vue component with patron search Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle(a)bywatersolutions.com Blocks: 41129 Target Milestone: --- This patch adds a reusable PatronSelect.vue component: a searchable, debounced patron picker built on v-select, showing age and library context in results, with loading/disabled states and slots for custom option/no-options/spinner rendering. It also adds a paginated patrons.search() method to fetch/patron-api-client.js, used by the new component to query the patrons API. This is generic UI infrastructure with no feature-specific behaviour; it's split out from bug 41129 (booking workflows), where it was originally extracted from inline logic in the booking patron-selection step, because it benefits from independent review and other patron-picking UIs can reuse it. Test plan: 1. Run: yarn cypress run --component --browser electron --spec 't/cypress/component/PatronSelect_spec.ts' 2. Verify the component mounts, debounced search calls the API, and selecting an option emits the expected value. Referenced Bugs: 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. You are the assignee for the bug.

1 18

[Bug 39054] New: a need to distinguish between manual bibliographic record modifications and those being a consequence of authority modification
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39054 Bug ID: 39054 Summary: a need to distinguish between manual bibliographic record modifications and those being a consequence of authority modification Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Now in action_logs, Koha does not distinguish between manual bibliographic record modifications and those being a consequence of authority modification. Both are logged in the same way: module: CATALOGUING ; operation: MODIFY ; interface: intranet. IMO it would be helpful to be able to distinguish this two cases. (For instance to be able to evaluate a librarian's 'koha' in the cataloguing process: a single action of modification of one authority record launching a modification of, say, 100 bibliographic records does not equal to manual modification of 100 bibliographic records. Also, if we trace issues in bibliographic records after modification being performed and want librarians to correct themselves, a biblio modification being a consequence of an authority modification should not be taken into account. Etc.) Comment are welcome. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 31506] New: Add "backup days" to /etc/koha/koha-common.conf
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31506 Bug ID: 31506 Summary: Add "backup days" to /etc/koha/koha-common.conf Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com koha-run-backups takes the --days argument to say how many days of backup we should keep around. The value of this is set to two in the default /etc/cron.daily/koha-common that is installed by the Debian packages. I routinely increase this value to keep more backup. One thing that can happen now is that I want to create fresh backups for all the sites on a server before doing an upgrade. So I run koha-run-backups manually, but I forget about the --days argument. Result: I loose a lot of backup! It would be nice if the default for --days could be set somewhere like /etc/koha/koha-common.conf. That way we could run koha-run-backups both from cron and manually, without the --days argument, and keep the same amount of backups either way. If --days is given as an argument, it should override the default. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 27138] New: Host items are not included in Z39 results when using EasyAnalytics
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27138 Bug ID: 27138 Summary: Host items are not included in Z39 results when using EasyAnalytics Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a library enables EasyAnalytics and links two records in the catalog then the host items show on the child record. If you search for these records via Z3950 (via zebra directly or the responder) the host items are not shown -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 65

[Bug 43748] New: Have option to renew/extend holds on a bib record
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43748 Bug ID: 43748 Summary: Have option to renew/extend holds on a bib record Initiative type: --- Sponsorship --- status: 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: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- At public libraries, publication dates on popular titles are sometimes delayed by over a year. Many libraries also set holds to expire automatically after a year with the cancel_unfilled_holds.pl cron job It would be great if there were a tool or workflow to override the expiration on holds for titles that need a few more months before they are published. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 43459] New: Librarian with permission order_manage should be able to see all vendors
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43459 Bug ID: 43459 Summary: Librarian with permission order_manage should be able to see all vendors 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 Target Milestone: --- Bug 40684 added rights for users with erm permission to list vendors, but this should also be given to users that manage orders since they need to list vendors before actiong on orders -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 43763] New: Hold cancellation request via API does not respect waiting hold cancellation policy
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43763 Bug ID: 43763 Summary: Hold cancellation request via API does not respect waiting hold cancellation policy Initiative type: --- Sponsorship --- status: 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: andrew(a)bywatersolutions.com QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Koha's API is able to cancel holds and create a hold cancellation requests when the hold policies say such a request is not allowed. To recreate: - have a waiting hold - set waiting hold cancellation policy to No - attempt to cancel via API without x-koha-override value - your holds is cancelled - create a new waiting hold - waiting hold cancellation policy still at No - attempt to cancel via API with x-koha-override value "cancellation-request-flow" - hold cancellation request is created If the API is meant to be equivalent to a user in the staff interface, then it should be allowed to cancel a waiting hold but not allowed to create a cancellation request regardless of the hold cancellation policy. If the API is meant to be equivalent to a user in the OPAC, then it should not be allowed to cancel a waiting hold and should only be allowed to create a cancellation request if the waiting hold cancellation policy is set to Yes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 40660] New: Authority record needs a link to modification log
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40660 Bug ID: 40660 Summary: Authority record needs a link to modification log Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Modification logs are available in many places in Koha. However, there is no link to a modification log when viewing an authority record. In order to look at an authority log, the user has to go to Tools > Logs, select authorities and then enter the object (authority record number). Not a big deal, but maybe not as convenient as accessing the log from the authority record where the record number is automatically entered into the object field. It would be nice if the modification log was accessible from the authority record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43762] New: FilterSearchResultsByLoggedInBranch needs more information when hiding info
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43762 Bug ID: 43762 Summary: FilterSearchResultsByLoggedInBranch needs more information when hiding info Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- FilterSearchResultsByLoggedInBranch, whether set to hide or show other library copies, needs to show: Local Copies / Other Copies / Available Available should ALWAYS show the same number, or should be configurable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3