- 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 6532] Way to move items to another record in batches
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '25

14 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6532 Lillian <l.curanzy(a)newportlibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |l.curanzy(a)newportlibrary.or | |g --- Comment #15 from Lillian <l.curanzy(a)newportlibrary.org> --- Yes, it would be very helpful to move multiple items from one bib to another bib. I can see this used to organize manga, series, magazines, etc. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 35402] Update the OPAC and staff interface to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 Pedro Amorim <pedro.amorim(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41250 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41250 [Bug 41250] Horizontal scrollbar in Koha home page -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 41245] New: Add ability to limit background workers by 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=41245 Bug ID: 41245 Summary: Add ability to limit background workers by job type Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In practice, some job types can cause other job types to get "backed up". It wouuld be good to be able to specify background job workers for specific job types. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[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