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

[Bug 25903] New: Sending a SIP patron information request with a summary field flag in indexes 6-9 will crash server
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25903 Bug ID: 25903 Summary: Sending a SIP patron information request with a summary field flag in indexes 6-9 will crash server 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 The 'summary' field in the patron information request specifies if detail information should be send for holds, overdues, fines, etc. The field is 10 characters in length (0-9). However, the SIP2 spec only defines indexes 0 though 5, leave 6 though 9 undefined. Some ILSs specify behavior for these undefined indexes. Apparently the 7th field is often used to request 'Fees', as opposed to 'Fines' in some ILS. Some software that integrate via SIP try both the 5th and 7th indexes to ensure they get all fines and fees. The problem is that Koha's SIP server crashes if any 'summary' index beyond 5 is flagged. We should simply ignore flags beyond 5 and act as if no flags were sent. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 25553] New: edit item date sort does not sort correctly
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25553 Bug ID: 25553 Summary: edit item date sort does not sort correctly Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When in the edit items table for a bib record, the date last seen and date accessioned do not sort correctly. To test, find a bib record with multiple items attached that have different dates for either accessioned and/or last seen. Select Edit - items. On the edit items screen, click on the column header for one of the dates and note that they do not sort in date order. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 25778] New: koha-plack --restart causes PERL5LIB to grow with duplicate entries
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '20

20 Sep '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25778 Bug ID: 25778 Summary: koha-plack --restart causes PERL5LIB to grow with duplicate entries Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Line 395 in koha-lack "PERL5LIB=$PERL5LIB:$KOHA_HOME/installer:$KOHA_HOME/lib/installer" causes PERL5LIB to grow with duplicate entries for /usr/share/koha/installer and /usr/share/koha/lib/installer when running in production. Note that this does *not* happen when running in dev, when using koha-testing-docker for instance. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[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 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 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 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