[Koha-bugs] [Bug 2389] overdue_notices.pl needs a test mode

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2389

--- Comment #6 from Barton Chittenden <barton at bywatersolutions.com> ---
(In reply to Katrin Fischer from comment #5)
> (In reply to Barton Chittenden from comment #3)
> > Additional side effect: when run with -t (trigger notices) and -n (no
> > email), no emails are sent, the list of emails rendered is limited to the
> > set that are triggered, but the triggers themselves are not re-set; the next
> > time that overdue_notices.pl is run with the -t option, any notices
> > triggered on the original run are *not* emailed.
> > 
> > This was definitely unexpected behavior.
> 
> I don't think that this behaviour is possible - the triggers are just
> calculations on the due date, there is nothing to be reset in the database?
> 
> I am afraid escalating this from enh to bug won't make it move faster,
> unless someone spends time to implement and test this.
> 
> There is a similar bug about a test mode for notices - bug 8000 - waiting
> for sign-off. But it won't stop it from debarring I think.

It's entirely possible that this was a mis-understanding on my part -- perhaps
I did the second run on a different day.

I read through bug 8000; it doesn't really cover my concerns with
overdue_notices.pl -- the script is old enough that it contains a lot of code
that should by all rights be in a library -- it has complicated internal logic
which queries the circ rules and the issues table to determine how many days
overdue an item is. The fact that I can't run this safely by hand for
trouble-shooting purposes due to documented and possibly un-documented side
effects just makes my job hard.

Furthermore, my understanding (even though I can't find anything on the wiki to
back this up) is that koha command line scripts are *supposed* to not make any
changes to system state unless a '--commit' argument is supplied. I'm not sure
that I want to go that far, simply because that  would break a lot of crontabs,
but in the spirit of that standard, I think that we should at least have an
option to run the script without un-intended consequence.

I'll see if I can make time to add a test-mode switch myself, I definitely did
want to bring this back up for discussion again though, simply because I'm
currently in a position where I'd like to run the script by hand, and am once
again frustrated by the fact that I can't.

-- 
You are receiving this mail because:
You are watching all bug changes.