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

[Bug 38978] New: [24.05.x] Can't hide column in holdings table from Table settings
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38978 Bug ID: 38978 Summary: [24.05.x] Can't hide column in holdings table from Table settings Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. In 24.05.x, hide some columns via Table settings. 2. The columns do not hide properly, you cannot hide any columns via Table settings on this table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

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

[Bug 20955] New: Add ability to trigger holds that violate holds policies (overridden holds)
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '26

17 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955 Bug ID: 20955 Summary: Add ability to trigger holds that violate holds policies (overridden holds) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries would like holds placed by staff that override holds policies to trigger during checkin. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 54

[Bug 31169] New: [OMNIBUS] Problems with forced holds (AllowHoldPolicyOverride)
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '26

17 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31169 Bug ID: 31169 Summary: [OMNIBUS] Problems with forced holds (AllowHoldPolicyOverride) 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When holds are forced, this can create several issues. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 27182] New: Add ability to rename a MARC modification template
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '26

16 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27182 Bug ID: 27182 Summary: Add ability to rename a MARC modification template Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org It would be helpful to add the ability to rename a MARC modification template. There are times when the name originally assigned isn't as descriptive as desired. While it is currently possible to use the 'New template' button to duplicate the template and give it a new name that's not very obvious. And then the old template would need to be deleted. This takes time and it would be more efficient to have a button or action from the main MARC modification template screen for renaming. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34