Bug 3367 - Overdue Rules not processed for patrons with checkouts more than 90 days overdue.
Summary: Overdue Rules not processed for patrons with checkouts more than 90 days over...
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-26 12:12 UTC by Chris Cormack
Modified: 2024-07-04 20:37 UTC (History)
2 users (show)

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


Attachments

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


---- Reported by rch@liblime.com 2009-06-26 00:12:10 ----

Debarment and overdue notices are both handled by the overdue_notices.pl cron script.  It takes a --max  argument intended to match the default longoverdue.pl length of 90 days, under the assumption that an item will be dissociated with a patron's account when it is marked lost.

A bug in the selection mechanism for overdue_notices.pl, however, causes the script to not process a patron if s/he has any items overdue more than 90 (or $max) days.



---- Additional Comments From joe.atzberger@liblime.com 2009-06-30 06:56:43 ----

This sounds to me like operation as intended.  If you want to supply a max of 99999, does that not work?



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:09 UTC  ---

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

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 rch@liblime.com.
CC member joe.atzberger@liblime.com does not have an account here

Comment 1 Katrin Fischer 2019-05-04 15:04:41 UTC
I am not sure if this is still valid:

These appear to be the relevant lines of code:

 102 =item B<-max>
 103 
 104 Items older than max days are assumed to be handled somewhere else,
 105 probably the F<longoverdues.pl> script. They are therefore ignored by
 106 this program. No notices are sent for them, and they are not added to
 107 any CSV files. Defaults to 90 to match F<longoverdues.pl>.

 499             my $maxdays = (
 500                   $overdue_rules->{ "delay" . ( $i + 1 ) }
 501                 ? $overdue_rules->{ "delay" . ( $i + 1 ) } - 1
 502                 : ($MAX)
 503             );   

So I think if you use triggered and have a delay defined... it would not use MAX?
Comment 2 Katrin Fischer 2023-10-07 20:27:58 UTC
(In reply to Katrin Fischer from comment #1)
> I am not sure if this is still valid:
> 
> These appear to be the relevant lines of code:
> 
>  102 =item B<-max>
>  103 
>  104 Items older than max days are assumed to be handled somewhere else,
>  105 probably the F<longoverdues.pl> script. They are therefore ignored by
>  106 this program. No notices are sent for them, and they are not added to
>  107 any CSV files. Defaults to 90 to match F<longoverdues.pl>.
> 
>  499             my $maxdays = (
>  500                   $overdue_rules->{ "delay" . ( $i + 1 ) }
>  501                 ? $overdue_rules->{ "delay" . ( $i + 1 ) } - 1
>  502                 : ($MAX)
>  503             );   
> 
> So I think if you use triggered and have a delay defined... it would not use
> MAX?


I think MAX is still used with --list-all, but you can use the -max option to overwrite. Closing, please re-open if you disagree.