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

[Bug 36736] New: Add ability to load DBIx::Class Schema files found in plugins
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '25

17 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36736 Bug ID: 36736 Summary: Add ability to load DBIx::Class Schema files found in plugins Change sponsored?: --- Product: Koha Version: unspecified 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 Right now, it is not possible to create custom Koha::Object(s) for a plugin without breaking things. For example we did this: BEGIN { my $path = Module::Metadata->find_module_by_name(__PACKAGE__); $path =~ s!\.pm$!/lib!; unshift @INC, $path; require Koha::CurbsidePickupIssues; require Koha::CurbsidePickupPolicies; require Koha::CurbsidePickups; require Koha::Schema::Result::CurbsidePickup; require Koha::Schema::Result::CurbsidePickupIssue; require Koha::Schema::Result::CurbsidePickupPolicy; # register the additional schema classes Koha::Schema->register_class(CurbsidePickup => 'Koha::Schema::Result::CurbsidePickup'); Koha::Schema->register_class(CurbsidePickupPolicy => 'Koha::Schema::Result::CurbsidePickupPolicy'); Koha::Schema->register_class(CurbsidePickupIssue => 'Koha::Schema::Result::CurbsidePickupIssue'); # ... and force a refresh of the database handle so that it includes # the new classes Koha::Database->schema({ new => 1 }); } In the curbside pickups plugin before it was integrated. The problem we've found is that calling Koha::Database->schema({ new => 1 }); resets the database connection and breaks any transactions you were in when the plugin was loaded! We should be able to search for and load any schema files found in plugin directories to make this all unnecessary. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 58

[Bug 40256] New: System defined MANUAL debit type description is hard coded but the description can be changed
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '25

17 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40256 Bug ID: 40256 Summary: System defined MANUAL debit type description is hard coded but the description can be changed Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Go to Admin -> Debit types 2. See MANUAL debit type with the description of 'Manual fee' 3. Click edit and edit the description. 4. Go back to the Debit types admin page. The description still reads "Manual fee" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 40485] New: Hide '+Add guarantee' button on patron details if no patron category can be guarantee
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '25

17 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40485 Bug ID: 40485 Summary: Hide '+Add guarantee' button on patron details if no patron category can be guarantee Change sponsored?: --- 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: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Some libraries don't use guarantor/guarantees. If no patron category is set to 'can be guarantee,' the option to add a guarantee from patron details should be hidden. Broad application would be if no patron categories in a site can be guarantees, but it should probably honor if any patron categories available to that logged-in branch cannot be guarantees. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[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