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

[Bug 25222] New: Add ability to let plugins live in individual subdirectories
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25222 Bug ID: 25222 Summary: Add ability to let plugins live in individual subdirectories 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org >From Tomas: "We really need to put each plugin in its own subdirectory (to identify them individually) and have a metadata file we can refer to." This would make things much more manageable. Right now, plugins get all mixed together in the plugins directory. For example, installing the kitchen sink plugin results in Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm being created in the plugins directory. Installing CoverFlow will create CoverFlow.pm in the same directory as KitchenSink.pm. There is no reason that plugins cannot be created to install in a subdirectory directly in the kpz file. In that case, the plugins directory would contain something like kitchen-sink/Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm, while CoverFlow would live in coverflow/Koha/Plugin/Com/ByWaterSolutions/CoverFlow.pm. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 46

[Bug 38198] New: Expired patrons can still make purchase suggestions through OPAC
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38198 Bug ID: 38198 Summary: Expired patrons can still make purchase suggestions through OPAC Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: rkuiper(a)roundrocktexas.gov QA Contact: testopia(a)bugs.koha-community.org We would like to add the ability to block expired patrons from placing purchase suggestions. Maybe add this to the BLOCKEXPIREDPATRONOPACACTION system preference as an option? -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 38487] New: Budget permissions need more granularity
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '26

17 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38487 Bug ID: 38487 Summary: Budget permissions need more granularity Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: catrina(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In a consortia, libraries need to be able to create budgets that cannot be edited by other libraries. However, the permissions in Koha are not granular enough to be able to accommodate that. Even without the budget_manage_all permission, libraries can view ALL budgets from Acquisitions > Administration: Budget (from left navigation). Selecting the green hyperlink returns a "No Fund Found" error (correctly). However, the Action buttons are available and libraries can edit another library's overall budget amount and add funds to that budget. They shouldn't be able to do this without the budget_manage_all permission. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 36135] New: Add tool to batch edit pick up dates of holds
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '26

17 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36135 Bug ID: 36135 Summary: Add tool to batch edit pick up dates of holds 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: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are sometimes situations where libraries have to extend their holds pick up dates. We should at same kind of tool for this like "Batch extend due dates". However criteria for dates to extend can be complicated (we've excluded e.g. items with specific state, holds with found status, items on transfer to specific library). So rather than using predefined criteria for holds to edit (at least for the start), tool should have option to upload file of SQL query results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 268

[Bug 35811] New: Adding a new item type does not clear cache (causing new type to not show properly in OPAC)
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '26

17 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35811 Bug ID: 35811 Summary: Adding a new item type does not clear cache (causing new type to not show properly in OPAC) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Item type descriptions are cached with cache key of 'itemtype:description:'.$lang, which is used by function C4::Biblio::GetAuthorisedValueDesc, used for example in OPAC during display of item's item type in the details view table: https://github.com/Koha-Community/Koha/blob/3df1cb33c277925b689b1e45c736ea8… The problem is, when a new item type is added, that cache key isn't flushed, meaning the new item type won't be displayed in OPAC, an empty field will be shown instead. Flushing memcached mitigates this issue. The cache key is cleared here during tests for instance: https://github.com/Koha-Community/Koha/blob/3df1cb33c277925b689b1e45c736ea8… I suspect the cache flushing should occur in `admin/itemtypes.pl`, after $op 'add_validate'. However, I'm not sure how to get the list of all languages to purge (and I assume all of them should be purged). I've found code snippet below, but I'm not sure if this approach would be acceptable (after adjusting the regex of course), given this gets cache by `Koha::Cache::Memory::Lite->get_instance` instead of `Koha::Caches->get_instance`... my $memory_cache = Koha::Cache::Memory::Lite->get_instance; for my $k ( $memory_cache->all_keys ) { $memory_cache->clear_from_cache($k) if $k =~ m{^CircRules:}; } I've also found this snippet (I see itemtypes.pl calls ->store, so this gets called too): https://github.com/Koha-Community/Koha/blob/2ce83fc784ad8bc716bd65f14845141… It seems to purge only English, which might be why I experienced the issue that I've experienced. So the question that prevails then is: how do we purge all the used languages? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 24843] New: Allow batch change of framework
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '26

17 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24843 Bug ID: 24843 Summary: Allow batch change of framework Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Koha should give users some method to change the framework of multiple records at once. Batch record modification cannot currently do this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 23111] New: Setting a custom framework as the default for cataloguing is not possible
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '26

17 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23111 Bug ID: 23111 Summary: Setting a custom framework as the default for cataloguing is not possible Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: hayleymapley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Currently, it is not possible to select a custom framework as the default, in situations where editing a record with no framework mapped, or importing a staged MARC file with no mapping. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 86

[Bug 36897] New: Make it possible to use select[multiple] and select[size] in a sidebar
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '26

17 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36897 Bug ID: 36897 Summary: Make it possible to use select[multiple] and select[size] in a sidebar Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com https://git.koha-community.org/Koha-community/Koha/src/commit/1ea4a11c2a88f… sets the height of aside fieldset select to a calculated "one fat line" which is fine for <select>, but for <select multiple> and <select size="10"> it turns what should be a multiline box into one line with a nearly invisible scrollbar. The fix is simple, a rule (like the one that exists in bootstrap.scss, which isn't specific enough to overrule the aside fieldset select rule) right after that for select[multiple], select[size] { height: auto; } but I don't quite know how to formulate a test plan for something unused other than by the advanced cataloging editor, which is working around the problem in bug 36589. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 24712] New: Use YAML files for some of the update data
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '26

17 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24712 Bug ID: 24712 Summary: Use YAML files for some of the update data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Depends on: 13897, 24262 Bug 13897 with bug 24262 refine our translation process for install files converting the old SQL files used in the installer for mandatory and optional data into YAML files and adding processing to allow centralised translation of those files alongside the rest of the translation project. It raises the question, however, of how we should deal with the same data during upgrades. Currently we add the American English values with standard SQL in an atomicupdate file (copied into updatedatabase at push time). I'm envisaging we may be able to do away with the atomicupdates for this type of data insertion during upgrade and replace it with a step inside updatedatabase that pulls the data, translations and all from the yaml files. Opening this bug to discus and attempt such an implementation. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13897 [Bug 13897] Use YAML files for installer data https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24262 [Bug 24262] Translate installer data in YAML format -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 21329] New: Purchase Suggestions Add Custom Fields
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '26

17 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21329 Bug ID: 21329 Summary: Purchase Suggestions Add Custom Fields Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be great if we could add custom fields to the purchase suggestion form, preferably set by library or hierarchical group. This would allow us to ask additional questions (Such as would you like a hold if we purchase this item, would you like to request an ILL if we don't purchase this item? etc.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26