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

[Bug 22408] New: Subscription entry form cleanup
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '20

15 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22408 Bug ID: 22408 Summary: Subscription entry form cleanup Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Serials Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Target Milestone: --- Created attachment 85629 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=85629&action=ed… Screenshot showing the proposed interface I would like to make a number of changes to the subscription entry form - Make the default layout single-column (like patron entry) - Switch the layout to two-column only when testing prediction pattern - Change the style of some buttons and links - Clean up some issues with capitalization and spacing - Make it clearer when form fields are read-only -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 22359] New: Improve usability of 'change calculation' (bug 11373)
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '20

14 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22359 Bug ID: 22359 Summary: Improve usability of 'change calculation' (bug 11373) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 11373 Target Milestone: --- There has been some discussion about the usability of the change calcualation feature from bug 11373. Adding a bug to collect comments and suggestions in a central spot in hope that we will be able to improve things prior to the 19.05 release :) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11373 [Bug 11373] Add "change calculation" feature to the fine payment forms -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 81

[Bug 21086] New: Wrong mock of DateTime->now in tests
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '20

13 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21086 Bug ID: 21086 Summary: Wrong mock of DateTime->now in tests Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal 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 Depends on: 20287, 19705 prove t/db_dependent/DecreaseLoanHighHolds.t t/db_dependent/DecreaseLoanHighHolds.t .. 1/17 Can't locate object method "truncate" via package "80" (perhaps you forgot to load "80"?) at /home/vagrant/kohaclone/C4/Circulation.pm line 3497. What is happening: We mock DateTime->now in the script to avoid the date comparaisons to fail on slow servers (see bug 19705). my $now_value = DateTime->now(); my $mocked_datetime = Test::MockModule->new('DateTime'); $mocked_datetime->mock( 'now', sub { return $now_value; } ); Since bug 20287, we have the following calls: Koha::Patron->store => Koha::Patron::Category->get_expiry_date which does: 221 return $date->add( months => $self->enrolmentperiod, end_of_month => 'limit' ); as enrolmentperiod is generated by t::lib::TestBuilder, it can be quite big, and so the date change from one call to the others. The failure is actually coming from the date becoming > 9999, which is not handled correctly, on purpose, by Koha::DateUtils (infinite) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19705 [Bug 19705] DecreaseLoanHighHolds.t is still failing randomly https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20287 [Bug 20287] Move AddMember and ModMember to Koha::Patron -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 18369] New: Broken title link in UNIMARC catalog search results table
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '20

13 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18369 Bug ID: 18369 Summary: Broken title link in UNIMARC catalog search results table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: synapse.ova(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In staff client, «Search the catalog» returns a table, where biblio title has a broken link (biblionumber is absent), yet other links works good (Holds, Edit Record, Edit items, OPAC view) Steps to Reproduce: In staff client, search the catalog (Cataloging → «Search the catalog» (/cgi-bin/koha/catalogue/search.pl)) Actual Results: Title of the biblio has a link, that doesn't have biblionumber Expected Results: Title of the biblio should have a link with a proper biblionumber at the end Additional Information: Each biblio in the results table is shown by XSL transformation of MARC data. XSL (\intranet-tmpl\prog\en\xslt\UNIMARCslim2intranetResults.xsl) prepares a link, and adds a biblionumber, that it expects to get from controlfield 001. But since this field could be either empty or contain something different than biblionumber (see https://lists.katipo.co.nz/public/koha/2015-September/043652.html) it is better to pass the biblionumber to this script. This script is already receiving sysprefs (that is not according to marcxml standart), so I suggest to pass the biblionumber the same way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 22969] New: fix biblionumber on 001 in UNIMARC XSLT
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '20

13 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22969 Bug ID: 22969 Summary: fix biblionumber on 001 in UNIMARC XSLT Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In UNIMARC default configuration the 001 is linked to biblio.biblionumber. In some XSLT files, 090$a is used. This is by default biblioitems.biblionumber so it usually works but it may not be the same and var biblionumber is used to create hyperlinks to record detail page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 24229] New: /items API tests fail on Ubuntu 18.04
by bugzilla-daemon＠bugs.koha-community.org 13 Jun '20

13 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24229 Bug ID: 24229 Summary: /items API tests fail on Ubuntu 18.04 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Tests fail in a weird way: kohadev-koha@7369d4443675:/kohadevbox/koha$ prove t/db_dependent/api/v1/items.t t/db_dependent/api/v1/items.t .. # Inactivity timeout # Failed test 'GET //RTrSH14TLmPlTAsO1RAR9x8MhJtMO7XJS5IKOwBKfwcFnpzHSGSEPM7k:thePassword123@/api/v1/items' # at t/db_dependent/api/v1/items.t line 75. # Failed test 'SWAGGER3.2.2' # at t/db_dependent/api/v1/items.t line 75. # got: undef # expected: '200' # Looks like you planned 12 tests but ran 5. # Looks like you failed 2 tests of 5 run. t/db_dependent/api/v1/items.t .. 1/2 # Failed test 'list() tests' # at t/db_dependent/api/v1/items.t line 95. Can't use an undefined value as an ARRAY reference at t/db_dependent/api/v1/items.t line 79. # Looks like your test exited with 255 just after 1. t/db_dependent/api/v1/items.t .. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 2/2 subtests It happens almost randomly (I reproduced the first time I started koha-testing-docker with the master-bionic image, but then it wouldn't reproduce). -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 24062] New: Circulation tests fail randomly if patron category type is 'X'
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '20

11 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24062 Bug ID: 24062 Summary: Circulation tests fail randomly if patron category type is 'X' Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal 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 The items are not issued if the patron category's type is 'X', used for statistics. koha_1 | # Failed test 'ISSUED_TO_ANOTHER question flag should be set if AutoReturnCheckedOutItems is disabled and item is checked out to another' koha_1 | # at t/db_dependent/Circulation.t line 1994. koha_1 | # got: undef koha_1 | # expected: '1' koha_1 | # Looks like you planned 2 tests but ran 1. koha_1 | # Looks like you failed 1 test of 1 run. koha_1 | koha_1 | # Failed test 'CanBookBeIssued + AutoReturnCheckedOutItems' koha_1 | # at t/db_dependent/Circulation.t line 2001. koha_1 | Can't call method "borrowernumber" on an undefined value at t/db_dependent/Circulation.t line 1998. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 20391] New: Koha creates new authorities for 100 & 700 tags bringing in the relator term into the new authority
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '20

11 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20391 Bug ID: 20391 Summary: Koha creates new authorities for 100 & 700 tags bringing in the relator term into the new authority Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Current behavior for when you have the system preference for AutoCreateAuthorities set to generate and BiblioAddsAuthorities set to allow, when creating new authority records for 100 & 700 tags, it also creates relator terms. Steps to recreate: When you save a bib record in the basic editor, authorities are connected or created if the system does not have that authority. When Koha creates new authorities for 100 & 700 tags for people it also brings the relator term into the new authority. Most people do not want relator terms in their authority records so they need to inspect their personal authorities and bring in the proper authority from LC (or another source). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 16248] New: ModZebra doesn't update zebraqueue if ES is enabled
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '20

10 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16248 Bug ID: 16248 Summary: ModZebra doesn't update zebraqueue if ES is enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The zebraqueue table should still be populated with updates if ES is enabled, so the Zebra indexer keeps the Z39.50/SRU indexes up to date. To reproduce: - Set SearchEngine = Elasticsearch - Watch for zebraqueue changes $ watch -n 0.5 'echo "SELECT COUNT(*) FROM zebraqueue WHERE done=0" | sudo koha-mysql kohadev' - Call touch_all_biblios.pl to simulate record changes $ sudo koha-shell kohadev ; cd kohaclone $ perl misc/maintenance/touch_all_biblios.pl -v => FAIL: Notice the watch is not changing the number of records to be indexed. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 23039] New: Hold found modal on checkin screen ( circulation.pl ) obscures Check in message info
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '20

10 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23039 Bug ID: 23039 Summary: Hold found modal on checkin screen ( circulation.pl ) obscures Check in message info Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Target Milestone: --- During the checkin process, all the message info is completely obscured by any modal forms that may be triggered by the checkin. In some cases that info could be vital to making an informed decision as to what option to choose in the modal itself. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35