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

[Bug 8761] New: Correct compile time warnings in C4::Circulation
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8761 Priority: P5 - low Change sponsored?: --- Bug ID: 8761 Assignee: gmcharlt(a)gmail.com Summary: Correct compile time warnings in C4::Circulation Severity: minor Classification: Unclassified OS: All Reporter: colin.campbell(a)ptfs-europe.com Hardware: All Status: NEW Version: master Component: Architecture, internals, and plumbing Product: Koha A recent enhancement to C4::Circulation has introduced some ambiguous constructs which on current perls give compile time warnings with perl 5.16.0 or 5.16.1 (I've not tested with older) if you check compilation with perl -wc C4/Circulation.pm you get the following warnings Scalar value @values[$take] better written as $values[$take] at Circulation.pm line 985. Scalar value @alloweddate[0] better written as $alloweddate[0] at Circulation.pm line 991. Scalar value @alloweddate[1] better written as $alloweddate[1] at Circulation.pm line 993. Scalar value @alloweddate[2] better written as $alloweddate[2] at Circulation.pm line 993. Scalar value @alloweddate[2] better written as $alloweddate[2] at Circulation.pm line 994. Heres the doc from perlwarn (W syntax) You've used an array slice (indicated by @) to select a single element of an array. Generally it's better to ask for a scalar value (indicated by $). The difference is that $foo[&bar] always behaves like a scalar, both when assigning to it and when evaluating its argument, while @foo[&bar] behaves like a list when you assign to it, and provides a list context to its subscript, which can do weird things if you're expecting only one subscript. On the other hand, if you were actually hoping to treat the array element as a list, you need to look into how references work, because Perl will not magically convert between scalars and lists for you. See perlref. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 8395] New: order receive not sorting right
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '13

21 Apr '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8395 Priority: P5 - low Change sponsored?: --- Bug ID: 8395 Assignee: koha-bugs(a)lists.koha-community.org Summary: order receive not sorting right Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Acquisitions Product: Koha Created attachment 10722 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10722&action=edit not sorted See the attached image - when I click on the 'Summary' heading to sort things, they are in no order that I can figure out. They should be in alpha order by title since that's the first bit of data in that field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[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