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

[Bug 11273] New: Barcode generation (AutoBarcode) in acquisitions is broken
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '15

22 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11273 Bug ID: 11273 Summary: Barcode generation (AutoBarcode) in acquisitions is broken Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: major 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 When AutoBarcode is activated and you have set AcqCreateItem to 'on order' there is a Javascript error when you try to generate a barcode for the item: TypeError: document.f is undefined http://localhost:8080/intranet-tmpl/lib/jquery/jquery.js Line 11 I am not sure if this used to work, but we shouldn't offer the plugin '...' and there should be no javascript errer. And ideally it should work :) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 12965] New: can create an item type that already exists
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '15

22 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12965 Bug ID: 12965 Summary: can create an item type that already exists Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If you create an item type that already exists it will overwrite that item type without warning the user. So if you have a DVD type and create a new DVD type the old type gets overwritten by the new with no warning. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[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 11966] New: make course reserves branch specific
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '15

18 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11966 Bug ID: 11966 Summary: make course reserves branch specific Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Would be nice if each library could have their own courses and if a library doesn't use course reserves the link to course reserves didn't show in the OPAC for that library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1