[Koha-bugs] [Bug 2883] New: longoverdue cronjob misleading and buggy, output mangled

[bugzilla-daemon at pippin.metavore.com]

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2883

           Summary: longoverdue cronjob misleading and buggy, output mangled
           Product: Koha
           Version: HEAD
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P3
         Component: System Administration
        AssignedTo: paul.poulain at free.fr
        ReportedBy: joe.atzberger at liblime.com
         QAContact: koha-bugs at lists.koha.org


There are many problems with the longoverdue report.  

First the example on how to run it is wrong:
  $PERL5LIB/misc/cronjobs/longoverdue.pl --lost 30=2 --lost 60=1 --charge 1

It claims it will set LOST=1 after 30 days, LOST=2 after 60 days, and charge
the account when setting LOST=2 (i.e., 60 days).  But the second set of --lost
options will always be an empty set.

It may be hard to tell, because it produces cluttered output like:

atz at arwen:~/koha/production/koha$ misc/cronjobs/longoverdue.pl --verbose --lost
30=2 --lost 60=1
starting range: 30 - 366 with lost value 2 at misc/cronjobs/longoverdue.pl line
104.
updating 916 for borrower 51 to lost: 2 at misc/cronjobs/longoverdue.pl line
108.
updating 1452 for borrower 53 to lost: 2 at misc/cronjobs/longoverdue.pl line
108.
updating 900 for borrower 33 to lost: 2 at misc/cronjobs/longoverdue.pl line
108.
updating 901 for borrower 33 to lost: 2 at misc/cronjobs/longoverdue.pl line
108.
updating 921 for borrower 33 to lost: 2 at misc/cronjobs/longoverdue.pl line
108.
updating 888 for borrower 33 to lost: 2 at misc/cronjobs/longoverdue.pl line
108.
updating 889 for borrower 34 to lost: 2 at misc/cronjobs/longoverdue.pl line
108.
updating 890 for borrower 36 to lost: 2 at misc/cronjobs/longoverdue.pl line
108.
updating 2213 for borrower 5 to lost: 2 at misc/cronjobs/longoverdue.pl line
108.
updating 238 for borrower 39 to lost: 2 at misc/cronjobs/longoverdue.pl line
108.
updating 196 for borrower 747 to lost: 2 at misc/cronjobs/longoverdue.pl line
108.
starting range: 60 - 30 with lost value 1 at misc/cronjobs/longoverdue.pl line
104.
count :  11 at misc/cronjobs/longoverdue.pl line 124.
range :  30 - 366 at misc/cronjobs/longoverdue.pl line 124.
lostvalue :  2 at misc/cronjobs/longoverdue.pl line 124.
count :  0 at misc/cronjobs/longoverdue.pl line 124.
range :  60 - 30 at misc/cronjobs/longoverdue.pl line 124.
lostvalue :  1 at misc/cronjobs/longoverdue.pl line 124.

========================================================

The use of warn statements instead of print for regular output is not helpful. 
Notice, however, the first range is 30-366 and the second range is 60-30. 
Those values get plugged into the query:

SELECT items.itemnumber,borrowernumber 
FROM issues,items 
WHERE items.itemnumber=issues.itemnumber 
AND DATE_SUB(CURDATE(), INTERVAL ? DAY) >  date_due 
AND DATE_SUB(CURDATE(), INTERVAL ? DAY) <= date_due 
AND itemlost <> ?

To clarify:

mysql> SELECT  DATE_SUB(CURDATE(), INTERVAL 30 DAY) as "30",
DATE_SUB(CURDATE(), INTERVAL 366 DAY) as "366", DATE_SUB(CURDATE(), INTERVAL 60
DAY) as "60";
+------------+------------+------------+
| 30         | 366        | 60         |
+------------+------------+------------+
| 2008-11-23 | 2007-12-23 | 2008-10-24 | 
+------------+------------+------------+
1 row in set (0.00 sec)

So what date_due is ever going to match these criteria:
  2008-11-23 <= date_due < 2008-10-24

None!




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.