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

[Bug 8408] New: Odd OPAC message when OPAC Renewals are disabled and OPACFineNoRenewals is set to blank
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8408 Priority: P5 - low Change sponsored?: --- Bug ID: 8408 Assignee: oleonard(a)myacpl.org Summary: Odd OPAC message when OPAC Renewals are disabled and OPACFineNoRenewals is set to blank Severity: enhancement Classification: Unclassified OS: All Reporter: kyle.m.hall(a)gmail.com Hardware: All Status: NEW Version: master Component: OPAC Product: Koha If OpacRenewalAllowed is set to "Don't allow" and OPACFineNoRenewals is set to blank ( i.e. disabled ). A user who owes any fines, when logged in to the OPAC will receive the following message: Please note: You have more than 0.00 in fines. This is a rather odd message, and is not very sensible. The message should either be modified or removed altogether. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 4870] New: Damaged status does not prevent items from being selected for reserves
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4870 Summary: Damaged status does not prevent items from being selected for reserves Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 Damaged status on items (952$4) seems to allow items to be selected for reserve. This happens both when the barcode is checked in and when the hold queue report is generated. Preferred behavior (open for discussion, of course) would be for damaged status to disallow reserves on items marked "Damaged," similar to items with a "Missing" status (though missing clears the status on checkin, we would NOT want that behavior for Damaged. It should be a manual status change). -- 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 16

[Bug 8486] New: Critical error in Koha::Calendar::days_between ?
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8486 Priority: P5 - low Change sponsored?: --- Bug ID: 8486 Assignee: colin.campbell(a)ptfs-europe.com Blocks: 7420, 8251 Summary: Critical error in Koha::Calendar::days_between ? Severity: blocker Classification: Unclassified OS: All Reporter: paul.poulain(a)biblibre.com Hardware: All Status: ASSIGNED Version: master Component: Architecture, internals, and plumbing Product: Koha My setup has syspref finesCalendar set "Use Calendar to skip all days the library is closed". I made the small following script: #!/usr/bin/perl use Koha::Calendar; use Koha::DateUtils; use 5.010; my $calendar = Koha::Calendar->new( branchcode => 'MAURES' ); say "Test 1=".$calendar->days_between(dt_from_string("2012-01-10") , dt_from_string("2012-05-05") )->in_units('days'); say "Test 2=".$calendar->days_between(dt_from_string("2012-05-05") , dt_from_string("2012-01-01") )->in_units('days'); The result I get is: ./test_calendar.pl DURATION : $VAR1 = bless( { 'seconds' => 0, 'minutes' => 0, 'end_of_month' => 'wrap', 'nanoseconds' => 0, 'days' => 26, 'months' => 3 }, 'DateTime::Duration' ); Test 1=26 DURATION : $VAR1 = bless( { 'seconds' => 0, 'minutes' => 0, 'end_of_month' => 'preserve', 'nanoseconds' => 0, 'days' => -4, 'months' => -4 }, 'DateTime::Duration' ); Test 2=-4 (the DURATION line comes from a warn I put in days_between Whatever the month, I always get the same result. Digging into documentation, I found this: $ perldoc DateTime::Duration · in_units( ... ) Returns the length of the duration in the units (any of those that can be passed to new) given as arguments. All lengths are integral, but may be negative. Smaller units are computed from what remains after taking away the larger units given, so for example: my $dur = DateTime::Duration->new( years => 1, months => 15 ); $dur->in_units( 'years' ); # 2 $dur->in_units( 'months' ); # 27 $dur->in_units( 'years', 'months' ); # (2, 3) $dur->in_units( 'weeks', 'days' ); # (0, 0) ! The last example demonstrates that there will not be any conversion between units which don't have a fixed conversion rate. The only conversions possible are: · years <=> months · weeks <=> days · hours <=> minutes · seconds <=> nanoseconds For the explanation of why this is the case, please see the How Datetime Math Works section of the DateTime.pm documentation CONCLUSION = the days_between() sub is doing a completely wrong calculation. I think we should to a date1-date2 to get a number of days, then remove all closed days. 2012-07-01 to 2012-07-15 is 14 (days) 2012-07-06 closed => 13 (days) 2012-07-07 closed => 12 (days) This problem is probably the real cause of bug 8251 and the trouble I get to test bug 7420 Colin, I've assigned this bug to you because you're Koha::Calendar initial author. Anyone is welcomed to confirm and provide a fix. What is really missing is a test plan. With a strong one, we would have detected the problem before -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 8479] New: Opac Holds being created with priority set to NULL
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8479 Priority: P5 - low Change sponsored?: --- Bug ID: 8479 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Opac Holds being created with priority set to NULL Severity: normal Classification: Unclassified OS: All Reporter: colin.campbell(a)ptfs-europe.com Hardware: All Status: NEW Version: unspecified Component: Hold requests Product: Koha As part of the patch introduced by bug 7398 the calculation of priority is governed by the display option. However the if the rank is not calculated because you have not opted to display it undef is passed to AddReserve and holds are not being picked up by subsequent pull lists -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 8607] New: overdue_notices is broken
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8607 Priority: P5 - low Change sponsored?: --- Bug ID: 8607 Assignee: koha-bugs(a)lists.koha-community.org Summary: overdue_notices is broken Severity: enhancement Classification: Unclassified OS: All Reporter: jonathan.druart(a)biblibre.com Hardware: All Status: NEW Version: unspecified Component: Notices Product: Koha Bug 7447 introduces a critical bug in overdue_notices.pl The script is unusable. The variable $date is not replaced with its content. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 6034] New: Shelving cart feature can wipe permanent shelving location in certain circumstances
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6034 Bug #: 6034 Summary: Shelving cart feature can wipe permanent shelving location in certain circumstances Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: jwagner(a)ptfs.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com We have found that the shelving cart feature added in Bug 3481 can wipe the permanent shelving location in a certain combination of circumstances, particularly if the In Processing part of the feature is not used. Patch is coming. -- 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 12

[Bug 8427] New: Patron search results not consistent
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8427 Priority: P5 - low Change sponsored?: --- Bug ID: 8427 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Patron search results not consistent Severity: enhancement Classification: Unclassified OS: All Reporter: kyle.m.hall(a)gmail.com Hardware: All Status: NEW Version: master Component: Patrons Product: Koha Using the patron search from mainpage.pl will give one search results that are ordered by surname, then firstname. This is totally logical. However, the same search from members-home.pl ( or any page using patron-search.inc ) has the results sorted by surname only, with the firstname ordering being essentially random ( in reality, the firstname order is the order in which they were entered into the database ). To me, it does not make sense that two default patron searches should give different sets of results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 8470] New: remove depreciated H:T:P test file
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8470 Priority: P5 - low Change sponsored?: --- Bug ID: 8470 Assignee: gmcharlt(a)gmail.com Summary: remove depreciated H:T:P test file Severity: major Classification: Unclassified OS: All Reporter: mtj(a)kohaaloha.com Hardware: All Status: NEW Version: master Component: Test Suite Product: Koha remove depreciated H:T:P test file -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 7889] New: Use standard style for errors and messages
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7889 Priority: P5 - low Change sponsored?: --- Bug ID: 7889 Assignee: oleonard(a)myacpl.org Blocks: 7884 Summary: Use standard style for errors and messages QA Contact: koha.sekjal(a)gmail.com Severity: minor Classification: Unclassified OS: All Reporter: oleonard(a)myacpl.org Hardware: All Status: NEW Version: master Component: Templates Product: Koha When displaying in-page errors or messages to the user a standard style should be used. Errors, alerts, or other messages which indicate failures, warnings, or other high-priority information should use: <div class="dialog alert"> ...error... </div> Informational messages should use: <div class="dialog message"> ...message... </div> -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 8463] New: t_00_testcritic_t.Test::Perl::Critic for "Koha/SearchEngine/Solr/Search.pm"
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '13

20 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8463 Priority: P5 - low Change sponsored?: --- Bug ID: 8463 Assignee: gmcharlt(a)gmail.com Summary: t_00_testcritic_t.Test::Perl::Critic for "Koha/SearchEngine/Solr/Search.pm" Severity: major Classification: Unclassified OS: All Reporter: mtj(a)kohaaloha.com Hardware: All Status: NEW Version: master Component: Architecture, internals, and plumbing Product: Koha Koha/SearchEngine/Solr/Search.pm fails perlcritic test -- You are receiving this mail because: You are watching all bug changes.

1 10