November 2024 - Koha-bugs - lists.koha-community.org

[Bug 36046] New: Choose staff interface homepage default action
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36046 Bug ID: 36046 Summary: Choose staff interface homepage default action Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirjam.vantieghem(a)etf.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently the default action for the top search box on the staff interface homepage is "Check out". This makes sense for library staff working at the circulation desk. However, for libraries using a self-checkout module, that might not be the desirable default action. We would prefer to have "Search catalog" as default action on the homepage. Would it be possible to have libraries choose the default action on the homepage? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 18760] New: printable checkin alerts
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '26

18 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18760 Bug ID: 18760 Summary: printable checkin alerts 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: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Our options right now to display messages at check in are as follow : - put a note in itemnotes, which will display in red in the checked in items table - write something in materials, which will display a proper alert, but dedicated to accompanying materials A new feature is on the way to allow patrons to write notes themselves, on a specific issue but not on the item if i understood correctly, that's bug 14224. This feature will create a new field in the items table: checkin_alert, to allow librarians to have arbitrary alerts displaying at checkin. These alerts will be printable. Use case: the item is an ILL item, and when checking it back in, the librarian wants to have a printed slip with the address of the partner library the item should be sent back to. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[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