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

[Bug 4232] New: Undefined hash references in Label Creator
by bugzilla-daemon＠kohaorg.ec2.liblime.com 02 Apr '10

02 Apr '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4232 Summary: Undefined hash references in Label Creator Product: Koha Version: HEAD Platform: PC OS/Version: Windows 2000 Status: NEW Severity: major Priority: P2 Component: Label printing AssignedTo: cnighswonger(a)foundations.edu ReportedBy: Ian.Walls(a)med.nyu.edu Estimated Hours: 0.0 Change sponsored?: --- When attempting to search for new items to add to a batch, a search with results returns: Can't use an undefined value as a HASH reference at /usr/share/koha/intranet/cgi-bin/labels/label-item-search.pl line 129 Similarly, if one can get to manage a created batch, attempting to edit a batch will result in Can't use an undefined value as a HASH reference at /usr/share/koha/lib/C4/Creators/Lib.pm line 321 This seems to be caused by some compilations of Perl not allowing a hash to be declared and assigned on the same line. The offending lines of code are: my $item_data->{'_item_number'} = $item_results->{$item}->{'itemnumber'}; (from label-item-search.pl) my $label_summary->{'_label_number'} = $label_number; (in C4/Creators/Lib.pm). Splitting the declaration and assignment into two lines fixes the problem. my $item_data; $item_data->{'_item_number'} = $item_results->{$item}->{'itemnumber'}; (from label-item-search.pl) my $label_summary; $label_summary->{'_label_number'} = $label_number; (in C4/Creators/Lib.pm). -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4

[Bug 4359] New: noItemTypeImages not active in OPAC
by bugzilla-daemon＠kohaorg.ec2.liblime.com 31 Mar '10

31 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4359 Summary: noItemTypeImages not active in OPAC Product: Koha Version: HEAD Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: jwagner(a)ptfs.com Estimated Hours: 0.0 Change sponsored?: --- The admin syspref noItemTypeImages appears to have no effect at all in the OPAC. If an item type has an image assigned, it will display regardless of whether the syspref is on or off. The icons show up in the advanced search page and on title display pages (and independent of XSLT being on or off). Is this by design? Or should the OPAC be told to obey the syspref? So far as I can tell, the syspref does work properly for staff mode. For advanced search, the problem seems to be in opac-search.pl, in this segment: my %row =( number=>$cnt++, ccl => $itype_or_itemtype, code => $thisitemtype, selected => $selected, description => $itemtypes->{$thisitemtype}->{'description'}, count5 => $cnt % 4, imageurl=> getitemtypeimagelocation( 'opac', $itemtypes->{$thisitemtype}->{'imageurl'} ), ); The imageurl line should check for the syspref. Haven't looked at the details display code yet. I'm thinking there should be a separate OPACnoItemTypeImages so that staff and OPAC can be set differently. Both the advanced search page and the title display page should obey it. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 4354] New: Cannot edit existing issuing rules
by bugzilla-daemon＠kohaorg.ec2.liblime.com 30 Mar '10

30 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4354 Summary: Cannot edit existing issuing rules Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: cmurdock(a)ccfls.org Estimated Hours: 0.0 Change sponsored?: --- The only way to change an existing issuing rule is to re-enter all the values for it as if you were adding a new rule. There should probably be a simpler way to edit an existing issuing rule, so you can more easily change a single value if you want to. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 2865] Acquisitions: GST not calculating correctly.
by bugzilla-daemon＠kohaorg.ec2.liblime.com 30 Mar '10

30 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2865 --- Comment #7 from Chris Cormack <chris(a)bigballofwax.co.nz> 2010-03-30 03:37:29 --- Jo is currently testing a fix for this, if it works we will send the patch upstream -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 4194] New: Syspref ILS-DI is missing
by bugzilla-daemon＠kohaorg.ec2.liblime.com 29 Mar '10

29 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4194 Summary: Syspref ILS-DI is missing Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: henridamien(a)koha-fr.org ReportedBy: magnus(a)enger.priv.no Estimated Hours: 0.0 Change sponsored?: --- The script ils-di.pl looks for a syspref called ILS-DI, which seems not to be set up by default. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 4347] New: advanced tag editor for Fields 000 and 008 in IE
by bugzilla-daemon＠kohaorg.ec2.liblime.com 29 Mar '10

29 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4347 Summary: advanced tag editor for Fields 000 and 008 in IE Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Browser compatibility AssignedTo: oleonard(a)myacpl.org ReportedBy: herrkandera(a)gmx.ch CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- The advanced tag editor is not opening for the fields 000 and 008 in IE 6, 7 and 8. This is due to a spacing error in the java section of the files under (/usr/share/koha/intranet/cgi-bin/cataloguing/value_builder): - marc21_field_008.pl (line 69) - marc21_field_008_authorities.pl (line 65) - marc21_leader.pl (line 59) - marc21_leader_authorities.pl (line 59) It reads: "unimarc field 100\",'width=1000,height=600,toolbar=false,scrollbars=yes'); but should be: "unimarc_field_100\",'width=1000,height=600,toolbar=false,scrollbars=yes'); This causes an error in IE. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 4343] New: OPAC My Account - Users unable to See Loans/Reserves
by bugzilla-daemon＠kohaorg.ec2.liblime.com 29 Mar '10

29 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4343 Summary: OPAC My Account - Users unable to See Loans/Reserves Product: Koha Version: 2.2.9 Platform: All OS/Version: All Status: NEW Severity: major Priority: P4 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: joel.r.harbottle(a)gmail.com CC: joel.r.harbottle(a)gmail.com Estimated Hours: 0.0 Deadline: 2010-04-30 Change sponsored?: --- Created an attachment (id=1765) --> (http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=1765) OPAC - MY ACCOUNT Screenshot IT Environment: Client Machines: PC/Mac (Internet Explorer 7, Mozilla Firefox 3, Apple Safari) Koha Server: PC (running Windows XP Professional SP3) Koha version: 2.2.9 --- Problem: Whenever any user logs into the MY ACCOUNT function of the OPAC, they are unable to see details of their loans. This is also the case for any hold requests they have placed aswell. Koha will however list next to the current loans area how items are checked out to this patron. You will notice this in the screenshot attached. Please see the screenshot from an example patron on our live system in the attached MS Word document (.doc format). The theme we use on our OPAC is 'npl' which is included in the Koha 2.2.9 install for Windows. We also use the 'npl' theme for the staff client and have no problems in the staff client, only the OPAC! Please help. Kindest Regards, Joel Harbottle Systems Support & Development Library Services (North) -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 4324] New: Let's tangoify Koha
by bugzilla-daemon＠kohaorg.ec2.liblime.com 29 Mar '10

29 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4324 Summary: Let's tangoify Koha Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: jeanandre.santoni(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- The icons used in Koha comes from many different icon sets, and the result is inconsistent. What do you think of using an well known icon set like http://tango.freedesktop.org/Tango_Desktop_Project ? Their guidelines are strict, and the existing icon base is important enough to cover most of our needs. As the templates will be rewritten in 3.4 due to the deprecation of HTML Template Pro, we could rebrand a little bit Koha in the same time. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 2889] templates should use loop_context_vars __odd__
by bugzilla-daemon＠kohaorg.ec2.liblime.com 26 Mar '10

26 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2889 --- Comment #9 from Colin Campbell <colin.campbell(a)ptfs-europe.com> 2010-03-26 16:53:37 --- Created an attachment (id=1763) --> (http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=1763) Patch for boraccount.pl -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 4340] New: patron name search does not handle punctuated names
by bugzilla-daemon＠kohaorg.ec2.liblime.com 24 Mar '10

24 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4340 Summary: patron name search does not handle punctuated names Product: Koha Version: HEAD Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Circulation AssignedTo: dbavousett(a)ptfs.com ReportedBy: dbavousett(a)ptfs.com Estimated Hours: 0.0 Change sponsored?: --- In C4::Members::SearchMember, the system is searching for surnames like "string%" or "% string%". Thus, for a search "steuben", you'll get Steuben, Steubenstein, or Von Steuben, but not "D'Steuben" or "Smith-Steuben". One of our customers would like this to work to find these punctuated names correctly, but merely using LIKE "%string%" is not the answer; in a search for "van", you want to find "Smith-Vandenberg" "Van Smith" or "Vanilla", but not "Sullivan". mysql has the capability of doing REGEXP there, but it is very, very slow, but I found a resource describing a method of using a more-general LIKE, then REGEXPing that, which testing indicates is *much* faster than adding a bunch of LIKEs for all the combinations. Patch coming shortly. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4