Bug 2883 - longoverdue cronjob misleading and buggy, output mangled
Summary: longoverdue cronjob misleading and buggy, output mangled
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: Main
Hardware: PC All
: P3 major (vote)
Assignee: Paul Poulain
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-23 12:55 UTC by Chris Cormack
Modified: 2012-10-26 00:41 UTC (History)
0 users

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:57:33 UTC


---- 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.

Comment 1 Paul Poulain 2011-08-02 13:38:01 UTC
partial fix sent and applied, no more information about what's missing, no patch attached, liblimers are now left.

If you have a problem, please reopen with details, or open another bug