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

[Bug 16910] New: Authority search plugin in cataloguing stops at 15 pages
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '25

21 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16910 Bug ID: 16910 Summary: Authority search plugin in cataloguing stops at 15 pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is similar to the problem fixed in bug 2735, but for the authority search plugin in cataloguing: 1) Go to cataloguing 2) MARC21: open authority search plugin from 100$a for example 3) Notice, it won't page after page 15 -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 17361] New: Add item messages table and rest api endpoints
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '25

21 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17361 Bug ID: 17361 Summary: Add item messages table and rest api endpoints Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This enhancement is to add the ability to create item messages and perform crud operations on them via the rest api only. The interface will be determined on the bug it blocks. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 17297] New: Give librarians the ability to add messages to an item
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '25

21 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17297 Bug ID: 17297 Summary: Give librarians the ability to add messages to an item Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some librarians would like the ability to leave messages attached to an item ( outside the scope of itemnotes and itemnotes_nonpublic ). This feature would give the librarians the ability to add and remove messages of arbitrary types defined in an authorised value list. -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 27675] New: Default checkout, hold and return policy should indicate when set vs unset and should not set null rules
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '25

21 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27675 Bug ID: 27675 Summary: Default checkout, hold and return policy should indicate when set vs unset and should not set null rules Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 These policies can be set to blank, this affects the holds queue and presumably other areas. There needs to be a visual indication of the rule not being set vs the rule being set to blank - or the rule should not save when dropdown is set to 'Not set' To recreate: 1 - Go to Admin->Circulation rules and pick a branch with no rules set 2 - Under "Default checkout, hold and return policy" leave all fields blank and hit save 3 - Check the DB, five rules have been set: SELECT * FROM circulation_rules WHERE branchcode="BRANCH"; 4 - In the staff client, click 'Unset' 5 - There is a warning, but no visible change 6 - Check the DB, the rules are gone -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 22492] New: Advanced editor - Rancor - AdditionalFieldsInZ3950ResultSearch
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '25

20 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22492 Bug ID: 22492 Summary: Advanced editor - Rancor - AdditionalFieldsInZ3950ResultSearch 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: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- With Bug 12747 we added the AdditionalFieldsInZ3950ResultSearch. This currently works in the z39.50 search for the basic editor and in the z39.50 search in acquisitions, but does not work when starting the z39.50 search in the advanced editor for cataloging. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

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

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