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

[Bug 25751] New: When an ORDERED suggestion is edited, the status resets to "No status"
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25751 Bug ID: 25751 Summary: When an ORDERED suggestion is edited, the status resets to "No status" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 The status "ORDERED" is missing from the pull down list of status values when editing a suggestion, so the first option is selected "No status". This leads to data loss when editing a suggestion in the status "ORDERED". Worse: the status can't be reset to "ORDERED" and so no AVAILABLE notice can be sent to the patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 25750] New: Fallback to ecost_tax_included, ecost_tax_excluded not happening when no 'Actual cost' entered
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25750 Bug ID: 25750 Summary: Fallback to ecost_tax_included, ecost_tax_excluded not happening when no 'Actual cost' entered Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org The patchsets on bugs 23523 and 23522 set and display respectively the unitprice_tax_included/unitprice_tax_excluded if 'Actual cost' has been entered. If 'Actual cost' is not entered entered then Koha should fallback to ecost_tax_included/ecost_tax_excluded. However the fallback is not working correctly. When 'Actual cost' is not set it has a value of 0.00 and Koha evaluates 0.00 to true so ecost_tax_included/ecost_tax_excluded is never used. e.g. In this fallback: my $cost_tax_included = $line{unitprice_tax_included} || $line{ecost_tax_included}; my $cost_tax_included = 0.00 || 7.23 $cost_tax_included is set to 0.00 as Perl treats 0.00 as true. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 26090] New: Catalog by itemtype report fails if SQL strict mode is on
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26090 Bug ID: 26090 Summary: Catalog by itemtype report fails if SQL strict mode is on Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org The catalog by itemtype report (reports/manager.pl?report_name=itemtypes) returns no results if SQL strict mode is on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 25786] New: Holds Queue building may target the wrong item for item level requests that match holds queue priority
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25786 Bug ID: 25786 Summary: Holds Queue building may target the wrong item for item level requests that match holds queue priority Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 23934 removed the limitation that prevented item level holds from getting local holds priority. The problem is the code has never checked if the item level hold matches the given item! This means the wrong item may be requested to fill an item level hold. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 25783] New: Holds Queue treating item-level holds as bib-level
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25783 Bug ID: 25783 Summary: Holds Queue treating item-level holds as bib-level 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We've only seen this on 19.11 and have not been able to recreate it on a test system, but we're seeing instances where a patron has an item-level hold but the holds queue treats it as a bib-level hold. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 25005] New: Admin Rights issue for Suggestion to Purchase
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25005 Bug ID: 25005 Summary: Admin Rights issue for Suggestion to Purchase Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: christofer.zorn(a)ajaxlibrary.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Hello All! I hope everyone staying safe during this time! Yesterday I was trying to give a staff member permission to view and approve the "Suggestions Pending Approval". I had given that user full rights to the 'Suggestion Management' permission, however the option did not appear until I also provided the user with 'Moderate patron comments' under tools. However, to continue testing this I removed the 'Suggestion Management' option and it did remove it. I think there is something wrong with the check of the suggestion management piece that is preventing it from showing unless moderate comments option is also selected. Thanks for looking into this. Christofer -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 26136] New: Prevent double submit of checkin form
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26136 Bug ID: 26136 Summary: Prevent double submit of checkin form 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We have seen reports of sites where checkins appear to be failing due to corrupt data with the error: The checkin for the following issue failed, Please go to the about page, section 'data corrupted' to know how to fix this problem (DBIx::Class::Row::update(): Can't update Koha::Schema::Result::Issue=HASH(0x55c471ef6c28): row not found at /usr/share/koha/lib/Koha/Object.pm line 158 This seems to be caused by a double submission / race condition - the checkout is returned twice - the first succeeeds, the second fails because the row is moved to old_issues Sometimes it succeeds an is logged as a return + localuse We should prevent this from happening -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 25641] New: Koha/XSLT/Base.t is failing on U20
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25641 Bug ID: 25641 Summary: Koha/XSLT/Base.t is failing on U20 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org kohadev-koha@a72d3d9a1f4d:/kohadevbox/koha$ prove t/db_dependent/Koha/XSLT/Base.t t/db_dependent/Koha/XSLT/Base.t .. 1/33 # Failed test 'Malformed XML warning correctly displayed' # at t/db_dependent/Koha/XSLT/Base.t line 87. # found warning: XSLT::Base: :1: parser error : Opening and ending tag mismatch: a line 0 and b # expected to find warning: (?^u:parser error : Opening and ending tag mismatch: a line 1 and b) # Failed test 'Malformed XML warning correctly displayed' # at t/db_dependent/Koha/XSLT/Base.t line 99. # found warning: XSLT::Base: :1: parser error : Opening and ending tag mismatch: a line 0 and b # expected to find warning: (?^u:parser error : Opening and ending tag mismatch: a line 1 and b) # Failed test 'Malformed XML warning correctly displayed' # at t/db_dependent/Koha/XSLT/Base.t line 104. # found warning: XSLT::Base: :1: parser error : Opening and ending tag mismatch: a line 0 and b # expected to find warning: (?^u:parser error : Opening and ending tag mismatch: a line 1 and b) # Failed test 'Malformed XML warning correctly displayed' # at t/db_dependent/Koha/XSLT/Base.t line 110. # found warning: XSLT::Base: :1: parser error : Opening and ending tag mismatch: a line 0 and b # expected to find warning: (?^u:parser error : Opening and ending tag mismatch: a line 1 and b) # Looks like you failed 4 tests of 33. t/db_dependent/Koha/XSLT/Base.t .. Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/33 subtests Test Summary Report ------------------- t/db_dependent/Koha/XSLT/Base.t (Wstat: 1024 Tests: 33 Failed: 4) Failed tests: 10, 12, 14, 16 Non-zero exit status: 4 Files=1, Tests=33, 1 wallclock secs ( 0.03 usr 0.01 sys + 0.44 cusr 0.04 csys = 0.52 CPU) Result: FAIL -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 26000] New: Holiday exceptions are incorrectly cached for an individual branch
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26000 Bug ID: 26000 Summary: Holiday exceptions are incorrectly cached for an individual branch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When updating exception holidays they are cleared from the cache until Koha::Calendar->exception_holidays is called That routine checks the cache, and then generates the holidays for a single branch and sets them in the cache. This is incorrect. single_holidays handles the situation correctly and exception_holidays should do the same. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 26012] New: Date in 'Paid for' information not formatted to Time/DateFormat system preferences
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26012 Bug ID: 26012 Summary: Date in 'Paid for' information not formatted to Time/DateFormat system preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial 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 The information shown in Paid for? on the items tab on detail view shows a date in database format. To test: - Make sure there is a replacement cost in the item - check it out - Mark it lost - Pay the lost item fee - Go to the detail page and look on the items tab for the item - It will show an entry with "Paid for?" label -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14