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

[Bug 25857] New: Hold Pickup Location is broken if UseBranchTransferLimits is not enabled
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '20

24 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25857 Bug ID: 25857 Summary: Hold Pickup Location is broken if UseBranchTransferLimits is not enabled Change sponsored?: --- Product: Koha Version: master 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 If UseBranchTransferLimits is disabled, changing the hold pickup location pulldown on addreserve.pl does not trigger a reload, and thus that branch is not checked to see if it is a valid pickup location. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 23309] New: Can't add new subfields to bibliographic frameworks
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '20

24 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23309 Bug ID: 23309 Summary: Can't add new subfields to bibliographic frameworks Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: System Administration 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 When I try to add a new a new subfield to a tag in the bibliographic MARC frameworks, it doesn't save. Tested on a sandbox, found this in the logs: DBD::mysql::st execute failed: Incorrect integer value: '' for column 'hidden' at row 1 [for Statement " insert into marc_subfield_structure (tagfield,tagsubfield,liblibrarian,libopac,repeatable,mandatory,kohafield,tab,seealso,authorised_value,authtypecode,value_builder,hidden,isurl,frameworkcode, link,defaultvalue,maxlength) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) " with ParamValues: 0="922", 1="n", 2="k", 3="k", 4=0, 5=0, 6="", 7="-1", 8=undef, 9="", 10="", 11="", 12="", 13=0, 14="", 15="", 16="", 17="9999"] at /kohadevbox/koha/admin/marc_subfields_structure.pl line 316. DBD::mysql::st execute failed: Incorrect integer value: '' for column 'hidden' at row 1 [for Statement " insert into marc_subfield_structure (tagfield,tagsubfield,liblibrarian,libopac,repeatable,mandatory,kohafield,tab,seealso,authorised_value,authtypecode,value_builder,hidden,isurl,frameworkcode, link,defaultvalue,maxlength) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) " with ParamValues: 0="941", 1="k", 2="k", 3="k", 4=0, 5=0, 6="", 7="-1", 8=undef, 9="", 10="", 11="", 12="", 13=0, 14="", 15="", 16="", 17="9999"] at /kohadevbox/koha/admin/marc_subfields_structure.pl line 316. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 17232] New: Subfield default values are not ported when creating a new framework from an old one
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '20

24 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17232 Bug ID: 17232 Summary: Subfield default values are not ported when creating a new framework from an old one Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: joachim.ganseman(a)ehb.be QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When creating a new bibliographic MARC21 framework from an old one, any default values set for subfields in the old framework are not ported to the newly created framework. They have to be reset. To reproduce: - Set a default value in an existing bibliographic MARC21 framework, e.g. 040$a to your institution's MARC code. - Create a new framework based on that one - Create a new record using that new framework: the default value is not set. - Upon checking the database table marc_subfield_structure (e.g. WHERE tagfield = 40 and tagsubfield = 'a'), notice there is no defaultvalue set in that subfield in the new framework. This issue occurs in a package install of version 16.05 on Debian. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 25842] New: Typo "streetype" in member-main-address-style.inc
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '20

23 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25842 Bug ID: 25842 Summary: Typo "streetype" in member-main-address-style.inc Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Templates Assignee: fridolin.somers(a)biblibre.com Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: fridolin.somers(a)biblibre.com, testopia(a)bugs.koha-community.org Depends on: 25070, 25839 There are several more instances of the incorrect variable "streetype" in member-main-address-style.inc. While not error-causing, they should be corrected for consistency. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25070 [Bug 25070] Include files to display address and contact must be refactored https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25839 [Bug 25839] Typo patron.streetype in member-main-address-style.inc -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 25839] New: Typo patron.streetype in member-main-address-style.inc
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '20

23 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25839 Bug ID: 25839 Summary: Typo patron.streetype in member-main-address-style.inc Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Typo in member-main-address-style.inc : patron.streetype > patron.streettype Generates error : Template process failed: undef error - The method Koha::Patron->streetype is not covered by tests! -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 25774] New: REST API searches don't handle correctly utf8 characters
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '20

23 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25774 Bug ID: 25774 Summary: REST API searches don't handle correctly utf8 characters Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: REST API Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org In the search box, search "❤": [2020/06/16 14:11:37] [ERROR] GET /api/v1/libraries: unhandled exception (Mojo::Exception)<<Wide character in subroutine entry at /kohadevbox/koha/Koha/REST/Plugin/Objects.pm line 107.>> Koha::REST::Plugin::Exceptions::__ANON__ /kohadevbox/koha/Koha/REST/Plugin/Exceptions.pm (73) 172.18.0.1 - - [16/Jun/2020:14:11:37 +0000] "GET /api/v1/app.pl/api/v1/libraries?_page=1&_per_page=20&q=%5B%7B%22me.name%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.library_id%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.marc_org_code%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.ip%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.pickup_location%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.address1%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.address2%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.address3%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.city%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.state%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.postal_code%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.country%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.opac_info%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%2C%7B%22me.notes%22%3A%7B%22like%22%3A%22%25%E2%9D%A4%25%22%7D%7D%5D&_match=contains&_order_by=%2Bme.name HTTP/1.1" 500 - "http://kohadev-intra.mydnsname.org:8081/cgi-bin/koha/admin/branches.pl" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0" -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 25702] New: Actions button on Search results from Z39.50 is displayed incorrectly
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '20

23 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25702 Bug ID: 25702 Summary: Actions button on Search results from Z39.50 is displayed incorrectly Change sponsored?: --- Product: Koha Version: 20.05 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: jkniez(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 105671 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=105671&action=e… Screenshot of the wrong position of the menu launched by Actions button When clicking on the Actions button in the Z39.50 Search Results window, sometimes the menu is not displayed correctly (actually it is displayed under or next to the table with Results and it is not visible in the displayed area). Usually it happens after clicking on the table row and then on the Actions button. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 25859] New: 19.11 upgrade creates holdfullfilment rule with empty value
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '20

23 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25859 Bug ID: 25859 Summary: 19.11 upgrade creates holdfullfilment rule with empty value Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com As part of bug 18928, we moved rules from default_circ_rules to circulation_rules. We created an entry in circulation rules where rule name hold fulfillment policy where it was null, we created an entry where this null value became an empty string instead which Koha treats differently than the NULL value it was. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 25860] New: 19.11 upgrade creates Return Policy rule with empty value
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '20

23 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25860 Bug ID: 25860 Summary: 19.11 upgrade creates Return Policy rule with empty value Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com As part of bug 18928, we moved rules from default_circ_rules to circulation_rules. We created an entry in circulation rules where rule name Return policy (in Default Checkout, hold and return policy) originally was null pre-upgrade, at the upgrade we created an entry where this null value became an empty string instead which Koha treats differently than the NULL value it was. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15522] New interface for revamped circulation rules
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '20

23 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522 --- Comment #123 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- Could columns be accordioned like rows? Maybe accordion each column, or groups according to topic? Then maybe a button/link that shows all or return to accordion? Sometimes we like to scan the page, and having all show as we scroll is good, but we don't want to scroll all the time. -- You are receiving this mail because: You are watching all bug changes.

1 0