April 2023 - Koha-bugs - lists.koha-community.org

[Bug 33190] New: Add search history button to advance search form if EnableSearchHistory keep
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33190 Bug ID: 33190 Summary: Add search history button to advance search form if EnableSearchHistory keep Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: adam.styles(a)esa.edu.au QA Contact: testopia(a)bugs.koha-community.org Created attachment 148047 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148047&action=e… screen shot of search history button in koha dev box as preview Hi All, I believe the 'search history' feature to be quite useful in daily repeated search work flows, further to this it is a feature fairly hidden behind a drop down UI in the top right when logged in. Therefor to promote the use of this valuable tool and also to improve it's discoverability, I propose the follow new enhancement. User story: * Add 'search history' button to advanced search button groups if 'EnableSearchHistory' sys pref is set to 'keep' Key logic: * If 'EnableSearchHistory' sys pref is set to 'keep' (this is an existing sys pref), an additional 'search history' button will populate at the of the current advance search buttons group * This new button element makes use of the existing syntax for other button on page and loads the font awesome 4.7 history icon which aligns with the buttons action. * The button will not display unless 'EnableSearchHistory' sys pref is set to 'keep', which makes use of a IF statement in the advsearch.tt template file at around line 100 ish (see patch) ``` [% IF Koha.Preference('EnableSearchHistory') %] <div class="btn-group"> <a href="/cgi-bin/koha/catalogue/search-history.pl" class="btn btn-link"><i class="fa fa-history"></i> search history</a> </div> [% END %] ``` I have tested in Koha dev box v22 and all works well. I will create test plan in patch commit message. I am creating my first patch for this very soon, just reading coding guidelines to ensure I patch as community expects. See attached screen shot. I welcome feedback. Thanks. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 27464] New: Extend functionality of AllowHoldsPolicyOverride to prevent some overrides
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27464 Bug ID: 27464 Summary: Extend functionality of AllowHoldsPolicyOverride to prevent some overrides Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: madamyk(a)ckls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If one tries to create a "local use only" item type, there isn't a good way to make it impossible to place holds for anywhere other than its home branch. Setting restrictions on it in Circ rules allows any staff member with permissions to override the hold restrictions. Another option is setting an item to a lost status, but this is certainly not ideal: it clears the status every time the item is scanned, and it affects how it appears in the OPAC. What if there were a way to have finer control over the AllowHoldsPolicyOverride system preference? For instance, allow hold overrides as a separate permission for overriding circulation rules vs. overriding patron restrictions. It seems logical that overriding a restriction to check out to a patron is quite a bit different from ignoring specific circulation rules (if that makes sense). Perhaps another way to work around this would be a checkbox in the circulation rules with an option to "Ignore staff overrides" or something similar? It could be turned on or off for each individual circulation rule. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[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 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 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 32640] New: Add fields to branches table to improve ILL functionality.
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32640 Bug ID: 32640 Summary: Add fields to branches table to improve ILL functionality. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk I was recently asked to add the British Library customer code and the ILL library code to the ILL_PARTNER_REQ notice for each of our 6 branches. The partner library will ask for our British Library customer code and Library code for when they need to claim payment from the British Library when lending their items. We also need the partner libraries codes when we loan items to them- we have to complete an online British Library claim form, and the form asks for these details. It makes it easier for us to supply these all in the one email. I have repurposed the branchstate to hold the BL code and the branchfax to hold the ILL library code and they both sit nicely in the notice now- but this is a very UK-centric solution. It would be useful if there were more text fields in the branches table to hold information like this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 21713] New: ExpireReservesonHolidays not obeying calendar
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21713 Bug ID: 21713 Summary: ExpireReservesonHolidays not obeying calendar Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a library has the system preference, ExpireReservesonHolidays set to Don't Allow - and a library has set their calendar to have the day the hold is set to expire as a holiday, the hold will still show the date the library is closed as the expiration date. The calendar is not being considered although the system preference says to obey the calendar. This was found in Koha version 17.11.07, 17.11.10 and in 18.05.02. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 32629] New: Add option for deleting resolved ILL requests to cleanup_database.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '25

13 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32629 Bug ID: 32629 Summary: Add option for deleting resolved ILL requests to cleanup_database.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de At the moment resolved (filled, cancelled) ILL requests cannot be deleted from the staff interface. It would be nice if there was a way to delete them after X days. The status could default to COMP for starters, but we might want to make it configurable in a next step. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8