February 2011 - Koha-bugs - lists.koha-community.org

[Bug 5449] New: JSON malformed in Koha - Blocker with jQuery 1.4.x
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '11

14 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5449 Summary: JSON malformed in Koha - Blocker with jQuery 1.4.x Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: brice.sanchez(a)sys-tech.net QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Created attachment 2789 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2789 Patch for JSON bug [EN] After updating jQuery in version 1.4.3, I could not import MARC records with the tools "Stage MARC records for import". Indeed, JSON was malformed, the JSON script did not respect the standard. So I changed all JSON scripts created on Koha. Please note, this problem is a blocker with jQuery 1.4.x but not with 1.3.x as the old version was more permissive. Attached patch. [FR] Après avoir mis à jour jQuery en version 1.4.3, je ne pouvais plus importer de notices MARC avec l'outils "Stage MARC records for import". En effet, les JSON étaient mal formés, ils ne respectaient pas la norme. J'ai donc modifié tous les script créant des JSON sur Koha. Attention, ce problème est bloquant avec jQuery 1.4.x mais pas 1.3.x car l'ancienne version était plus permissive. Ci-joint, le correctif -- 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 11

[Bug 4993] New: ldap search always anonymous when using auth_by_bind
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '11

14 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4993 Summary: ldap search always anonymous when using auth_by_bind Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Authentication AssignedTo: gmcharlt(a)gmail.com ReportedBy: dpavlin(a)rot13.org QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When using auth_by_bind, search was always done as anonymous user. This is a problem if we want to fetch LDAP values which have ACL permissions only for users. -- 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 11

[Bug 5714] New: Unescaped ampersands in OPAC facets
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '11

14 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5714 Summary: Unescaped ampersands in OPAC facets Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Unescaped ampersands are being sent to the template in the query_cgi variable. -- 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 17

[Bug 5653] New: default new label layout and sample data have broken call number placeholder
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '11

13 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5653 Summary: default new label layout and sample data have broken call number placeholder Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Label printing AssignedTo: cnighswonger(a)foundations.edu ReportedBy: gmcharlt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The sample label layout data and the hardcoded default values for a new spine label layout refer to 'callnumber' instead of 'itemcallnumber'. Consequently, labels based on these layouts will not include the call number unless the user manually updates the layout to use itemcallnumber. -- 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 12

[Bug 5305] New: Resorting results of CCL queries fails in Staff Client
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '11

08 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5305 Summary: Resorting results of CCL queries fails in Staff Client Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Staff Client AssignedTo: paul.poulain(a)biblibre.com ReportedBy: jcamins(a)cpbibliography.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 If you do a CCL query in the Staff Client and then try to change the sorting of the results, you will be redirected back to the Advanced Search page because of a malformed query URL. For some reason the "q=" is getting URL escaped. This problem does not appear with non-CCL queries. -- 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 5240] New: next link hidden on edit subfields
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '11

08 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5240 Summary: next link hidden on edit subfields Change sponsored?: --- Product: Koha Version: HEAD Platform: All URL: cgi-bin/koha/admin/marc_subfields_structure.pl?tagfiel d=952&frameworkcode=BKS OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Created attachment 2642 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2642 next link When you're on the frameworks editor and you're editing subfields, if there are too many subfields they go on to another page, but the Next link is below the Edit button and gets lost. Either all subfields should be on the one page or the next button should be clearer -- 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 12

[Bug 5601] New: SIP Due dates miscalculated via DateTime
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '11

07 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5601 Summary: SIP Due dates miscalculated via DateTime Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: SIP2 AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: ohiocore(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 SIP checked out items report incorrect due date of 1 day earlier than actual due date. Koha data internally and staff interface both show correct date, so the error is only in SIP's "view" of the date. mysql> select itemnumber,barcode,onloan from items where barcode="33518003139989" or barcode="33518003273994"; +------------+----------------+------------+ | itemnumber | barcode | onloan | +------------+----------------+------------+ | 115532 | 33518003139989 | 2011-01-23 | | 127096 | 33518003273994 | 2011-01-23 | +------------+----------------+------------+ Staff interface shows, for example: "Checked out to 23518000442008 : due 01/23/2011". But when we pull it using SIP telnet login via an Item Information (17) request: 1720110103 115501AOLGPL|AB33518003139989| 1804020120110103 115559AB33518003139989|AJDon't sleep, there are snakes :|AQLGPL|BGLGPL|AH20110122 160000| 1720110103 115501AOLGPL|AB33518003273994| 1804020120110103 115655AB33518003273994|AJThe elegance of the hedgehog|AQLGPL|BGLGPL|AH20110122 160000| So that shows the date due stamp (AH) is consistently 8 hours early. The use of the DateTime module has introduced this logical error. This is exactly why *not* to use one-off new Date dependencies and string hacking in leaf code, if there is any way to avoid it. Specifically, the DateTime constructor does NOT default to local timezone, or in fact to ANY timezone, when invoked with the current arguments. You can demonstrate this w/ the following test: $ date Mon Jan 3 14:47:30 PST 2011 $ perl -e 'use DateTime; my $x=DateTime->now(); my $y=DateTime->new(year=>2011,month=>1,day=>3); print $x, " ", $x->time_zone_long_name(), " ", $x->epoch, "\n", $y, " ", $y->time_zone_long_name(), " ", $y->epoch, "\n"; ' 2011-01-03T22:47:33 UTC 1294094853 2011-01-03T00:00:00 floating 1294012800 So the timezone of the objects that we are getting is "floating". See: http://search.cpan.org/~drolsky/DateTime-0.66/lib/DateTime.pm#Floating_Date… where we are advised: "If you are planning to use any objects with a real time zone, it is strongly recommended that you do not mix these with floating datetimes." All of our objects have real timezones, namely the local $ENV{TZ} one. -- 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 7

[Bug 5684] New: Z search on OCLC pulls in 952s
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '11

30 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5684 Summary: Z search on OCLC pulls in 952s Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 Created attachment 3051 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3051 imported from oclc When you search on Z39.50 and use OCLC as your target it brings in 952 fields (aka holdings) from other libraries. Z search should either offer an option (like marc import) or ignore all holdings fields when importing. This can be done with a sys pref and/or an option the Z search form. The discussion on IRC can be read below. [08:58] <nengard> is the z search in acq different from the one in cataloging? I have a report that the acq z search is pulling in 952 fields but i've never seen the cataloging one do that [08:59] <kf> nengard: the forms are differnt - I added some missing options. And you can define a framework- not sure about other differences [09:06] <slef> kf: koha jone or another one? [09:08] <jcamins> nengard: I just realized what it is. [09:08] <jcamins> OCLC. [09:09] <nengard> oh!!!!!!!! [09:09] <jcamins> I remember deleting those fields at Princeton, too. [09:10] <slef> jcamins: always? [09:10] <jcamins> slef: well, we always did at Princeton. [09:10] <jcamins> Maybe some people keep them. [09:10] <slef> jcamins: as in OCLC always send 9xx fields? [09:10] <jcamins> I think so. [09:11] <slef> bleah, I hope that's documented [09:11] * slef browses http://www.oclc.org/ [09:11] <slef> http://www.oclc.org/support/documentation/z3950/search_IRs/#952structure [09:12] <nengard> ICK [09:12] <nengard> but good that it's documented [09:12] <slef> so OCLC users need to configure Koha to use something else? [09:12] <slef> Someone told me why Koha uses 952 but I forget. [09:12] <nengard> i have a theory .... but it's not a nice one :) [09:13] <slef> nengard: what's yours? Mine is 852 => 952 [09:14] <slef> Should koha's z search warn and offer to discard if it sees a biblio/items mapped field in results? [09:14] * Nate_ has quit (Quit: Nate_) [09:14] * tcohen (~tomas(a)atlas.unc.edu.ar) has joined #koha [09:15] <jcamins> slef: because 952 is used for local holdings by OCLC. [09:15] * Nate_ (~nathancur(a)c-24-147-25-6.hsd1.ct.comcast.net) has joined #koha [09:16] <nengard> slef the marc import lets you ignore holdings - so i think the z search should too [09:16] <nengard> maybe a sys pref or a checkbox on the z search page (don't import 952) [09:17] <nengard> i'll start a report for this and include the chat -- 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 7

[Bug 5080] New: koha-create doesn't create the zebra-related directories for authorities
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '11

29 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5080 Summary: koha-create doesn't create the zebra-related directories for authorities Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Packaging AssignedTo: robin(a)catalyst.net.nz ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 koha-create creates the zebra directories for biblios, but not authorities. -- 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 4

[Bug 4935] New: Batch Modify tool cannot "unset" options such as Lost status
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '11

24 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4935 Summary: Batch Modify tool cannot "unset" options such as Lost status Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When using the batch modify tool, one cannot unset a set status such as Lost with an empty value. As this is one of the first things my librarians will try to do with this tool, I propose that all authorized value fields be allowed to be emptied using this tool (Lost, Damaged, Not For Loan, Use Restrictions, etc.). The tool CAN set items to a value from a null value (good behavior). -- 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 15