July 2022 - Koha-bugs - lists.koha-community.org

[Bug 28550] New: Text on overduerules.pl should explain how triggers are selected
by bugzilla-daemon＠bugs.koha-community.org 22 Dec '22

22 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28550 Bug ID: 28550 Summary: Text on overduerules.pl should explain how triggers are selected 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 28549 The onscreen text on the overdue notice and status triggers page should explain which branch will get used. Right now, that defaults to issuing branch, but a flag in the cron can be set to make it use item homebranch instead. I've made this bug depend on 28549, which proposes moving that control into a syspref. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28549 [Bug 28549] Add a system preference to duplicate --frombranch flag in overdue_notices.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 31157] New: overdue_notices.pl --frombranch option should be available as a system preference
by bugzilla-daemon＠bugs.koha-community.org 22 Dec '22

22 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31157 Bug ID: 31157 Summary: overdue_notices.pl --frombranch option should be available as a system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz On a multi-tenant system it is understandable for one client to want one options for the --frombranch and another to want another. However, as the overdue job is run under cron.daily it's not trivial to change it on a per instance basis.. We should expose this option at the UI level. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 28549] New: Add a system preference to duplicate --frombranch flag in overdue_notices.pl
by bugzilla-daemon＠bugs.koha-community.org 22 Dec '22

22 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28549 Bug ID: 28549 Summary: Add a system preference to duplicate --frombranch flag in overdue_notices.pl 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The overdue_notices cron allows one to specify whether the issuing branch or item homebranch should be used to select the triggers to follow. We should allow this choice in a system preference so one can change it without commandline access. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 31061] New: OPACSuppress does not work properly with Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 22 Dec '22

22 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31061 Bug ID: 31061 Summary: OPACSuppress does not work properly with Elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com OPACSuppress is system preference to hide records in OPAC search by adding a limit in search query. With Zebra, this limit is : not Suppress=1 https://git.koha-community.org/Koha-community/Koha/src/commit/244b847a08bf6… With Elasticsearch this limit is currently quite different : suppress:false https://git.koha-community.org/Koha-community/Koha/src/commit/244b847a08bf6… Main problem is that in default framework we define Suppress search field on 942$n with authorized values YES_NO. This generates records with 1 for YES and 0 for NO. But a boolean for Elasticsearch is not a perl boolean. So only missing subfield means false : https://www.elastic.co/guide/en/elasticsearch/reference/6.8/boolean.html Records with 0 are hidden ! Another side-effect : We whould like to have several MARC fields with 'suppress' search field. To distinguish several causes of hidden at OPAC. Any of those fields having 1 must hide at OPAC. So syntax 'NOT(suppress:1)' is more correct. I propose we change to have the same behavior as Zebra. Change 'suppress' search field to not remove boolean type. Change QueryBuilder to use 'NOT(suppress:1)'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 28583] New: Temporarily disable CSS and Javascript for pages with variable
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '22

16 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28583 Bug ID: 28583 Summary: Temporarily disable CSS and Javascript for pages with variable 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: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 14004 introduced the ability to temporarily disable added CSS and Javascript in OPAC and interface by adding ?DISABLE_SYSPREF_IntranetUserCSS=1 for example to the url, but it doesn't work for pages referring to specific ids, for example : -https://kohapro.bulac.fr/cgi-bin/koha/circ/circulation.pl?borrowernumber=xxx -https://kohapro.bulac.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=xxx I thought I was because two '?' in the same url can't be used and try to replace it by '&' but it still doesn't work. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 23585] New: Hide Item Information tab when adding to basket from file without creating items
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '22

16 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23585 Bug ID: 23585 Summary: Hide Item Information tab when adding to basket from file without creating items Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To Test: - Create a basket set to create items either at receiving or at cataloging - Add to basket from a MARC file - On addorderiso2709.pl, observe that the Item Information tab is present but only contains the words "Import all the checked items in the basket with the following parameters:" with no additional content It makes sense that we can't enter anything else here -- we're not creating items and therefore don't have anything to enter. But it would be less confusing to just hide this tab entirely. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31160] New: Required fields in the Patrons API are a bit random
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '22

15 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31160 Bug ID: 31160 Summary: Required fields in the Patrons API are a bit random 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: martin.renvoize(a)ptfs-europe.com CC: tomascohen(a)gmail.com Currently, the required fields in the patron API do not match the required fields in the CSV imports.. and they don't entirely make sense.. city and address are required for example.. is there some reasoning behind those choices? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 26648] New: Prevent internal server error if item attached to old checkout has been removed
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '22

14 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26648 Bug ID: 26648 Summary: Prevent internal server error if item attached to old checkout has been removed 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Whilst playing with notices to see if we could calculate a running total of savings for a library user to add to their issueslip notice I found that if an item relating to an old checkout has been deleted, then the relation accessor can explode -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 29048] New: Authorities search results - related records link
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '22

14 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29048 Bug ID: 29048 Summary: Authorities search results - related records link Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: vitorfernandes87(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The related records link in the authorities search results searches for "an=authid", which returns all records with an started with authid (after clicking the link). This causes a difference between the number of related records and the number of records retrieved in the search (using Elasticsearch). The link should change from: q=an=[% resul.authid | uri %] To: q=[% resul.authid | uri %]&idx=an,phr in the following line: https://github.com/Koha-Community/Koha/blob/master/koha-tmpl/opac-tmpl/boot… Test plan: - Create 10 authority with similar values - Relate some record with authority 1 - Relate some record with authority 10 - Search authorities (authority 1 should have 1 related record) - Click the related records link - You should get 2 related records -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 30944] New: Recalls - action buttons to cancel recall on various pages do not work
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '22

14 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30944 Bug ID: 30944 Summary: Recalls - action buttons to cancel recall on various pages do not work 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: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Separated out from bug 30924 - cancel recalls action buttons don't seem to work: 1. Once a recall is made, and checked in: a. On the staff interface item details page > recalls section - selecting from the Actions drop down list/button "Cancel recall and return to Centerville" does nothing. b. However, selecting the tick box and selecting "Cancel selected recalls" works. c. In addition, after you press "Cancel...": - the URL changes to http://127.0.0.1:8081/cgi-bin/koha/recalls/request.pl - clicking on normal (or any other tab gives you the message "The record you requested does not exist ()." - URL is http://127.0.0.1:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber= 2. Once a recall is made, and checked in: . From Circulation > Recalls > Recalls queue: same as 1a and 1b. 3. Once a recall is made, and checked in: . From Circulation > Recalls > Recalls to pull: select "Cancel recall and return to: Centerville: generates this error: DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Data truncated for column 'reason' at row 1 at /kohadevbox/koha/Koha/Object.pm line 170 at /usr/share/perl5/DBIx/Class/Exception.pm line 77 ..... 4. On the patron details > recalls tab page for Henry, selecting Actions > "Cancel recall and return to: Cenetrville" does nothing (same as 1a). Setting up things to test/replicate: 1. Enable recalls: set UseRecalls system preference to 'Use'. 2. Setup rcalls circulation and fines rules: . Recalls allowed (total) = 5 . Recalls per record (count) = 2 . On shelf recalls allowed = 'If any unavailable' . Recall due date interval (day) = 3 . Recall overdue fine amount = 5 . Recall pickup period (day) = 2 3. Checkout an item to a patron: - Patron used: Mary Burton (Midway) - Record used: Programming Perl (biblionumber = 262, one item = 39999000011418, home library = Centerville) 4. Change username/password for a patron, login to the OPAC, and place a recall for the item in step 4. - Patron used: Henry Acevedo (Midway) 5. Check in item for recall with library set to Centerville - confirm recall and transfer. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23