November 2010 - Koha-bugs - lists.koha-community.org

[Bug 5453] New: Variables declaration should not occur in conditionals
by bugzilla-daemon＠bugs.koha-community.org 15 Jul '11

15 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5453 Summary: Variables declaration should not occur in conditionals Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: colin.campbell(a)ptfs-europe.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 This is an antipattern in a lot of Koha code. my $x = Z() if $y; it obscures code and can cause hard to track bugs. What does it say of the value of $x if not $y? Is someone maintaining the code liable to make unwarrantable assumptions about the definedness or value of $x. ( the use of postfix if is also a problem as in reading actual code it is often easy to miss that an assignment is in a conditional because the postfix if has disappeared off the right of your screen. Postfix ifs give a reader very little visual clue that a conditional is occurring. The above cde should be rewritten as my $x; if ($y) { $x = Z(); } Bug opened to record such patches against -- 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 24

[Bug 4994] New: ldap mapping inconsistancy: Net::LDAP returns lowercase names
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '11

14 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4994 Summary: ldap mapping inconsistancy: Net::LDAP returns lowercase names Change sponsored?: --- Product: Koha Version: rel_3_0 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 CC: dpavlin(a)rot13.org Estimated Hours: 0.0 This requires us to specify all LDAP mappings in koha-conf.xml in lowercase, instead of original case used withing LDAP. Compare readability of <userid is="hrEduPersonUniqueID" ></userid> (which doesn't work) with required (and non-intuitive) <userid is="hredupersonuniqueid" ></userid> -- 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 5268] New: Language Issue: Debarred
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '11

14 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5268 Summary: Language Issue: Debarred Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 For those using US English, would it make more sense to change debar and debarred to 'restricted' or 'barred'? I have to admit that I have yet to train a library where they didn't ask what 'debarred' meant and why it wasn't just 'barred' -- 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 6

[Bug 5307] New: language searching fields
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '11

14 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5307 Summary: language searching fields Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The language values from the 008 and 041 fields are what's used to determine the language for the item. It does not differentiate between 041$a (the current language) and 041$h (original language). I think it should only search the 041$a because that's the language of the record you're searching for. -- 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 6

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