December 2020 - Koha-bugs - lists.koha-community.org

[Bug 21959] New: Batch item modification - ability to apply regular expression on text fields
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '21

11 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21959 Bug ID: 21959 Summary: Batch item modification - ability to apply regular expression on text fields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Here we want the possibility to make regex on text (type text or textarea) fields in the batch item modification form. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 56

[Bug 24347] New: Add a 'search to order' option similar to 'search to hold'
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '21

11 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24347 Bug ID: 24347 Summary: Add a 'search to order' option similar to 'search to hold' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org On bug 11149 it was noted that the search options when reordering an existing record are limited. Instead of relying on ccl queries or rebuilding search features in the acq module, it could be nice to have a "search to order" feature. This could work similar to the "search to hold" functionality. Only you would not start from a patron record, but from your basket. Searching in the catalog you would see an "Add to order" link that would redirect you to the order page of your basket with the record already linked to the order. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 18806] New: Cannot revert a batch
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '21

11 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18806 Bug ID: 18806 Summary: Cannot revert a batch Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Tools Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 18242 Since bug 18242: When a biblio is deleted, a new transaction is created. tools/manage-marc-import.pl use the AutoCommit flag, which does not allow nested transaction. AutoCommit must not be used. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18242 [Bug 18242] Move of checkouts to old_issues is not handled correctly -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 27180] New: Fines cronjob does not update fines on holidays when finesCalendar is set to ignore
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '21

10 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27180 Bug ID: 27180 Summary: Fines cronjob does not update fines on holidays when finesCalendar is set to ignore Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The fines cronjob currently skips updating fines if the date it is run is a holiday for the applicable library. This is problematic when an item is marked lost the day following a holiday as we can end up missing a day of fines. Additionally it confuses things for libraries who do not expect the calendar to affect fines. This seems to have been done when dropbox mode used calculations on the 'last update' of a fine to determine how much to refund. Now that dropbox mode simply calculates the fine with a different return date this code is no longer needed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 25850] New: CalcDateDue freezes with 'useDaysMode' set to 'Daysweek' and the due date lands on a sunday.
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '21

10 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25850 Bug ID: 25850 Summary: CalcDateDue freezes with 'useDaysMode' set to 'Daysweek' and the due date lands on a sunday. Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com >From the DateTime manual page: $dt->day_of_week() Returns the day of the week as a number, from 1..7, with 1 being Monday and 7 being Sunday. Also available as "$dt->wday()" and "$dt->dow()". But the method "get_push_amt" assumes that day_of_week is numbered 0..6 with 0 being Sunday. (Also, there is a funny equality test of a boolean value and the number 1.) The result is that for Sundays, $self->{weekly_closed_days}->[$dow] is undefined and its negation is thus true, which results in a push_amt of seven days, which lands on the next Sunday and the process repeats. sub get_push_amt { my ( $self, $base_date) = @_; my $dow = $base_date->day_of_week; return ( # We're using Dayweek useDaysMode option $self->{days_mode} eq 'Dayweek' && # It's not a permanently closed day !$self->{weekly_closed_days}->[$dow] == 1 ) ? 7 : 1; } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 25348] New: Add support for circulation status 12 ( lost )
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '21

09 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25348 Bug ID: 25348 Summary: Add support for circulation status 12 ( lost ) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com We should support the SIP2 "circulation status" value 12, "lost". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 21658] New: Renew requests fail if a fee attached
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '21

09 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21658 Bug ID: 21658 Summary: Renew requests fail if a fee attached Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com A Sip Renew request (29) for an item with an associated fee should behave similarly to a checkout request i.e. the initial request has fee acknowledged set to N - server rejects the transaction an responds indicating the fee amount. Self check unit has the responsibility of collecting that fee and can then proceed repeating the request but with fee acknowledged set to Y, this request should then succeed. Currently this is not happening on older versions renew requests are always rejected if there is a fee irrespective of the value of the fee acknowledged field. On master there is an additional problem that the server is crashing due to a runtime error when processing the fee. This bug has not manifested for many users as 3m and most other self-check units actually send a checkout request not a renewal request when renewing items. Newer biblioteca units do send a renew request and expect this functionality -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 23434] New: Hold confirmation dialog problem if HoldsAutoFill is enabled
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '21

09 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23434 Bug ID: 23434 Summary: Hold confirmation dialog problem if HoldsAutoFill is enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 23399 Created attachment 92025 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=92025&action=ed… Checking a hold for another library with HoldsAutoFill enabled If the HoldsAutoFill system preference is enabled, the hold confirmation dialogs on the check-in page are badly constructed, resulting in duplicate information and inconsistent displays. See attached screenshot Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23399 [Bug 23399] Reindent returns.tt -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 24957] New: OpenLibrarySearch doesnt return result correctly on OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '21

09 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24957 Bug ID: 24957 Summary: OpenLibrarySearch doesnt return result correctly on OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If you turn on OpenLibrarySearch results are often not returned and only the text "Open Library:" displays. Firstly, if there is nothing to return we should display nothing. Secondly, it does look like any of these records do return data but the API has changed, I think. Koha checks to see if "items: []" has length and returns false if this is true. But I am finding many records where the data seems to be present: (https://openlibrary.org/api/volumes/brief/json/id:0;isbn:067002662X;lccn:__…) but items contains nothing. I don't know anything about the OpenLibrary API, but perhaps it has changed. TO RECREATE: 1. turn on OpenLibrarySearch 2. go to the opac results page and opac details page and see many records that just display "Open Library: " and nothing else. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 27205] New: Hold routes are not dealing with invalid pickup locations
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '21

08 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27205 Bug ID: 27205 Summary: Hold routes are not dealing with invalid pickup locations Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It's possible to PUT or POST /holds with invalid pickup locations. As the staff cannot overwrite invalid pickup locations (to confirmed), we should raise an exception from AddReserve and ModReserve if called with invalid pickup locations. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32