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

[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 13124] New: Record titles with parentheses causing label weirdness
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '15

17 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13124 Bug ID: 13124 Summary: Record titles with parentheses causing label weirdness Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org See the attached image -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 11966] New: make course reserves branch specific
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '15

17 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

[Bug 5956] New: Highlight holds on check-in
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '15

17 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5956 Bug #: 5956 Summary: Highlight holds on check-in Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: jcamins(a)cpbibliography.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com When a book is checked in that is on hold, it would be helpful if the title showed up in the list of checked in books in red. When you are checking in a large number of books it is easy to go by the hold message if you are just checking the books in. Highlighting the hold as you highlight the overdue would be a big help. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 8

[Bug 11895] New: Keep stats on reserves
by bugzilla-daemon＠bugs.koha-community.org 17 Sep '15

17 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11895 Bug ID: 11895 Summary: Keep stats on reserves 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 It would be nice if Koha tracked that an item was on reserve at some point and when it was on reserve it checked out X times. Versus the data of all of it's checkouts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2