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

[Bug 38956] New: Automate MARC Authority Updates with the Library of Congress
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38956 Bug ID: 38956 Summary: Automate MARC Authority Updates with the Library of Congress Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be helpful to pull in regular updates for MARC Authority records rather than manually having to check for updates to subject headings. For example - an author passes away, the current behavior is you need to edit the authority record. It would be beneficial to connect to the LOC database to look for updates automatically. Apis for the LOC https://www.loc.gov/apis/ -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 18584] New: Removing trailing-space from our codebase
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18584 Bug ID: 18584 Summary: Removing trailing-space from our codebase Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org This bug report is opened for didactic purpose. If you already contributed to Koha you must not contribute here. -- You are receiving this mail because: You are watching all bug changes.

1 119

[Bug 24806] New: Syspref ILLOpacbackends can not be disbled
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24806 Bug ID: 24806 Summary: Syspref ILLOpacbackends can not be disbled Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: hans.palsson(a)hkr.se The syspref ILLOpacbackends allows admin to choose which ILL-backends that should be available to the user in the OPAC. However, there is no way of _not_ having any backends, even the syspref is described as "If left empty, all installed backends will be enabled". A syspref should not behave like this, if the field is left empty no backends should be available in the OPAC (?). An alternative solution is to set another syspref that enables/disables use of ILL in OPAC. Libraries that do not allow ordering of ILL from the OPAC must be able to hide this feature. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 20930] New: Handle YAML type system preferences as parsed references
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '25

17 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20930 Bug ID: 20930 Summary: Handle YAML type system preferences as parsed references 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: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Currently, C4::Context->preference('YAMLpref') returns a string that needs to be parsed by any code using the preference. My suggestion is to return a parsed version instead (a hash/array ref or a string) and using the syspref cache with the parsed value. Like this, we could: - centralize parsing of YAML system preferences - optimize use of system preference cache by caching the parsed version instead. Parse once and store in cache; no need to re-parse on each call! We could centralize this functionality into Koha::Config::SysPref->value() (used by C4::Context->preference). Use database column systempreferences.type with value of "yaml" to trigger this functionality in "value()"-method. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 35054] New: Waiting hold cancellation rules need to include in transit and staff side cancellations
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '25

17 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35054 Bug ID: 35054 Summary: Waiting hold cancellation rules need to include in transit and staff side cancellations 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the new waiting hold cancellation rule, it only puts items on the cancelled hold table if the patron cancels a waiting hold. It would be helpful if a patron could cancel the hold even while in transit. It would also be helpful if we had an option for staff cancelled holds to be put on that table. Staff that cancel a hold for a patron are not always able to jump up and grab that hold right away. This should be an option. Either a setting with the rule, or an option on the fly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[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 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 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