Re: ogo task reminder

> >> - notification time column in the job table
(as compared to the date x 
> >> table for appointments
> > Any schema changes are going to need the blessing
of the PTBs; makes
> > upgrading/updating, packaging, etc... more
complicated.
> I know, and I thought about that, but I decided, just
for consistency, it 
> would make sense to copy the logic how things work from
appointment, would 

I agree that this is the ideal solution (at least IMO)

> be the better idea. As there were no
extendedJobAttributes... which I could 
> have used, as I started. At least I was not aware of
the patch in bugzilla.

I just wonder if, for the sake of getting something sooner,
if a simpler
solution wouldn't work. 

In my understanding tasks have a due *DATE* and not a start
*TIME* like
an appointment.  Would it be sufficient to simply store a
"reminder"
property on the task, and to process the tasks for the day? 
Early in
the day an e-mail could be sent to user(s) concerning what
tasks they
have due in DAY + 1 (Mon - Thu) or TODAY + 3 (Fri).

Or make the property an int, number of days 1, 2, 3, or 4. 
Then you'd
only need to scan the tasks due in the next 4 days - even at
large sites
that shouldn't be more than a few hundred.

In the morning the user could have an e-mail "Your due
tasks" or some
such.

I do something like this with SQL, but with no OGo/WebUI
integration,
you just get the message for all your tasks.  Just making
that optional
would be a huge improvement.

> > Makes sense to me.  I'd image than the adding of
the logic command and
> > the adding of the tool should be separate patches.
 Maybe "skyjobnotify"
> > should be "ogojobnotify".
> yes, I just named it for consistency, maybe renaming
skyaptnotify too?

That would break people's existing crontabs, etc...  so
probably not.

> > > - the e-mail reminder looks like the
following:
> > > Task Notification
> > >   title:        testreminder
> > >   owner:        ogouser
> > >   start-date:   2007-03-11 01:00 (MET)
> > >   end-date:     2007-03-13 01:00 (MET)
> > >   status:       
> > >   sensitivity:  1
> > >   priority:     1
> > >   actual work:  0
> > >   total work:   0
> > > - skyjobnotify leaves a hard coded log entry
in the jobs 
> history "reminder sent"
> > Is this derived from a template or hard-coded?
> This is copied from skyaptnotify, so should work the
same way, with a 
> template definable via a Default.

Cool.

> > > - In the webui, a default reminder preference
can be defined by the user 
> > >in the jobs preferences page
> > What is the name of the default created?
> > > - when creating a job, the user can choose
the reminder time from a 
> > > popup, same
> > > as for  appointment reminders
> > > - when a reminder is set, and not yet sent
out, then it shows up in the 
> > > webui most likely there are bugs in it, but
as far as i tested for now, it 
> > > works, despite still some quirks in the
webui, where the reminder time is not 
> > > shown correctly. maybe improvements:
> > > - reminder could be sent to the creator, if
he is not one of the 
> > > executors
> > Hmmm, I don't know.  Doesn't seem very useful.  I
*assume* the creator
> > has an interest and keeps a better eye on things
than the executant. :
> > > - improved template for the notification,
e.g. including the url link to 
> the
> > > task in ogo.
> > I think including the link is imperative.
> well I need to find out, how to generate the link, and
make it available in 
> the e-mail...
> > > - maybe more...
> > What happens if the executant is a team?
> I have not tested, but I think the same will happen, as
when a team is an 
> appointment participant. I only copied it from
skyaptnotify.

> > >> - notification time column in the job
table (as compared to the date x 
> > >> table for appointments
> > > Any schema changes are going to need the
blessing of the PTBs; makes
> > > upgrading/updating, packaging, etc... more
complicated.
> > I know, and I thought about that, but I decided,
just for consistency, it 
> > would make sense to copy the logic how things work
from appointment, would 
> I agree that this is the ideal solution (at least IMO)
> > be the better idea. As there were no
extendedJobAttributes... which I could 
> > have used, as I started. At least I was not aware
of the patch in bugzilla.
> I just wonder if, for the sake of getting something
sooner, if a simpler
> solution wouldn't work. 
> In my understanding tasks have a due *DATE* and not a
start *TIME* like
> an appointment.  Would it be sufficient to simply store
a "reminder"
> property on the task, and to process the tasks for the
day?  Early in
> the day an e-mail could be sent to user(s) concerning
what tasks they
> have due in DAY + 1 (Mon - Thu) or TODAY + 3 (Fri).
> Or make the property an int, number of days 1, 2, 3, or
4.  Then you'd
> only need to scan the tasks due in the next 4 days -
even at large sites
> that shouldn't be more than a few hundred.
> In the morning the user could have an e-mail "Your
due tasks" or some
> such.
> I do something like this with SQL, but with no
OGo/WebUI integration,
> you just get the message for all your tasks.  Just
making that optional
> would be a huge improvement.

FYI, the query I use is:
WHERE "job_status" NOT IN  ( '25_done',
'30_archived', '02_rejected' ) 
AND is_control_job IS NULL 
AND start_date <  'tomorrow'
AND end_date < 'tomorrow':ATE +
INTERVAL '4 days'