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

[Bug 3087] Z39.50 server returns usmarc format records for UNIMARC DB
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '12

30 Aug '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3087 --- Comment #18 from Frédéric Demians <frederic(a)tamil.fr> --- > No, I tested only MARC21 actually. But it is more trivial. The > retrieval schemes are now in separate xml files in etc/zebradb like > retrieval-info-auth-dom.xml etc. (4 files). Thanks for the explanation. I wasn't aware of this. It seems that what you're describing has been introduced by bug 7818. > Your patch only updates etc/koha-conf.xml. The section you update, is > only used if the separate retrieval file should not be found. I will send an updated patch to fix those 4 files. > Actually, I would recommend to just delete the retrieval fallback > section in koha-conf.xml. Now we have a confusing situation; fallback > within the same etc directory does not make much sense to me. Good idea. I think that this simplification should be asked in 7818 bug directly, so Galen could review it. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3087] Z39.50 server returns usmarc format records for UNIMARC DB
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '12

30 Aug '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3087 --- Comment #17 from M. de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to comment #16) > I'm not sure to understand. Could you elaborate? Do you mean that for > UNIMARC there isn't XSL converter to Dublin Core for example? In this > case, this was already the case. This isn't a regression. We just lack > that currently in Koha, and we should plan to fix it separately. No, I tested only MARC21 actually. But it is more trivial. The retrieval schemes are now in separate xml files in etc/zebradb like retrieval-info-auth-dom.xml etc. (4 files). Your patch only updates etc/koha-conf.xml. The section you update, is only used if the separate retrieval file should not be found. Actually, I would recommend to just delete the retrieval fallback section in koha-conf.xml. Now we have a confusing situation; fallback within the same etc directory does not make much sense to me. If you look at those files, you will certainly understand it. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8621] New: Template for sending out carts not formatting correctly
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '12

30 Aug '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8621 Priority: P5 - low Change sponsored?: --- Bug ID: 8621 Assignee: oleonard(a)myacpl.org Summary: Template for sending out carts not formatting correctly Severity: enhancement Classification: Unclassified OS: All Reporter: katrin.fischer(a)bsz-bw.de Hardware: All Status: NEW Version: master Component: Templates Product: Koha I send myself a cart from the English and from the German templates, both emails show wrong formatting. I sent 2 titles, one with, one without items. Then numbering is wrong: Hi, Katrin Fischer sent you a cart from our online catalog. Please note that the attached file is a MARC bibliographic records file which can be imported into personal bibliographic software like EndNote, Reference Manager or ProCite. --------------------------------------------------------------------- 1. Allgemeine deutsche Biographie / * Author(s): Bayerische Akademie der Wissenschaften --Historische Kommission * Published by: Duncker & Humblot,, 54 * Notes : Zitiert.: ADB. - Neudr. mit Ersch.-Ort Berlin. - In Fraktur * Items: 2. Veröffentlichungen des Max-Planck-Instituts für Geschichte 3. Published by: Vandenhoeck & Ruprecht, 54 4. URL : http://www.bsz-bw.de/rekla/show.php?mode=urce&id2 5. Items: * Midway (non public note testing) dia -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 8663] New: Circulation rules hard due date calendar wrong format
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '12

30 Aug '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8663 Priority: P3 Change sponsored?: --- Bug ID: 8663 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Circulation rules hard due date calendar wrong format Severity: normal Classification: Unclassified OS: All Reporter: pelletiermaxime(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Circulation Product: Koha On my install the format has to be "YYYY-MM-DD". The calendar widget outputs a date in the "MM/DD/YYYY" format. Patch to follow to make it use the right date format of your install. I know master uses a new calendar widget, but hardduedate won't work at all if the date format isn't the right one, so I figured it was a bug important enough to a patch for 3.8. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 8596] New: Reports interface date picker doesn't force ISO formatted dates
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '12

30 Aug '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8596 Priority: P5 - low Change sponsored?: --- Bug ID: 8596 Assignee: gmcharlt(a)gmail.com Summary: Reports interface date picker doesn't force ISO formatted dates Severity: normal Classification: Unclassified OS: All Reporter: robin(a)catalyst.net.nz Hardware: All Status: NEW Version: master Component: Reports Product: Koha If you create a report with <<Enter a date|date>>, the resulting date picker interface when running the report doesn't force dates to ISO form, instead they are created using the date format of the system. This is passed to mysql which complains about the format not being right, understandably. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 8626] New: Encoding problem with = in cart emails
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '12

30 Aug '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8626 Priority: P5 - low Change sponsored?: --- Bug ID: 8626 Assignee: oleonard(a)myacpl.org Blocks: 8621 Summary: Encoding problem with = in cart emails Severity: normal Classification: Unclassified OS: All Reporter: katrin.fischer(a)bsz-bw.de Hardware: All Status: NEW Version: master Component: OPAC Product: Koha I have testes this with Outlook Web Access and Thunderbird so far and both mail clients show the problem: Original URL: http://localhost/cgi-bin/koha/opac-detail.pl?biblionumber=5100 Thunderbird/OWA: http://localhost/cgi-bin/koha/opac-detail.pl?biblionumberQ00 I have tracked down the problem with the URLs to it being a problem with encoding and the = character. Currently we have following line sin opac-sendbasket.pl: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems that with this setting the = is interpreted as the beginning of a special character. So if you have a URL or Title containing = it will not be displayed correctly. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 8640] New: GetHardDueDate functions incorrectly
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '12

30 Aug '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8640 Priority: P5 - low Change sponsored?: --- Bug ID: 8640 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: GetHardDueDate functions incorrectly Severity: enhancement Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha GetHardDueDate works just like GetIssuingRule, but it not only tests for having found an row of results before returning, but checks for the existence of a hard due date as well. That means that even if it finds a matching rule, unless that rule has a hardduedate set it will toss it and keep looking! So, for example, even though there is a matching rule for say "STAFF / VIDEO / *", but it has no hardduedate. So it gets tossed and the subroutine keeps looking. If the next match, "STAFF / * / *" *has* a hardduedate, it is the one returned. This means that if a more specific rule has no hard due date, it is overridden by a less specific rule that does have a hard due date. TEST PLAN: 1) Create 2 issuing rules, one more specific with no hard due date, one less specific *with* a hard due date. See my description above for an example. 2) Issue an item to a borrower where the more specific rule should apply, and the checkout should not receive a hard due it. 3) Observe that it *does* receive a hard due date. 4) Apply the patch, and repeat step 2. 5) Observe that the checkout *does not* receive a hard due date. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 8648] New: searchResults uses SQL query rather than GetMarcFromKohaField
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '12

29 Aug '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8648 Priority: P5 - low Change sponsored?: --- Bug ID: 8648 Assignee: jcamins(a)cpbibliography.com Summary: searchResults uses SQL query rather than GetMarcFromKohaField Severity: normal Classification: Unclassified OS: All Reporter: jcamins(a)cpbibliography.com Hardware: All Status: NEW Version: master Component: Architecture, internals, and plumbing Product: Koha Around line 1470-something: my $sth = $dbh->prepare( "SELECT tagfield FROM marc_subfield_structure WHERE kohafield LIKE 'items.itemnumber'" ); $sth->execute; -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 8329] New: GetLostItems in C4::Items.pm has a SELECT *
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '12

29 Aug '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8329 Priority: P5 - low Change sponsored?: --- Bug ID: 8329 Assignee: gmcharlt(a)gmail.com Summary: GetLostItems in C4::Items.pm has a SELECT * Severity: major Classification: Unclassified OS: All Reporter: mtompset(a)hotmail.com Hardware: All Status: NEW Version: unspecified Component: Reports Product: Koha my $query = " SELECT * FROM items LEFT JOIN biblio ON (items.biblionumber = biblio.biblionumber) LEFT JOIN biblioitems ON (items.biblionumber = biblioitems.biblionumber) LEFT JOIN authorised_values ON (items.itemlost = authorised_values.authorised_value) WHERE authorised_values.category = 'LOST' AND itemlost IS NOT NULL AND itemlost <> 0 "; We're using 3.6.3, and I comfirmed this is in 3.6.6. This problem would only be obvious if there are many lost items. It is a hellish query as we have 39,000+ "lost" items. We're in the midst of doing data entry/cleanup on a new system. my $query = " SELECT title, author, lib, itemlost, authorised_value, barcode, datelastseen, price, replacementprice, homebranch, itype, itemtype, holdingbranch, location, itemnotes, items.biblionumber as biblionumber FROM items LEFT JOIN biblio ON (items.biblionumber = biblio.biblionumber) LEFT JOIN biblioitems ON (items.biblionumber = biblioitems.biblionumber) LEFT JOIN authorised_values ON (items.itemlost = authorised_values.authorised_value) WHERE authorised_values.category = 'LOST' AND itemlost IS NOT NULL AND itemlost <> 0 "; This is functional, though it can probably be trimmed. The SELECT * includes XML and MARC fields which are sizable and eat system memory! -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 8547] New: Enabling star ratings causes javascript errors that cause IE to have a boo boo
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '12

29 Aug '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8547 Priority: P5 - low Change sponsored?: --- Bug ID: 8547 Assignee: oleonard(a)myacpl.org Summary: Enabling star ratings causes javascript errors that cause IE to have a boo boo Severity: enhancement Classification: Unclassified OS: All Reporter: robin(a)catalyst.net.nz Hardware: All Status: NEW Version: rel_3_8 Component: OPAC Product: Koha I think this is due to a trailing comma in a list. Real browser are OK with it, but IE is dumb. -- You are receiving this mail because: You are watching all bug changes.

1 15