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@free.fr ReportedBy: joe.atzberger@liblime.com QAContact: koha-bugs@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@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.