April 2013 - Koha-bugs - lists.koha-community.org

[Bug 10031] New: runreport.pl has an error
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '13

29 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10031 Bug ID: 10031 Summary: runreport.pl has an error Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Task Scheduler Assignee: gmcharlt(a)gmail.com Reporter: ketan(a)carvingit.com The code that's hashed out is the current code. The lines below that are the lines that should be present instead. A minor typographical error. Following is the output of diff command showing the difference between the original file and the update file - bin/cronjobs/runreport.pl ================================================================= 195,197c195,201 < my $sql => $report->{savedsql}; < my $report_name => $report->{report_name}; < my $type => $report->{type}; --- > #my $sql => $report->{savedsql}; > my $sql = $report->{savedsql}; > #print $sql; > #my $report_name => $report->{report_name}; > my $report_name = $report->{report_name}; > #my $type => $report->{type}; > my $type = $report->{type}; ================================================================= New to koha. Looking for info on submitting a patch myself. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 9033] New: Wide character error in runreport.pl
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '13

29 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9033 Priority: P5 - low Change sponsored?: --- Bug ID: 9033 Assignee: gmcharlt(a)gmail.com Summary: Wide character error in runreport.pl Severity: normal Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Reports Product: Koha runreport.pl is not encoding email correctly. Wide character in subroutine entry at /usr/share/perl5/Mail/Sendmail.pm line 308. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 10151] New: OpacRightSidebar missing from OPAC pref file
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '13

29 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10151 Bug ID: 10151 Summary: OpacRightSidebar missing from OPAC pref file Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org CC: gmcharlt(a)gmail.com The OpacRightSidebar system preference only shows up under "Local use" because it was never added to opac.pref. It should appear under the OPAC tab. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 10147] New: Koha allows for multiple main entries
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '13

29 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10147 Bug ID: 10147 Summary: Koha allows for multiple main entries Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nengard(a)gmail.com CC: m.de.rooy(a)rijksmuseum.nl Koha is letting catalogers enter multiple main entry tags. Only one 1XX tag is permitted according to cataloging rules. It would be nice to have a way to link fields together in the framework and say that 1 is required but that all can't be filled in. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 9842] New: SIP tests : fix for 07hold.t on Cancel Hold
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '13

29 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9842 Bug ID: 9842 Summary: SIP tests : fix for 07hold.t on Cancel Hold Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: SIP2 Assignee: adrien.saurat(a)biblibre.com Reporter: adrien.saurat(a)biblibre.com CC: colin.campbell(a)ptfs-europe.com [MT10401] When running the SIP tests, 07hold.t returns errors. ERROR 1: # Failed test 'match leader Place Hold: valid item (1783B), valid patron (1X981)' # at /home/asaurat/workspace/versions/community/C4/SIP/t/SIPtest.pm line 204. # Response '161N20130318 181053AA1X981|BSVIL|AB1783B|AJL ANGOISSE DU ROI SALOMON|AOVIL|AY3AZEA76' doesn't match pattern '(?-xism:^161Y\d{8} {4}\d{6})' Here, the most important return value is the "1" after "16", indicating a success. And indeed, the hold is correctly recorded in Koha. The following character, indicating the "available" status (and which can be of "Y" or "N" value), is fed by the "available" method in C4/SIP/ILS/Item.pm which is not totally functionnal yet. So, the question is : - should the test gives a OK result by accepting N or Y as long as we get a 161 and not a 160? - should we keep this as it is? (seems safer and cleaner, if we want to respect the SIP protocol the item should be marked as available if it is... I'll go this way and won't touch this in this patch) ERROR 2: # Failed test 'match leader Cancel Hold: valid hold for user (1X981)' # at /home/asaurat/workspace/versions/community/C4/SIP/t/SIPtest.pm line 204. # Response '160N20130318 181054AA1X981|AOVIL|AFNo such hold on patron record.|AY6AZEA73' doesn't match pattern '(?-xism:^161[NY]\d{8} {4}\d{6})' Here, the hold actually exists, but the "No such hold on patron record" result is caused by an error in the perl script of ILS.pm Tests like "unless ($trans->ok)" should be written unless "($trans->ok(1))". ERROR 3: # Failed test 'match leader Cancel hold: cleanup hold for 2nd patron (1X999)' # at /home/asaurat/workspace/versions/community/C4/SIP/t/SIPtest.pm line 204. # Response '160N20130318 181054AA1X999|AOVIL|AFNo such hold on patron record.|AY0AZEA70' doesn't match pattern '(?-xism:^161[NY]\d{8} {4}\d{6})' Same as error 2. I'll thus include a small patch correcting the "No such hold on patron record" problem (ERRORS 2 and 3). For the first error, I don't know how to finish the "available" method so I'll leave it to someone who knows this part better. Maybe can it be assumed that if we get a 161 the following character is automatically Y? After all, this Y or N on availability seems to be a concern only when the hold is refused. Or maybe should we accept both Y and N because it is possible to place a hold on items not yet available? I don't know... TEST PLAN : 1) In "C4/SIP/t", configure the SIPtest.pm file. 2) Configure your SIPconfig.xml if needed. 3) Start your SIP server. 4) In "C4/SIP/t", do a "make test" (see the README file for more informations) -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 8746] New: rebuild_zebra_sliced.sh don't work where Record length of 106041 is larger than the MARC spec allows
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '13

29 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8746 Priority: P5 - low Change sponsored?: --- Bug ID: 8746 Assignee: gmcharlt(a)gmail.com Summary: rebuild_zebra_sliced.sh don't work where Record length of 106041 is larger than the MARC spec allows Severity: major Classification: Unclassified OS: All Reporter: stephane.delaune(a)biblibre.com Hardware: All Status: NEW Version: rel_3_10 Component: Searching Product: Koha rebuild_zebra_sliced.sh don't work where Record length of 106041 is larger than the MARC spec allows -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 10008] New: 'Opened' tab should be 'Open'
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '13

29 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10008 Bug ID: 10008 Summary: 'Opened' tab should be 'Open' Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de After asking native speaker advice I think that the tabs on the serials subscription search page should be labelled "open" and "closed". -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 10142] New: Unclear which issues show on subscription details issues tab
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '13

29 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10142 Bug ID: 10142 Summary: Unclear which issues show on subscription details issues tab Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: colin.campbell(a)ptfs-europe.com I got asked which issues show on the 'Issues' tab in the serials subscription detail page. The number of issues seems random and it's hard to figure out what the pattern here is. Looking at GetSerials I think it is: All issues not arrived, missing or not available (2,4,5) + last 5 issues arrived, missing or not available But the POD states: =head2 GetSerials ($totalissues,@serials) = GetSerials($subscriptionid); this function gets every serial not arrived for a given subscription as well as the number of issues registered in the database (all types) this number is used to see if a subscription can be deleted (=it must have only 1 issue) FIXME: We should return \@serials. =cut So at least there is some mismatch between the POD and what really happens. Also it would be nice if we could do this a bit better. Another point: shouldn't the status include claimed? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 10139] New: add sample MARC files, to Koha codebase
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '13

29 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10139 Bug ID: 10139 Summary: add sample MARC files, to Koha codebase Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: gmcharlt(a)gmail.com Reporter: mtj(a)kohaaloha.com Koha does not currently have a set of MARC data for testing this patch attempts to add a set of MARC files to the Koha codebase -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 9052] New: YUI assets installed in the wrong place by packages
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '13

29 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9052 Priority: P5 - low Change sponsored?: --- Bug ID: 9052 CC: robin(a)catalyst.net.nz Assignee: koha-bugs(a)lists.koha-community.org Summary: YUI assets installed in the wrong place by packages Severity: blocker Classification: Unclassified OS: All Reporter: jcamins(a)cpbibliography.com Hardware: All Status: NEW Version: master Component: Packaging Product: Koha Even though YUI has been moved to opac-tmpl/lib/yui, the packages were installing some of the CSS assets to opac-tmpl/prog/en/yui -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45