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

[Bug 36773] New: Patron search in booking modal doesn't allow searching for cardnumbers with 2 characters
by bugzilla-daemon＠bugs.koha-community.org 03 May '24

03 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36773 Bug ID: 36773 Summary: Patron search in booking modal doesn't allow searching for cardnumbers with 2 characters Change sponsored?: --- Product: Koha Version: unspecified 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, martin.renvoize(a)ptfs-europe.com If you are using short cardnumbers like the famous "42", you can't use that for searching for a patron when booking an item from the staff interface. If you look for "koha" you will find the user, but it will display as koha, null as surname is not set. As this can be the case for all patrons of the organisation type, it would be nice to improve display a little. (not sure if this is really booking specific or if we are using this search elsewhere, might be general) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 36637] New: listOrders for a given biblio_id will return all orders like %biblio_id%
by bugzilla-daemon＠bugs.koha-community.org 03 May '24

03 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36637 Bug ID: 36637 Summary: listOrders for a given biblio_id will return all orders like %biblio_id% Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de CC: tomascohen(a)gmail.com When using the API to retrieve orders for a given param biblio_id, it returns orders where the biblio_id is part of the orders biblio_id. F.e. if the given param is 26, the API will return orders where biblio_id is 262 Maybe this behaviour is intended in order to act as a search filter but i would expect the API, when used with biblio_id, only to return orders where the biblio_id is exactly like the one in the query. To Test: 1) go to http://localhost:8081/cgi-bin/koha/acqui/basket.pl?basketno=1 2) add an order via +Add to basket 3) use an existing record f.e. 9780596004927 4) click addOrder and enter necessary fields, then add item and choose fund to save the order 5) check the biblionumber of the ordered item f.e. 262 6) use the api to fetch orders curl -u koha:koha "http://localhost:8081/api/v1/acquisitions/orders?biblio_id=2" 7) check the biblio_id of the given response -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 34893] ILS-DI can return the wrong patron for AuthenticatePatron
by bugzilla-daemon＠bugs.koha-community.org 03 May '24

03 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34893 Nick Clemens (kidclamp) <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |36575 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32449] New: Plugins: Order the results of GetPlugins/get_enabled_plugins
by bugzilla-daemon＠bugs.koha-community.org 03 May '24

03 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32449 Bug ID: 32449 Summary: Plugins: Order the results of GetPlugins/get_enabled_plugins Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org We still get results back in database insertion order. We could at least order them by plugin class to get more consistent results for running multiple plugins, not relying on installation order. A developer that needs execution in a certain order would be able to control that by class name. Which sounds more reliable to me than installation order. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 36700] New: CSRF: Cannot save a systempreference
by bugzilla-daemon＠bugs.koha-community.org 03 May '24

03 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36700 Bug ID: 36700 Summary: CSRF: Cannot save a systempreference 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org [2024/04/25 11:50:14] [WARN] Programming error - No CSRF token passed for POST http://172.20.21.1:18081/intranet/svc/config/systempreferences (referer: https://master.rijkskoha.nl:28443/cgi-bin/koha/admin/preferences.pl?op=sear…) at /usr/share/koha/Koha/Middleware/CSRF.pm line 82. Fix underway. Diving into js, HTTPClient etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 36769] New: Adding new subfield to 952 in default framework causes 500 error
by bugzilla-daemon＠bugs.koha-community.org 03 May '24

03 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36769 Bug ID: 36769 Summary: Adding new subfield to 952 in default framework causes 500 error 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: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1. Edit the Default framework, 952 tag. 2. Try to add a subfield 12 as a custom note field for the 952. 500 error: Duplicate IDDuplicate IDDuplicate ID [2024/05/02 12:04:51] [WARN] DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Duplicate entry '952-1' for key 'PRIMARY' at /usr/share/koha/lib/Koha/Object.pm line 170 The Default framework uses the numbers 0-9, and letters a-z, with k set aside for libraries that make their catalogs available for z39.50. I'm sure this is an intended limitation to prevent subfields with double digits and characters. Many libraries like to add custom fields to the 952. Some will reconfigure an existing subfield with a new name. It is also possible to add a new field with a capital letter, like 'A'. It may be helpful to add to the documentation on frameworks/subfields in the Koha manual what is actually available for use. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 36681] New: CSRK_TOKEN header should be named CSRF-TOKEN (hyphen instead of underscore)
by bugzilla-daemon＠bugs.koha-community.org 03 May '24

03 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36681 Bug ID: 36681 Summary: CSRK_TOKEN header should be named CSRF-TOKEN (hyphen instead of underscore) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org By default, nginx ignores invalid headers and header names containing underscores are considered invalid https://nginx.org/en/docs/http/ngx_http_core_module.html#ignore_invalid_hea… https://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_hea… Changing the underscore to an hyphen would allow to keep the default nginx configuration -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 24895] New: CCL searching with phr modifier doesn't work
by bugzilla-daemon＠bugs.koha-community.org 03 May '24

03 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24895 Bug ID: 24895 Summary: CCL searching with phr modifier doesn't work Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To test: - enable DumpSearchQueryTemplate so you can easily check the contents of your query - enter a CCL search of ti,phr:batman - confirm the query gets processed as just ti:batman -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 36764] New: Koha::Plugins::Base->store_data should return something more useful
by bugzilla-daemon＠bugs.koha-community.org 02 May '24

02 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36764 Bug ID: 36764 Summary: Koha::Plugins::Base->store_data should return something more useful 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently, it returns undef which is not that useful for checking if everything went well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 36763] New: Changing a patron category doesn't update form accordingly
by bugzilla-daemon＠bugs.koha-community.org 02 May '24

02 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36763 Bug ID: 36763 Summary: Changing a patron category doesn't update form accordingly Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Patron editor needs to re-evaluate form when the patron category is changed. For example, let's say you have an adult category that requires both a surname and a first name, and an institution category that requires only the surname. You edit an existing adult category and change it into an institution. Realistically, it should clear the first name field, remove the field, and not require it to save. However, as is, none of this happens, and it is impossible to save without putting some value in the first name field. Changing the patron category should clear fields that hidden for the chosen category, and hide those hidden fields, removing the required class. And if the category is changed to something that has more fields, those fields should be shown, and if they are required, the required class added. I know, in typical workflows, this is not necessarily an issue. You generally create a new patron with the category first. But on occasion, as we clean up accounts, sometimes an account changes categories, and this should be a common check. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0