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

[Bug 37449] New: Authority matching using Elasticsearch on 'Number' fields fails
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37449 Bug ID: 37449 Summary: Authority matching using Elasticsearch on 'Number' fields fails Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The query created for authority search always uses `.ci_raw`.. but that doesn't exist for all search field types, including 'Number'. Fridolin added ci_raw for type 'Std Number' in bug 31695 because of this, but I'm not sure that's the right approach globally. We found this when attempting to add a 001 match rule.. local-number defaults to type 'Number' and this never matches anything because 'Number' doesn't include a ci_raw to search against. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[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 32748] New: Library limitations will cause data loss when editing items
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Bug ID: 32748 Summary: Library limitations will cause data loss when editing items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Moving this from bug 31422 where another issue was fixed to a new bug report: The library limitations are used to limit down the selection in pull downs in several spots. If you are editing data from library B while logged in at library A, doing so might result in data loss as the value stored in the modified object might be missing from the drop downs your user sees. Example 1: Item values Itemtype: BK Books - limited to Centerville AV LOC: FIC Fiction - limited to Centerville Your user: logged in for Centerville * Edit an item and make sure it uses the itemtype Books and location Fiction. * Switch library to any but Centerville. * Edit item: Both item type and location drow downs will be empty. * Saving now will empty out itemtype (if not set mandatory) and location resulting in data loss. I initially thought that bug 20256 might help here, but it won't as there is a mismatch of one feature checking the login library and the other checking the home library of the staff patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 74

[Bug 39515] New: Add where parameter to delete_patrons.pl
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39515 Bug ID: 39515 Summary: Add where parameter to delete_patrons.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Some scripts, like delete_items.pl for example, have a -where parameter which allows for SQL statements to be used as additional parameters. It would be useful to have a similar -where parameter in the batch delete patrons script. Library teams have different requirements regarding which patrons should be deleted (and when), and even their own definition of inactive patrons. Having a -where parameter would offer them more flexibility to automatically delete patrons using the script, rather than having to do this manually. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[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 37344] New: Patrons with cancelled discharge are seen as discharged when suspended due to overdue
by bugzilla-daemon＠bugs.koha-community.org 17 Nov '25

17 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37344 Bug ID: 37344 Summary: Patrons with cancelled discharge are seen as discharged when suspended due to overdue Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org GIVEN: 1 - A library with overdue suspension 2 - A user with a cancelled discharge 3 - The same user has an issue whose date_due is gone WHEN: 1 - The book is checked in 2 - The user connects to the OPAC THEN: The user can see they are suspended due to a discharge EXPECTED: The user can see they are suspended due to an overdue -- You are receiving this mail because: You are watching all bug changes.

1 69

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