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

[Bug 30279] New: Log when personal data is displayed in staff client
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '25

14 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30279 Bug ID: 30279 Summary: Log when personal data is displayed in staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 The patch allows logging every access to patron personal data by staff members. This enables tracking of abnormal usage patterns in order to discover and mitigate possible data breaches, and the data collected could also be useful for investigators if such an event where to occur. An entry is written to the actions_log table when any page the patron-info sidebar is displayed on is viewed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 32968] New: Create granular permissions for ERM
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32968 Bug ID: 32968 Summary: Create granular permissions for ERM Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: pedro.amorim(a)ptfs-europe.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Depends on: 32925 Currently, there is only one top-level permission for ERM on the system. Example: Allow a staff member to create agreements but not delete them. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32925 [Bug 32925] Display loading info when a form is submitted -- You are receiving this mail because: You are watching all bug changes.

1 81

[Bug 40684] New: Permission error for vendors if user has not full acquisition modul permission
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40684 Bug ID: 40684 Summary: Permission error for vendors if user has not full acquisition modul permission Change sponsored?: --- 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: michaela.sieber(a)kit.edu QA Contact: testopia(a)bugs.koha-community.org With a restricted libarian account (only some acq permissions) it is not possible to see or edit vendors in acquisition . The error message "Something went wrong: Error: Authorization failure. Missing required permission(s)." appears. The patron would need the acquisition permissions which includes budget permissions among other things, otherwise the API blocks the request. To recreate: 1. Log in as superlibrarian 2. Search for a user, for example borrowernumber=17 7. Give permissions for catalogue (staff access) and manage_vendors 8. Log in with this account 9. Go to Acquisition module 10. Click on Search Vendors Check that the error message mentioned above appears -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 34138] New: Real time hold queue can get backed up in busy libraries
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34138 Bug ID: 34138 Summary: Real time hold queue can get backed up in busy libraries Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Hi, In a very busy library the real time hold queue can get significantly behind (1500-1600 entries, for example) when many returns are processed at once. We're just wondering if there is some inefficiency there that we could resolve to make things move through more quickly (batching of requests was my first thought). In fairness, currently this is using database polling and not rabbitmq - the answer very well could be "use rabbit and this will improve" - which actually is an answer I'm willing to accept, if not immediately implement again in this way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 32572] New: We should have a background queue for each job type
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32572 Bug ID: 32572 Summary: We should have a background queue for each job type 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In production we are seeing that ES updates and real time holds queue can overwhelm the background worker and fall behind from "real time" If we had a dedicated worker for each of these jobs we could batch the operations, e.g. Fetch ES jobs until we hit 100 records or run out of queue, then index 100 at a time Indexing 1 record at a time takes a long time for each record -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 38634] New: marc21_framework_DEFAULT.yml refers to non-existant column biblioitems.cn_prefix
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38634 Bug ID: 38634 Summary: marc21_framework_DEFAULT.yml refers to non-existant column biblioitems.cn_prefix Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In file installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml, there is following entry: > 279 - tagfield: "942" > 280 tagsubfield: "k" > 281 liblibrarian: "Call number prefix" > 282 libopac: "Call number prefix" > 283 repeatable: 0 > 284 mandatory: 0 > 285 kohafield: biblioitems.cn_prefix > 286 tab: 9 > 287 authorised_value: "" > 288 authtypecode: "" > 289 value_builder: "" > 290 isurl: > 291 hidden: 0 > 292 frameworkcode: "" > 293 seealso: "" > 294 link: "" > 295 defaultvalue: However the table does not exist in the DB. I have no clue on who is right. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32640] New: Add fields to branches table to improve ILL functionality.
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32640 Bug ID: 32640 Summary: Add fields to branches table to improve ILL functionality. Change sponsored?: --- 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: r.delahunty(a)arts.ac.uk I was recently asked to add the British Library customer code and the ILL library code to the ILL_PARTNER_REQ notice for each of our 6 branches. The partner library will ask for our British Library customer code and Library code for when they need to claim payment from the British Library when lending their items. We also need the partner libraries codes when we loan items to them- we have to complete an online British Library claim form, and the form asks for these details. It makes it easier for us to supply these all in the one email. I have repurposed the branchstate to hold the BL code and the branchfax to hold the ILL library code and they both sit nicely in the notice now- but this is a very UK-centric solution. It would be useful if there were more text fields in the branches table to hold information like this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 21713] New: ExpireReservesonHolidays not obeying calendar
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21713 Bug ID: 21713 Summary: ExpireReservesonHolidays not obeying calendar Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a library has the system preference, ExpireReservesonHolidays set to Don't Allow - and a library has set their calendar to have the day the hold is set to expire as a holiday, the hold will still show the date the library is closed as the expiration date. The calendar is not being considered although the system preference says to obey the calendar. This was found in Koha version 17.11.07, 17.11.10 and in 18.05.02. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 32629] New: Add option for deleting resolved ILL requests to cleanup_database.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32629 Bug ID: 32629 Summary: Add option for deleting resolved ILL requests to cleanup_database.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de At the moment resolved (filled, cancelled) ILL requests cannot be deleted from the staff interface. It would be nice if there was a way to delete them after X days. The status could default to COMP for starters, but we might want to make it configurable in a next step. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 39410] New: Notice display modal should use shadow dom
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39410 Bug ID: 39410 Summary: Notice display modal should use shadow dom Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Whilst we improved the notice display modal in bug 30287, it still doesn't fully reflect how a notice appears for the end user. Because we're not using a shadow dom or embedded iframe, we are including all the styles of the parent page within the notice display. (hence it misleads us to think bootstrap styles are available within notices when in fact we do not include the bootstrap sheets in either HTML email or print notice outputs. I propose using shadow dom to rectify that and ensure notice displays match as closely as possible to how they will display to the end user.. be that printed or in their email. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25