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

[Bug 10659] New: Upgrade jQuery star ratings plugin
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '15

21 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10659 Bug ID: 10659 Summary: Upgrade jQuery star ratings plugin Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org The version of the jQuery star ratings plugin that Koha uses is not compatible with the latest version of jQuery. If we want to be able to upgrade jQuery we need to also upgrade the star ratings plugin, which is now at version 4.11 (we have v3.14). -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 12897] New: Enhance date ranges in ccl.properties with Zebra
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '15

21 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12897 Bug ID: 12897 Summary: Enhance date ranges in ccl.properties with Zebra 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, we're fairly inconsistent with how we handle dates with Zebra indexing and searching. 1) _INDEXING_ The "registers" that we typically want to use for dates are "year" (y - Non-tokenized and non-normalized 4 digit numbers) and "date" (d - Non-tokenized and non-normalized ISO date strings) (http://www.indexdata.com/zebra/doc/querymodel-zebra.html) Sometimes we might need to use "numeric" if the date format isn't supported by "year" (YYYY) or "date" (which has to be YYYY-MM-DD format, it seems). However, at the moment, "pubdate" is the only index with a "year" register, and "acqdate"/"Date-of-acquisition" is the only index with a "date" register. The numeric register is also used sub-optimally. We use it for "onloan" and "pubdate", but both of those have better registers to use. Numeric (via st-numeric) works with "pubdate" because 1900-2000 is a straight forward numerical range. (The more I think about it, the more the difference between "year" and "numeric" might not matter too much. However "date" offers benefits when it comes to range searching.) Here are some other date indexes we have: 1) Date/time-last-modified (only has a 'word' register) - could maybe have a 'numeric' register as it has a format of yyyymmddhhmmss.f, but I'm not 100% sure. 2) date-entered-on-file ('word' and 'sort') - could have a 'numeric' register as it should be in YYDDMM format. (Neither 'year' nor 'date' would work, but 'numeric' could.) 3) copydate (only has a 'word' and 'sort' register) - could have a 'year' register as it should be in YYYY format. 4) onloan ('numeric' and 'word') - could have a 'date' register as it's in ISO format 5) datelastseen ('word') - could have a 'date' register as it's in ISO format 6) datelastborrowed ('word') - could have a 'date' register as it's in ISO format 7) replacementpricedate ('word') - could have a 'date' register as it's in ISO format ['pubdate' has 'word', 'numeric', 'year', and 'sort' registers.] ['acqdate'/'Date-of-acquisition' has 'word', 'date', and 'sort' registers.] ['tpubdate' exists in ccl.properties but isn't indexed for our MARC21.] 2) _SEARCHING_ Zebra has a built-in ability to do range searches. It relies on two special attributes to accomplish this: r=o and r=r (http://www.indexdata.com/yaz/doc/tools.html#ccl.qualifiers) r=o Allows ranges and the operators greather-than, less-than, ... equals. This sets Bib-1 relation attribute accordingly (relation ordered). A query construct is only treated as a range if dash is used and that is surrounded by white-space. So -1980 is treated as term "-1980" not <= 1980. If - 1980 is used, however, that is treated as a range. r=r Similar to r=o but assumes that terms are non-negative (not prefixed with -). Thus, a dash will always be treated as a range. The construct 1980-1990 is treated as a range with r=r but as a single term "1980-1990" with r=o. The special attribute r=r is available in YAZ 2.0.24 or later. Uses of r=r: 1) copydate 2) pubdate 3) lex 4) arl 5) arp Uses of r=o: 1) st-numeric (this is a qualifier or "structure attribute" which tells Zebra to use the "numeric" register) So... looking back at the _INDEXING_ section... it's clear that anything with a "date" register should use "r=o" for range searching, as YYYY-MM-DD has internal hyphens which would negatively affect a r=o search. When using a "numeric" or "year" register, we can use r=r. Personally, I rather we use r=o (e.g. X - X) rather than r=r (e.g. X-X), but we already have existing documentation in the manual (and on the advanced search page) saying that "X-X" is how you specify a date range. I'd be open to hearing ideas about this one. r=o is the only possibility for specifying date ranges for ISO formatted dates, and it works for YYYY dates as well, whereas r=r will only work for positive integers. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 11603] New: Gather print notices: add csv and ods export
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '15

20 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11603 Bug ID: 11603 Summary: Gather print notices: add csv and ods export Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org I completely refactored the gather_print_notices cronjob in order to allow the generation of csv and ods files. You can have a look at the wip on the BibLibre repo: http://git.biblibre.com/?p=kohac;a=shortlog;h=refs/heads/sanop/ft/MT13212 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 91

[Bug 14472] New: Wrong ISSN search index in record matching rules
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '15

18 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14472 Bug ID: 14472 Summary: Wrong ISSN search index in record matching rules Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: amitddng135(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 40721 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=40721&action=edit Wrong search index Wrong ISSN search index in record matching rules. Currently ISSN record matching rules using "isbn" search index. Result: 1) Not able to upload records via 022$a (ISSN) matching rule. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 14510] New: Allow column visibility in additem.pl to be customized
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '15

18 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14510 Bug ID: 14510 Summary: Allow column visibility in additem.pl to be customized Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: jweaver(a)bywatersolutions.com Reporter: jweaver(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It should be possible to customize column visibility in the items table in additem.pl through the columns configuration tool. -- You are receiving this mail because: You are watching all bug changes.

1 36

[Bug 12133] New: Guarantor requirements when registering a patron
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '15

18 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12133 Bug ID: 12133 Summary: Guarantor requirements when registering a patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 27517 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=27517&action=edit Add two requirements when registering a new patron Attached patch adds two new requirements when registering a new patron: - A child patron must have a guarantor. - A guarantor cannot be a guarantee. Both of these stem from legal requirements in Finland - these might not be applicable for everywhere, so perhaps a syspref to control one, or both, might be in order? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 14382] New: datepicker's dateFormat setting for reports is missing
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '15

17 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14382 Bug ID: 14382 Summary: datepicker's dateFormat setting for reports is missing Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: costalc(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org datepicker's dateformat setting for reports is missing. Reports always run with ISO date format (yyyy-mm-dd) but this setting is missing in /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/LANGUAGE/modules/reports/guided_reports_start.tt. Because of this date format in datepicker plugin adopts the format defined in dateformat syspreferences variable and this is wrong. To solve this is needed to include this code below line 169: // redefine the datepicker's default because reports require ISO // http://jqueryui.com/demos/datepicker/#option-dateFormat $( ".datepicker" ).datepicker( "option", "dateFormat", "yy-mm-dd" ); Tested in 3.18.7 release. In 3.2 is not missing so it works fine. -- You are receiving this mail because: You are watching all bug changes.

1 41

[Bug 13229] New: Suggestion date filters have a style problem
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '15

17 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13229 Bug ID: 13229 Summary: Suggestion date filters have a style problem 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Created attachment 33444 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=33444&action=edit Screenshot The date related filters on the suggestion page don't look quite right/as before. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 13220] New: Shipment date not saved when creating an invoice which has a duplicated number
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '15

17 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13220 Bug ID: 13220 Summary: Shipment date not saved when creating an invoice which has a duplicated number 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: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org When creating an invoice which has a duplicated number, if the user chooses to 'Create new invoice anyway', previously entered shipment date (todays date by default) is not being saved, because the date value is passed to the script in the wrong format (acqui/parcels.pl expects shipmentdate parameter to be in the system-configured date format, but what it's getting in such cases is ISO-formatted date instead). As a consequence (when receiving orders from invoice whith empty shipment date) 'datereceived' field in order records are also not being populated. Here and there, Koha is using datereceived field to establish if the order was received or not received, so such not-quite-complete orders: - can be cancelled from the basket (even when they are de facto already received), - it's not possible to cancel receipt of those orders from the invoice (because Koha is considering them as not yet received). To reproduce: 1) Make sure you have some system date format configured in your test environment which is different from ISO format (e.g., DD/MM/YYYY) and the AcqWarnOnDuplicateInvoice syspref is enabled 2) Create some invoice with e.g. '11111' number, 3) Create another invoice with the same number (using 'Create new invoice anyway' button) 4) Try to create yet another invoice with the same number; observe that already existing invoice created in step 3) does have empty shipment date. 5) Optional: create some orders and receive them from the invoice with empty shipment date; observe that such orders are not being treated as received in all places (e.g. it's not possible to cancel receipts of such orders, and the message displayed is not in any way helpfull to determine why not). Note: empty shipment date field in invoice and/or order records may be not readilly apparent in some other places in the acquisitions module, e.g. on the order receive page, there is a date being displayed labeled as 'Received on: ', but this is not the value from the database, it's just today's date. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 13207] New: "Branch:" on basket page should read "Library:"
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '15

17 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13207 Bug ID: 13207 Summary: "Branch:" on basket page should read "Library:" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The label "Branch:" on the basket summary page should be "Library: " instead. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9