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

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

[Bug 3803] New: Show PO Number and ISSN in orderline of basket display
by bugzilla-daemon＠kohaorg.ec2.liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3803 Summary: Show PO Number and ISSN in orderline of basket display Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: rch(a)liblime.com ReportedBy: colin.campbell(a)ptfs-europe.com Estimated Hours: 0.0 Change sponsored?: Sponsored Show the Purchase Order Number in the order line of the basket display Also show the ISSN if present in addition to the ISBN to accomodate serials orders The feature sponsored by the Food and Agriculture Organisation of the United Nations -- 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 8

[Bug 3577] New: Barcode.pl does not cater variable length branch codes in hbyymmincr format
by bugzilla-daemon＠kohaorg.ec2.liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3577 Summary: Barcode.pl does not cater variable length branch codes in hbyymmincr format Product: Koha Version: unspecified Platform: PC OS/Version: Linux - Debian Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: rch(a)liblime.com ReportedBy: mwilson(a)globaladvisors.biz Estimated Hours: 0.0 Change sponsored?: --- The Barcode.pl script attempts to auto-increment the barcode by isolating the maximum barcode in the item database. It does this by isolating the last four numerals of the barcodes and choosing the maximum value. The problem is that the SELECT query assumes a two letter branch code. If the branch code varies, the SELECT query fails to isolate the correct portion of the branch code. It therefore incorrectly maximises and the increment is wrong causing duplicate barcodes. The exact line is: $query = "SELECT MAX(CAST(SUBSTRING(barcode,7,4) AS signed)) FROM items WHERE barcode REGEXP ?"; The solution would be to limit branch codes to two letters or to isolate only the last four numerals of the barcode string before maximising. Incidently, surely this also limits the barcode to 9999 items? -- 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 3422] New: purchase suggestions: acceptorreject.pl uses hard-coded templates instead of the new messaging module.
by bugzilla-daemon＠liblime.com 14 May '10

14 May '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3422 Summary: purchase suggestions: acceptorreject.pl uses hard-coded templates instead of the new messaging module. Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: rch(a)liblime.com ReportedBy: rch(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- Patron notification of purchase suggestion response should use the newer messaging system, allowing templates to be created in the notices interface. Currently the message template is stored in a .tmpl file in intranet-tmpl, and messages aren't queued. -- 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 6