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

[Bug 4995] New: extended attributes replication from LDAP
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '11

28 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4995 Summary: extended attributes replication from LDAP 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 Documentation for extended attributes is somewhat lacking, and my last patch in my previous bug report just fixed case without any extended attributes in LDAP. -- 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 9

[Bug 5215] New: Barcode field not cleared when using "Add and Duplicate" option on additem.pl
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '11

22 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5215 Summary: Barcode field not cleared when using "Add and Duplicate" option on additem.pl Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: cnighswonger(a)foundations.edu QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 The barcode field is not cleared/incremented properly when using the "Add and Duplicate" option. Rather it is pre-populated with the previously used barcode which causes additem.pl to return a duplicate barcode error if the cataloger does not catch the mistake. The problem is caused by the fact that the current item record is simply duplicated and re-loaded into the form. The solution is to add code which either pre-populates with the next barcode number if the incremental pattern is set or clears the p subfield if one of the various patterns using the javascript plugin is selected. A pull request with an implementation of this will follow. -- 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 10

[Bug 4863] New: Bookfund.pm lacks use C4::Context
by bugzilla-daemon＠bugs.koha-community.org 19 Jul '11

19 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4863 Summary: Bookfund.pm lacks use C4::Context Change sponsored?: --- Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: evelio(a)masmedios.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 After installing koha community 3.0.6 we have a 500 error invoking the following URL on our internal server http://koha2:8088/cgi-bin/koha/acqui/acqui-home.pl change the exchange rate and save, it redirects to http://koha2:8088/cgi-bin/koha/acqui/currency.pl?type=change&CAD=1.29540&ty… and then get the 500 error. Logs says [Wed Jun 09 10:53:36 2010] [error] [client 192.168.x.y] Can't locate object method "dbh" via package "C4::Context" (perhaps you forgot to load "C4::Context"?) at /home/www/koha_bage/lib/C4/Bookfund.pm line 399., referer: http://koha2:8088/cgi-bin/koha/acqui/acqui-home.pl [Wed Jun 09 10:53:36 2010] [error] [client 192.168.x.y] Premature end of script headers: currency.pl, referer: http://koha2:8088/cgi-bin/koha/acqui/acqui-home.pl we have fixed adding the following line at the begining of the file Bookfund.pm use C4::Context; -- 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 2

[Bug 5431] New: Separate state field for library addresses
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '11

17 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5431 Summary: Separate state field for library addresses Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All URL: /cgi-bin/koha/admin/branches.pl OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 If the proposed changes for Bug 5422 are accepted, the same change should be made to the way library addresses are stored. -- 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 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 5548] New: Hard Due Dates Circ Rule
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '11

14 Jul '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5548 Summary: Hard Due Dates Circ Rule Change sponsored?: Sponsored Product: Koha Version: HEAD Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Circulation AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 This development shall enable libraries to specify global and/or ceiling due dates for specific combinations of branchcode, item type and patron category. Full RFC: http://wiki.koha-community.org/wiki/Hard_Due_Dates_Circ_Rule_RFC -- 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 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