November 2014 - Koha-bugs - lists.koha-community.org

[Bug 12885] New: Search fails with errors when HTML5 Media is enabled and url has plus (+) charcters
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '15

22 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12885 Bug ID: 12885 Summary: Search fails with errors when HTML5 Media is enabled and url has plus (+) charcters Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org For example, the following URL in 856$u: http://www.mrqe.com/lookup?talented+mr.+ripley will trigger the following error: Quantifier follows nothing in regex; marked by <-- HERE in m/+ <-- HERE ripley/ at /var/lib/koha/coos/kohaclone/C4/HTML5Media.pm line 113. This will make all searches where the record in question is in the results impossible. You will get the error instead of search results. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 11247] New: Wrong param order in TransformHtmlToXml() call
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '15

22 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11247 Bug ID: 11247 Summary: Wrong param order in TransformHtmlToXml() call 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: srdjan(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Indicator and indicator_tag are placed in revers order when making TransformHtmlToXml() call. It cannot be spotted, because indicators are empty anyway. It generates warnings in the log file. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 12632] New: Hold limits ignored for record level holds with item level itemtypes
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '15

22 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12632 Bug ID: 12632 Summary: Hold limits ignored for record level holds with item level itemtypes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests 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 The crux of the issue is that if you are using item level itemtypes, but are allowing biblio levels holds, those holds do not have items. So, in CanItemBeReserved, when Koha counts the number of holds to compare against the given rule, it will always give 0 ( except of course for found holds, and the occasional item-level hold ). So the query is saying "link each of these reserves to the reserved item, and count the number of reserves this patron where the itemtype is DVD". However, since these are all record level reserves, there are no items to link to, and so when it looks for all reserves this and item whose itemtype is DVD, it finds zero reserves! I can see a few resolutions to this: 1) Add a system preference ReservesControlTypeLevel to allow a library to select between item and record level itemtypes for hold rules. 2) Use COALESCE(itype,itemtype) to more gracefully select record level itemtypes if the reserve is a record level hold 3) Add a conditional if to our query such that if the reserve has no itemtype, we should join on reserves.biblionumber=items.biblionumber instead of reserves.itemnumber=items.itemnumber, with a 'GROUP BY itemnumber' tacked on. 4) The same as 3, but instead of a conditional, join to items twice, once by itemnumber items_i, once by biblionumber items_b. Group by itemnumber, use COALESCE( items_i.itemtype, items_b.itemtype ) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 55

[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 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 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