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

[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 12 Jun '20

12 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 25473] New: Can't add order from MARC file, save button does nothing
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '20

12 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25473 Bug ID: 25473 Summary: Can't add order from MARC file, save button does nothing 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: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org tl;dr it seems form error handling can break it. (when not ticking a record to import) == Test plan == 1. stage a marc record 2. acquisitions: have a basket 3. click on "Add to basket" 4. "From a staged file" 5. "Add orders" button 6. Optional open JavaScript console - You see twice the error "$ is not defined" - not sure if related though 7. Don't tick the record 8. Save (at least try) 9. You should see an expected error message 10. Tick the record 11. Choose a fund 12. Save (at least try) 13. Nothing happens :< -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 25567] New: borrower_attribute_types.category_code must be set to undef if not set
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '20

12 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25567 Bug ID: 25567 Summary: borrower_attribute_types.category_code must be set to undef if not set Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing 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: 20443 Certainly caused by bug 20443. The method Koha::Patron::Attribute::Type->categorycode is not covered by tests! To recreate: Create a new patron attribute type, don't select a patron's category (and not repeatable or unique) Go to the batch patron modification tool, enter a cardnumber, next. => boom! Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20443 [Bug 20443] Move C4::Members::Attributes to Koha namespace -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 24413] New: MarkLostItemsAsReturned functionality does not lift restrictions caused by long overdues
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '20

12 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24413 Bug ID: 24413 Summary: MarkLostItemsAsReturned functionality does not lift restrictions caused by long overdues Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If an account has been restricted by the long overdue process, and the item causing the restriction is returned by marking it lost (via MarkLostItemsAsReturned), the restriction is not lifted despite 'AutoRemoveOverduesRestriction' being marked to 'Do'. To replicate: 1. Set MarkLostItemsAsReturned to 'from items tab of the catalog module' 2. Set AutoRemoveOverduesRestrictions to 'Do' 3. Set up an overdues restriction in the notice triggers 4. Check out an item and let the overdues process restrict the account 5. Navigate to the moredetail.pl page (items tab) for the overdue item 6. Mark the item lost 7. Return to the account in question - notice the item has been returned, but the restriction remains -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 25608] New: Regression: Bug 23463 broke inventory
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '20

12 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25608 Bug ID: 25608 Summary: Regression: Bug 23463 broke inventory Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: didier.gautheron(a)biblibre.com Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 23463 need to use unblessed items. Test plan : - Create a biblio with default framework - Create an item with barcode='000AAA1', callnumber='ZZZAAA1' - Create an item with barcode='000AAA2', callnumber='ZZZAAA2' - Create a file 'barecodes.txt' containing 2 lines '000AAA1' and '000AAA2' - Go to inventory tool : /cgi-bin/koha/tools/inventory.pl - Choose file in 'Barcode file' - Enter item callnumber between 'ZZZ' and 'ZZZa' - Check 'Compare barcodes list to results' - Check ' - Submit => without patch, you get an error trace Error trace Can't call method "title" on an undefined value at /kohadevbox/koha/tools/inventory.pl line 347, <$fh> line 2. at /kohadevbox/koha/tools/inventory.pl line 347 in (eval) at /kohadevbox/koha/tools/inventory.pl line 347 344: : $inventorylist // []; 345: for my $item ( @$loop ) { 346: my $biblio = Koha::Biblios->find( $item->{biblionumber} ); 347: $item->{title} = $biblio->title; 348: $item->{author} = $biblio->author; 349: } 350: Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23463 [Bug 23463] Move C4::Items CRUD subroutines to Koha::Item -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 25556] New: Holds blocked when empty holdallowed value present in circulation_rules
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '20

12 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25556 Bug ID: 25556 Summary: Holds blocked when empty holdallowed value present in circulation_rules Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: stalkernoid(a)gmail.com Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, slavashishkin(a)gmail.com Holds blocked ("Cannot place hold" yellow notification window) for default rule after onboarding.pl (web installation process). That happens because /cgi-bin/koha/installer/onboarding.pl script creates the empty (holdallowed="") key/value pair in the circulation_rules table. Probably empty ("") holdallowed key assumed to have the same behavior as undef/NULL, because: - in the interface (/cgi-bin/koha/admin/smart-rules.pl) both are interpreted as "Not set" (undef or ""), - if to remove this empty value for holdallowed from circulation_rules table at all (so have it undef) holds allowed and not blocked. - in other cases if "holdallowed" has correct values from the dropdown list (0, 1, 2, 3) - all works as expected. I.e.: 1. ="" has behavior as ="0", 2. value absence (NULL/undef) has behavior as ="2" ("from any library"). 3. but for both values site interface shows "not set". This makes confusion: in 1. it blocks holds, and in 2. it allows. I propose we make both "" and undef work similarly as "not set" in "check if holds allowed" code, and both to allow holds like undef now does. And at the same time remove "" creation but use undef instead in the onboarding process when done first rule creation. -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 25428] New: Escaped HTML shows in authority detail view when subfield is a link
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '20

12 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25428 Bug ID: 25428 Summary: Escaped HTML shows in authority detail view when subfield is a link Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 104604 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104604&action=e… Screenshot showing the problem In authority records there is the option to designate a subfield as a URL (like we do for 856$u in the default MARC framework). When you view the details of such a record the URL is output to the screen as HTML markup. This is because the script is sending hard-coded HTML to the template and the template outputs is as escaped. Rather than use the $raw filter to make the link work, we should remove the script-generated HTML and do it in the template. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 25452] New: Alternate email contact not displayed
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '20

12 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25452 Bug ID: 25452 Summary: Alternate email contact not displayed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Patrons Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The B_email field of a patron is not display on the moremember page (patron view) -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 25563] New: Cannot sub "add order from MARC file" form after alert
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '20

11 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25563 Bug ID: 25563 Summary: Cannot sub "add order from MARC file" form after alert Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 24386 If you get an alert about "no fund selected" you won't be able to submit the form. To recreate (test plan from bug 25473) - stage a marc record - acquisitions: have a basket - click on "Add to basket" - "From a staged file" - Don't tick the record - Save - You should see an expected error message - Tick the record - Choose a fund - Save (at least try) - Nothing happens :< Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24386 [Bug 24386] Double submit should be prevented when adding to a basket -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18