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

[Bug 18183] New: jQuery append error related to script tags in cloneItemBlock
by bugzilla-daemon＠bugs.koha-community.org 22 Jan '18

22 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18183 Bug ID: 18183 Summary: jQuery append error related to script tags in cloneItemBlock 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org This is a strange javascript error that I experienced on a 3.22 system and could not reproduce with the current (modified) framework in master. But since the code is essentially the same, it might still be possible. The js error is: TypeError: document.getElementById(...) is null The line in koha-tmpl/intranet-tmpl/prog/js/additem.js that causes this error is: $(clone).append(data); While running append, jQuery seems to call .domManip and .globalEval internally. The result on the interface is that you do not have an item block when receiving an order (AcqCreateItem=receiving). Note that data comes from services/itemrecorddisplay.pl and is a very long string containing all item fields and even script tags for plugins. Between the ACQ framework in 3.22 and in master (copied from Default), I noticed some smaller changes in the lines for plugins. Since the js variable "clone" contains a jQuery object for an element that is not yet added to the page, I could imagine a getElementById error. But it does not always occur, so some other condition must be triggered too. This condition appears to be connected to the script tags, since removing all plugins from the ACQ framework in 3.22 made the error disappear (no solution however). Some interesting comments on jQuery's handling of appending script tags are found in http://stackoverflow.com/questions/610995/cant-append-script-element Triggered by the getElementById error, I rearranged a few lines in cloneItemBlock so that I appended clone (the 'floating' div field for the new item) first to the outeritemblock div on the page and after that I appended the data string (item fields and script tags) to clone. This resolved the js error on 3.22 and did not affect master. Conclusion: We seem to stumble over a problem with our plugin script tags in jQuery's script evaluation when clone is not bound to the page yet. The proposed patch just adds this workaround touching three lines. If we would like to change (again) the way we handle script tags for plugins, we will need much more effort. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 19798] New: Returns.pl doesn't define itemnumber for transfer-slip.
by bugzilla-daemon＠bugs.koha-community.org 22 Jan '18

22 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19798 Bug ID: 19798 Summary: Returns.pl doesn't define itemnumber for transfer-slip. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: bjorn.nylen(a)ub.lu.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Marking master as version as 17.11 isn't available to select. It seems the itemnumber isn't set in the link/button that prints transfer-slips. To reproduce: 1. Check in available/not on hold item at a non owning library. 2. Press transfer-button. 3. Resulting slips says "Item not found". "Inspect element" in browser for the button indicates that itemnumber is not set: "transfer-slip.pl?transferitem=&branchcode=CPL&op=slip" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 19860] New: Make staff client home page responsive
by bugzilla-daemon＠bugs.koha-community.org 22 Jan '18

22 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19860 Bug ID: 19860 Summary: Make staff client home page responsive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 14546 The YUI grid on the staff client home page should be replaced with use of the Bootstrap grid. This change will not affect the header search area, only the body of the page. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14546 [Bug 14546] Make staff client templates responsive -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 19857] New: Optionally hide SMS provider field in patron modification screen
by bugzilla-daemon＠bugs.koha-community.org 22 Jan '18

22 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19857 Bug ID: 19857 Summary: Optionally hide SMS provider field in patron modification screen Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Optionally hide SMS provider field in patron modification screen with BorrowerUnwantedField system preference. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 19788] New: Local preference with uppercase
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '18

19 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19788 Bug ID: 19788 Summary: Local preference with uppercase Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: frederic(a)tamil.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In Administration > System preferences, when adding a local preference, the 'variable' name is transformed in lowercase. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 19702] New: Basket not displaying correctly on home page
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '18

19 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19702 Bug ID: 19702 Summary: Basket not displaying correctly on home page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: david.bourgault(a)inlibro.com Reporter: david.bourgault(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: philippe.blouin(a)inlibro.com When viewing the "base url" of the OPAC catalog, the basket is not displayed correctly: Say your website is `opac.books.com`, the basket will be displayed correctly for all page under `opac.books.com/cgi-bin/koha/` but not on `opac.books.com/` -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 19840] New: Patron note is not displayed on checkin
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '18

19 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19840 Bug ID: 19840 Summary: Patron note is not displayed on checkin Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Circulation 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 Depends on: 14224 If a patron let a note on the checkout (AllowCheckoutNotes), it is supposed to be displayed when checked in Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14224 [Bug 14224] patron notes about item shown at check in -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 18458] New: Merging authority record incorrectly orders subfields
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '18

19 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18458 Bug ID: 18458 Summary: Merging authority record incorrectly orders subfields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When merging two authorities and updating the linked biblios MARC::Field->new() is called with the tagnumber, indicators, and the new subfield $9 This causes this subfield to be the first in the field as a whole and is inconsistent with usualy ordering -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 19813] New: MarcItemFieldsToOrder cannot handle a tag not existing
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '18

19 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19813 Bug ID: 19813 Summary: MarcItemFieldsToOrder cannot handle a tag not existing 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org MarcItemFieldsToOrder defines how Koha looks at tags in order records to generate item data. Let's look at a simplified case: homebranch: 955$a holdingbranch: 956$a So, here we are looking at 955 for the home branch, and 956 for the holding branch. So, it should make sense that Koha requires that these fields exist in equal number in the record. That is, for each 955, there should be a corresponding 956. Let's look at a different case: homebranch: 946$a|975$a holdingbranch: 946$a|975$a In this case, we are using the fallback behavior. VendorA stores the branch data in 946, and VendorB stores it in 975. This seems like it would work, but it won't! That's because Koha is expecting there to be the same number of 946's as there are 975's! In reality, the VendorA records will have a number of 946's, and *zero* 975's. The inverse will be true for VendorB. Koha should be able to skip those tags that simply don't exist in the record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 19200] New: Warns when exporting a basket
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '18

19 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19200 Bug ID: 19200 Summary: Warns when exporting a basket Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org When exporting a basket with the default CSV profile: Use of uninitialized value in string eq at /home/vagrant/kohaclone/acqui/basket.pl line 173. CGI::param called in list context from package CGI::Compile::ROOT::home_vagrant_kohaclone_acqui_basket_2epl line 177, this can lead to vulnerabilities. See the warning in "Fetching the value or values of a single named parameter" at /usr/share/perl5/CGI.pm line 436. When exporting a basket with some other CSV profile: CGI::param called in list context from package CGI::Compile::ROOT::home_vagrant_kohaclone_acqui_basket_2epl line 177, this can lead to vulnerabilities. See the warning in "Fetching the value or values of a single named parameter" at /usr/share/perl5/CGI.pm line 436. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23