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

[Bug 3109] New: Consistency Check, broken img tags
by bugzilla-daemon＠liblime.com 17 May '10

17 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3109 Summary: Consistency Check, broken img tags Product: Koha Version: HEAD Platform: PC URL: http://www.koha.org/about-koha/case-studies/hlt.html OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Websites, Mailing Lists, etc. AssignedTo: jmf(a)liblime.com ReportedBy: joe.atzberger(a)liblime.com Estimated Hours: 0.0 Top of the page says "The first version of Koha went live at HLT in January 2005." That's just wrong. Should be 2000, as the rest of the page goes on to describe. The screenshot images are missing, links are 404. -- 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.

2 2

[Bug 3812] New: Illegal Date 'iso' does not match 'iso' format (Acquisitions)
by bugzilla-daemon＠kohaorg.ec2.liblime.com 17 May '10

17 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3812 Summary: Illegal Date 'iso' does not match 'iso' format (Acquisitions) Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: Acquisitions AssignedTo: rch(a)liblime.com ReportedBy: m.de.rooy(a)rijksmuseum.nl Estimated Hours: 0.0 Change sponsored?: --- >From koha error log: [Mon Nov 23 10:36:57 2009] [error] [client 192.87.126.61] [Mon Nov 23 10:36:57 2009] orderreceive.pl: Illegal Date 'iso' does not match 'iso' format: yyyy-mm-dd at /usr/share/koha/intranet/cgi-bin/acqui/orderreceive.pl line 80. This happens when datareceived parameter does not exist or is empty. In that case the second parameter iso from the line below becomes the first parameter. my $datereceived = C4::Dates->new($input->param('datereceived'),'iso') || C4::Dates->new(); Solution: force the first parameter to be present in the call: my $datereceived = C4::Dates->new($input->param('datereceived')||'','iso') || C4::Dates->new(); -- 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 2

[Bug 3795] New: Incorrect title URL in Receive Order table for multiple items
by bugzilla-daemon＠kohaorg.ec2.liblime.com 17 May '10

17 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3795 Summary: Incorrect title URL in Receive Order table for multiple items Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Acquisitions AssignedTo: rch(a)liblime.com ReportedBy: m.de.rooy(a)rijksmuseum.nl Estimated Hours: 0.0 Change sponsored?: --- This bug is a continuation of bug 3794! If Receive Orders (orderreceive.pl) shows multiple items, clicking on the first row of the table takes you to the data of the second row. Selecting the last row produces a fatal error. Further analysis reveals that the orderreceive template does not produce a correct URL for multiple items. The main reason for the above error is the fact that it generates a biblio parameter instead of the correct biblionumber parameter in the title URL. This makes SearchOrder in Acquisitions.pm not find the correct record with the passed order number. For the first record, it only finds the second record that contains the order number in the title. For the second record, it finds nothing resulting in a fatal error. The orderreceive template must be adjusted for the biblionumber parameter (line 152). After that, clicking on the first row does not yet work (bug 3794). But the second link works now. After receiving the second title, it will be possible to receive the first one. The script orderreceive.pl should formally be corrected to also handle the situation of zero records. -- 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 2

[Bug 3742] New: OPAC Authority Search does not really search anywhere
by bugzilla-daemon＠kohaorg.ec2.liblime.com 17 May '10

17 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3742 Summary: OPAC Authority Search does not really search anywhere Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: jmf(a)liblime.com ReportedBy: m.de.rooy(a)rijksmuseum.nl Estimated Hours: 0.0 Change sponsored?: --- Searching authorities with anywhere on Browse by Subject does not search anywhere but only in Heading, if you leave the other fields blank. This is caused by a small bug in opac-authorities-home.pl. The line filling the @values parameter before calling SearchAuthorities should not be: my @value = ($query->param('valuea'), $query->param('valueb'),$query->param('valuec'),); but should be: my @value = (scalar $query->param('valuea'), scalar $query->param('valueb'),scalar $query->param('valuec'),); Reason: CGI param returns an empty list for the blank values in list context. The parameters are mixed up as a result. Force them to scalar resets the situation. -- 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 2

[Bug 3858] New: Quick Spine Tool Should have Left Menu
by bugzilla-daemon＠kohaorg.ec2.liblime.com 16 May '10

16 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3858 Summary: Quick Spine Tool Should have Left Menu Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Tools AssignedTo: cnighswonger(a)foundations.edu ReportedBy: nengard(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- I think that the Quick Spine Label Tool should either have the Labels menu on the left or the Tools menu on the left - either way there should be a menu to the left of the Quick Spine Label Tool. -- 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 3

[Bug 3981] New: GST confusing in en-US
by bugzilla-daemon＠kohaorg.ec2.liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3981 Summary: GST confusing in en-US Product: Koha Version: HEAD Platform: PC OS/Version: All Status: ASSIGNED Severity: trivial Priority: P5 Component: Acquisitions AssignedTo: nengard(a)gmail.com ReportedBy: nengard(a)gmail.com CC: chris(a)bigballofwax.co.nz Estimated Hours: 0.0 Change sponsored?: --- I spoke with Chris (translation manager) and we decided it was okay to change the en-US translation from GST to Tax. He will add that to the translation tool so that it still says GST for all other en languages. -- 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 6

[Bug 3704] New: SIP Checkin of not checked out item returns error without additional reason
by bugzilla-daemon＠kohaorg.ec2.liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3704 Summary: SIP Checkin of not checked out item returns error without additional reason Product: Koha Version: rel_3_0 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: SIP2 AssignedTo: joe.atzberger(a)liblime.com ReportedBy: patrick.langer(a)easycheck.org Estimated Hours: 0.0 Change sponsored?: --- Checking in a not checked out item returns an error (which is correct) without giving a reason for the failure as screen_msg (aka AF field in SIP2) is empty. Checkin in koha SIP is generally quite sparse when it comes to error handling and reasons for the failure of the checkin. Most times no screen_msg is filled which makes it hard for the self service terminal to display an understandable reason to the patron for the failure. In this case I suggest to insert in SIP::ILS Checkin around row 183 right after $circ->ok($item && $item->{patron}); if (!defined($item->{patron})) { $circ->screen_msg("Item not checked out"); } else { [rest of the transaction part] } -- 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 3125] New: IE7: Selected columns list in Reports Dictionary is not showing column names.
by bugzilla-daemon＠liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3125 Summary: IE7: Selected columns list in Reports Dictionary is not showing column names. Product: Koha Version: rel_3_0 Platform: PC URL: http://staff-dfs4.dev.kohalibrary.com/cgi- bin/koha/reports/dictionary.pl?phase=Add%20New%20Definit ion OS/Version: All Status: NEW Severity: normal Priority: P3 Component: Browser compatibility AssignedTo: joe.atzberger(a)liblime.com ReportedBy: daniel.sweeney(a)liblime.com CC: oleonard(a)myacpl.org, galen.charlton(a)liblime.com Estimated Hours: 0.0 When adding a new definition to the Reports Dictionary, using IE7, the left hand/selected list is wide enough but does not display the names of the selected columns. Admins can add columns to the list and the appropriate columns are added but they do not display except as empty list entries. -- 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.

2 5

[Bug 3145] New: patron templates using poorly named "P" and "C" variables
by bugzilla-daemon＠liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3145 Summary: patron templates using poorly named "P" and "C" variables Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: joe.atzberger(a)liblime.com ReportedBy: galen.charlton(a)liblime.com Estimated Hours: 0.0 As pointed out by Joe, at least two templates, possible more, use template variables "P" and "C" to indicate patron category types. These are poor names, and should be changed to something like patron_category_type_P and patron_category_type_C. -- 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.

2 2

[Bug 3804] New: Implement Search by Purchase Order Number In Acquisitions
by bugzilla-daemon＠kohaorg.ec2.liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3804 Summary: Implement Search by Purchase Order Number In Acquisitions Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: PATCH-Sent Component: Acquisitions AssignedTo: rch(a)liblime.com ReportedBy: colin.campbell(a)ptfs-europe.com Estimated Hours: 0.0 Change sponsored?: Sponsored Allow users to search in acquisitions using Purchase Order Number -- 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