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

[Bug 5406] New: Allow Koha to authenticate using LDAPS as well as LDAP
by bugzilla-daemon＠bugs.koha-community.org 14 Jun '11

14 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5406 Summary: Allow Koha to authenticate using LDAPS as well as LDAP Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Authentication AssignedTo: gmcharlt(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: dpavlin(a)rot13.org Estimated Hours: 0.0 When we are connecting across the internet to LDAP servers, we should be using LDAPS if at all possible. I propose adding another variable to the LDAP config and changing C4::Auth_with_ldap to be able to do LDAP or LDAPS Net::LDAPS is functionally equivalent to Net::LDAP so will require minimal code changes. -- 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 3

[Bug 5509] New: Packaging scripts get upset when there's an LDAP configuration in the koha_conf.xml
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '11

08 Jun '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5509 Summary: Packaging scripts get upset when there's an LDAP configuration in the koha_conf.xml Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal 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 To find the mysql host, username, and password, the scripts use grep and associated things. However, when LDAP connection details are added, these also match the grep, causing confusion. -- 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