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

[Bug 33182] New: Expand options for OpacItemLocation
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '25

20 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33182 Bug ID: 33182 Summary: Expand options for OpacItemLocation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The options in OpacItemLocation are: -library and call number -library, collection code, and call number -only libray -library, location, and call number These options seem a bit arbitrary. I often have requests to have both collection code and location but that is not possible with the current configuration. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 22178] New: Add start and end date for repeated holidays
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22178 Bug ID: 22178 Summary: Add start and end date for repeated holidays 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- When weekly or other repeating holidays are changed it will always effect dates in the future, but also in the past. For fine calculation and other reasons this can cause problems. It would be nice if it would possible to start and and repeated holidays at specific dates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[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 36434] New: Use a keyword that will be secretly included in all OPAC bibliographic and authority searches
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36434 Bug ID: 36434 Summary: Use a keyword that will be secretly included in all OPAC bibliographic and authority searches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Libraries might repurpose their OPAC to only search certain records. These records might still have relevant collection, item type, shelving location information, so it doesn't work to use these fields to filter OPAC searches on. It might be easier to add a 'keyword' to the MARC for these records, and have Koha secretly apply this keyword to the search, when switched on. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 36007] New: Add the ability to batch edit in Course Reserves
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36007 Bug ID: 36007 Summary: Add the ability to batch edit in Course Reserves Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice to have the ability to batch edit in course reserves. A scenario could be, a course is reactivated, the items in the course are the same, but they all need to be relocated for the course is happening at a different branch, or a different reserve location. A batch edit would allow staff to retain the list of items in the course, but easily update the new course reserves values. At this time, each item would need to be individually edited. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[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 38956] New: Automate MARC Authority Updates with the Library of Congress
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38956 Bug ID: 38956 Summary: Automate MARC Authority Updates with the Library of Congress Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be helpful to pull in regular updates for MARC Authority records rather than manually having to check for updates to subject headings. For example - an author passes away, the current behavior is you need to edit the authority record. It would be beneficial to connect to the LOC database to look for updates automatically. Apis for the LOC https://www.loc.gov/apis/ -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 26744] New: Log changes to extended patron attributes
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26744 Bug ID: 26744 Summary: Log changes to extended patron attributes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It looks like changes to a patron's "extended patron attributes" are not logged, when BorrowersLog is on. They should probably be. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 95

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