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

[Bug 29152] New: Change to default search behavior when limiting by branch
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '21

11 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29152 Bug ID: 29152 Summary: Change to default search behavior when limiting by branch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major 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 Depends on: 21249 Prior to bug 21249, branch limits in searching were enforced based on the item homebranch. Bug 21249 introduces a syspref to control how those limits are enforced. That's good. But on update the syspref is set to limit based on BOTH homebranch and holdingbranch. That's bad. >From 21249: $dbh->do(q{INSERT IGNORE INTO systempreferences (variable, value, options, explanation, type) VALUES ('SearchLimitLibrary', 'both', 'homebranch|holdingbranch|both', "When limiting search results with a library or library group, use the item's home library, or holding library, or both.", 'Choice')}); Should we not make that default to homebranch in order to not silently change how searches work? This makes a *huge* difference in search results. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21249 [Bug 21249] Syspref to choose whether to search homebranch, holding branch or both for library groups in advanced search -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 14999] Adding to basket orders from staged files mixes up the prices between different orders
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '21

11 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14999 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Pushed to oldstable Version(s)|21.11.00,21.05.05 |21.11.00,21.05.05,20.11.12 released in| | CC| |fridolin.somers(a)biblibre.co | |m --- Comment #17 from Fridolin Somers <fridolin.somers(a)biblibre.com> --- Pushed to 20.11.x for 20.11.12 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28573] New: Replace authority record with Z39.50/SRU creates new authority record
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '21

11 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28573 Bug ID: 28573 Summary: Replace authority record with Z39.50/SRU creates new authority record Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: sebastian.krieg(a)tuz-eisenach.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When replacing an authority record with Z39.50/SRU you get a new record and no update of the upgrading record. Test instance: Catalyst IT Ltd. (New Zealand) (https://koha-community.org/demo/) example record: #13 (name: Plato) Steps to reproduce: 1. Menu "Home > Authorities > Details for authority #13 (Personal Name)" 2. Form: https://demo-intra.mykoha.co.nz/cgi-bin/koha/authorities/detail.pl?authid=13 3. Menu "Edit > Replace record via Z39.50/SRU" 4. Field "Name(any)": Homer >> Click "search" 5. choose the second entry "Aschmann, Homer, 1920-" >> click "import" Expected solution: - replace the record #13 with the search data "Aschmann, Homer, 1920-" - Form: https://demo-intra.mykoha.co.nz/cgi-bin/koha/authorities/detail.pl?authid=13 Error: - Menu "Home > Authorities > Adding authority Personal Name" - form: https://demo-intra.mykoha.co.nz/cgi-bin/koha/authorities/authorities.pl?bre… - Save the record as Record #14 - Menu "Home > Authorities > Details for authority #14 (Personal Name)" Note: I found this error in release 21.05., I use a instance 20.11. to reproduce the error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 11350] Holds offered to patrons who are not allowed to put the item on hold
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '21

11 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11350 Sara Brown <sbrown(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbrown(a)bywatersolutions.com Version|unspecified |21.05 --- Comment #4 from Sara Brown <sbrown(a)bywatersolutions.com> --- I'm seeing this on 21.05.04. Settings: -ReservesControlBranch set to 'item's home library' -Patron X created in category LIMITED with home library EAST -Circ rules at library EAST allow category LIMITED patrons to place holds on item type ADULTBOOK -Circ rules at library WEST prevent category LIMITED patrons from placing holds on item type BOOK -Bib 999 has items with itype ADULTBOOK (all home library EAST) and BOOK (all home library WEST) Steps: -Make ADULTBOOK copy of bib 999 unavailable via checkout to unrelated patron (etc.) -Place bib-level hold on bib 999 for patron X - WEST-owned BOOK copy shows correctly as unavailable for item-level hold in 'Place a hold on a specific item' section Then both: -The WEST-owned BOOK copy of bib 999 appears on WEST's next holds queue run for patron X, and also -Checking in the BOOK copy of bib 999 triggers the hold for patron X -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 28189] New: Move the base swagger file to YAML
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '21

11 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28189 Bug ID: 28189 Summary: Move the base swagger file to YAML Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com In order to be able to add better documentation on the API, we should move the base file to YAML, so we can add multi-line Markdown in it. It renders correctly with tools like Redoc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 28613] New: Several objects.search-based routes missing parameters
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '21

11 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28613 Bug ID: 28613 Summary: Several objects.search-based routes missing parameters Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com The objects.search helper provides convenient ways to paginate and a 'q' filter parameter to build complex queries on this Koha::Objects-based routes. Some routes were created prior to this feature getting introduced. We need to adjust the parameters for all existing objects.search-based routes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 29272] New: API not respecting $category->effective_change_password
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '21

10 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29272 Bug ID: 29272 Summary: API not respecting $category->effective_change_password Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com The API public routes for changing passwords were developed before bug 10796, and when it was pushed (before this routes), we forgot to adapt things in the API. It only checks OpacPasswordChange, but doesn't consider $category->effective_change_password -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 29309] New: 'Pay all fines' should be 'Pay all'
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '21

10 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29309 Bug ID: 29309 Summary: 'Pay all fines' should be 'Pay all' Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It is inconsistent right now. They are not all fines, and that's why we should rename it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 28585] New: Bug in GET /patrons by date_of_birth
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '21

10 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28585 Bug ID: 28585 Summary: Bug in GET /patrons by date_of_birth Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: hannamari.h.heiniluoma(a)jyu.fi Querying patrons by their date_of_birth returns an empty response, even though there are patrons with that date of birth in the database. Might be a bug? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56

[Bug 11873] Upgrade jstree jQuery plugin to the latest version
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '21

10 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11873 --- Comment #2 from Owen Leonard <oleonard(a)myacpl.org> --- This patch is too large to attach, so I've pushed it to a GitLab branch: https://gitlab.com/koha-dev/koha-dev/-/tree/bug-11783-upgrade-jstree Bug 11873: Upgrade jstree jQuery plugin to the latest version This patch upgrades the jstree plugin in the OPAC and the staff interface. The old version had compatibility issues with the latest jQuery. Also changed: When viewing an authority record in the OPAC's MARC view, clicking one of the hierarchy links should now open the MARC view again rather than reverting to the normal view. To test, apply the patch and rebuild the staff interface and OPAC CSS (https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staf…) To test you must have the AuthDisplayHierarchy system preference enabled, and you must have some authorities data which can be displayed as a hierarchy. From the test plan for Bug 8523: "Create authority records with a hierarchy of see also fields (in MARC21/NORMARC, you'll be using 5xx fields for this, with a subfield $w = 'g' for broader terms and subfield $w = 'h' for narrower terms)" - Perform an authority search in the OPAC which will return one of your modified authority records. - View the record. - There should be an expanded tree menu at the top of the authority information. - Clicking the arrows in the tree should correctly expand and collapse the nodes. - Clicking the authority record link in the node should load that record. - Test also from the OPAC's MARC view of the authority record. - Confirm that clicking an authority record link in the MARC view opens the corresponding record in MARC view again. - Perform the same tests in the staff interface. -- You are receiving this mail because: You are watching all bug changes.

1 0