August 2015 - Koha-bugs - lists.koha-community.org

[Bug 14592] New: Export data bad encoding
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14592 Bug ID: 14592 Summary: Export data bad encoding Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: frederic(a)tamil.fr QA Contact: testopia(a)bugs.koha-community.org Tools > Export data produces a file badly encoded, when marc/xml file format is chosen. It works with CSV. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 14106] New: koha-conf paths to zebra libraries are wrong in jessie
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14106 Bug ID: 14106 Summary: koha-conf paths to zebra libraries are wrong in jessie Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: robin(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz On jessie, doing a zebra reindex will cause errors like: 15:10:47-01/05 zebraidx(16108) [warn] No such record type: dom./etc/koha/zebradb/biblios/etc/dom-config.xml A workaround is documented here: http://wiki.koha-community.org/wiki/Troubleshooting_Zebra#No_such_record_ty… However we need to get it working out of the box, and to be backwards compatible. My plan is: * have koha-start-zebra check for the location of mod-dom.so, probably searching through a predefined list. * have it create a symlink inside /var/lib/koha that points to the right directory for the libraries. * update the zebra*.cfg templates so that they point to the new symlink location * as part of postinst, update the configuration for currently installed files so that they point to the symlink location. This'll mean that it'll work on all the layouts of the zebra libraries that we care to handle. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 14674] New: koha-create should set upload_path in koha-conf.xml
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14674 Bug ID: 14674 Summary: koha-create should set upload_path in koha-conf.xml Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 14453] New: kohaidx is missing for id in authority-koha-indexdefs.xml
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14453 Bug ID: 14453 Summary: kohaidx is missing for id in authority-koha-indexdefs.xml 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In authority-koha-indexdefs.xml, all tags use the namespace "kohaidx" except the tag "id". When re-generating authority-zebra-indexdefs.xsl, the line : <xslo:variable name="idfield" select="normalize-space(marc:controlfield[@tag='001'])"/> is modified : <xslo:variable name="idfield" select="normalize-space()"/> This is an error. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 14098] New: Regression in Marc Modification Templates
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14098 Bug ID: 14098 Summary: Regression in Marc Modification Templates Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In previous versions of Koha, a marc modfication rules like "Copy field XXX$Y to 952$x" would add the field to an existing 952 field if there was one already, and only create a 952 field if none existed. Now an entirely new 952 field is created to store the subfield even if there is already one! -- You are receiving this mail because: You are watching all bug changes.

1 42

[Bug 14597] New: Reverting a batch where a record overlaid a now deleted record will fail
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14597 Bug ID: 14597 Summary: Reverting a batch where a record overlaid a now deleted record will fail Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If batch of records is used to overlay existing records, and one of those records is deleted, any attempt to revert this batch will fail. The unanimous consensus is that deleted records should stay deleted ( https://lists.katipo.co.nz/public/koha/2015-June/043048.html ). -- You are receiving this mail because: You are watching all bug changes.

1 40

[Bug 14509] New: Koha still allows spaces at the end, beginning or as your password
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14509 Bug ID: 14509 Summary: Koha still allows spaces at the end, beginning or as your password Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org This is a follow-up bug for bug 10177 which fixed the 'change password' page to not allow your password to have spaces at the beginning or ending or to consist solely of spaces. But there are still 2 other pages to fix: - Patron account > Edit patron - OPAC > Change password -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 14339] New: Installer broken by bug 13967
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14339 Bug ID: 14339 Summary: Installer broken by bug 13967 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major 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 introduction of the new Koha::Config::SysPrefs package slightly changed the behaviour on syspref retrieval by not catching DB errors (notably when there is no DB structure :-/, which should be detected and redirected to the installer/maintenance depending on the interface) -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 14031] New: Itemnumber should be a numeric search in ccl.properties
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14031 Bug ID: 14031 Summary: Itemnumber should be a numeric search in ccl.properties Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl At the moment, if you do a search in the OPAC or staff client for "itemnumber:1", you'll get no results even when you have an item with an itemnumber of 1. That's because Zebra defaults to a word list search, but there is no word index for itemnumber. It's a numeric index. So, to find that item, you'll have to try "itemnumber,st-numeric:1". However, by tweaking ccl.properties, we can make "itemnumber:1" work as well. We already do this for "notforloan" which we know will always be numeric. Current ccl.properties: notforloan 1=8008 4=109 itemnumber 1=8010 4=109 is the PQF/RPN for "st-numeric". So... let's just add "4=109" to itemnumber, and be merry! -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 10824] New: OAI-PMH repository/server not handling time in "from" argument
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '15

10 Nov '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10824 Bug ID: 10824 Summary: OAI-PMH repository/server not handling time in "from" argument Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, if you try to use time in a "from" argument with the Koha OAI-PMH repository/server, you'll get unexpected results. Case 1: There are 3 records with the following timestamps: 2013-09-02 10:29:40 2013-09-05 13:44:33 2013-09-05 13:44:34 However, if you sent a request using "2013-09-02 8:29:40" or "2013-09-02T8:29:40Z" (the latter being the 'proper' way), you'll only retrieve the last 2 records of the 3 record set. This is because we're using this code to check the "from" and "until" arguments: "WHERE DATE(timestamp) >= ? AND DATE(timestamp) <= ?" We need to strip DATE() from around the timestamps. If we just compare the normal timestamp, MySQL can handle properly compare the timestamp against the following strings: "2013-09-02" "2013-09-02 8:29:40" "2013-09-02T8:29:40Z" (NB This one produces a warning (not an error) so it's less than ideal) I'm proposing that we remove DATE() and include a regex to strip UTC designators T and Z. This way, we'll always be passing in "2013-09-02" or "2013-09-02 8:29:40" which work perfectly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21