---- Reported by joe.atzberger@liblime.com 2008-12-23 12:55:04 ----

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@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!



---- Additional Comments From joe.atzberger@liblime.com 2008-12-29 10:11:27 ----

Partial fix patch sent.



---- Additional Comments From gmcharlt@gmail.com 2009-03-05 08:33:36 ----

Partial fix patch pushed to head.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:57 UTC  ---

This bug was previously known as _bug_ 2883 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2883

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was joe.atzberger@liblime.com.