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

[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

[Bug 26165] New: Duplicating large saved report leads to error due to length of URI
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26165 Bug ID: 26165 Summary: Duplicating large saved report leads to error due to length of URI Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: bolshawh(a)parliament.uk QA Contact: testopia(a)bugs.koha-community.org If the combined character length of a saved report's title, notes and SQL is too long then pressing the 'duplicate' button will lead to an error: "Request-URI Too Long The requested URL's length exceeds the capacity limit for this server." This seems to be happening after the URL reaches 8226 characters. I originally encountered this error when duplicating a long SQL report but I think the easiest way to replicate it is to add a lot of text to the notes field: 1. Create a simple SQL report and add a lot of text into the notes field (the combined URL lenth must be >8225 characters) 2. Save the report 3. Press the duplicate the report from the saved reports page (guided_reports.pl?phase=Use%20save) As a workaround for this bug, users can copy and paste the SQL into a new report and save it that way or write shorter reports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 23542] New: SRU import ending issue
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23542 Bug ID: 23542 Summary: SRU import ending issue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When importing records from a SRU server, the diacritics have bad encoding. I reproduce with BNF server so it may be a UNIMARC issue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44