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

[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

[Bug 24623] New: Phase out jquery.cookie.js: Advanced MARC editor
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '21

08 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24623 Bug ID: 24623 Summary: Phase out jquery.cookie.js: Advanced MARC editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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: 23944 The advanced cataloging editor uses a cookie to set the user's preference for whether to use the advanced cataloging editor by default. This process should use the newer cookie library, js-cookie. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23944 [Bug 23944] Phase out use of jquery.cookie.js in favor of js.cookie.js -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 24624] New: Phase out jquery.cookie.js: Receipt summary
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '21

08 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24624 Bug ID: 24624 Summary: Phase out jquery.cookie.js: Receipt summary Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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: 23944 In acquisitions, the receipt summary page uses cookies to remember the settings in the sidebar filter. This process should use the newer cookie library, js-cookie. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23944 [Bug 23944] Phase out use of jquery.cookie.js in favor of js.cookie.js -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 26960] New: Move batch item modification template JavaScript to the footer
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '21

08 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26960 Bug ID: 26960 Summary: Move batch item modification template JavaScript to the footer Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement 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: 26959 In order to conform to best practices for performance, staff client template JavaScript should be in the footer instead of the header. This patch will do so for the batch item modification template. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26959 [Bug 26959] Reindent batch item modification template -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 26959] New: Reindent batch item modification template
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '21

08 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26959 Bug ID: 26959 Summary: Reindent batch item modification template Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org I would like to update the batch item modification template so that it has consistent indentation. -- You are receiving this mail because: You are watching all bug changes.

1 22