Re: ogo task reminder

> > As an aside I'd like to discuss@ the job notification feature.  If you
> > could post your explanation of the problem/deficiency and the logic of
> > your proposed solution over on discuss@ it would be appreciated.
> ok, lets rock. Above Adam refers to the following ogo enhancement:
> .http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1167
> Enh: If a job is due, but not finished, the user should be notified.
> the patch I added to the report, does not fully what the name says.
> the skyjobnotify tool started out as a copying the functionality of
> skyaptnotify.
> this enables the user to define a job specific reminder time before the due
> date, so that he will receive an e-mail notification, if the reminder date has
> reached.

Which is awesome,  I've wanted this for a long time.  Currently I run an
SQL to get a nice list of nearly due or overdue jobs.

> the tool skyjobnotify should be run from a cron job as its friend skyaptnotify. 
> - the skyjobnotify tool is configured with the Defaults just like skyaptnotify:
>     skyjobnotify = {
>         JobNotifyBeVerbose = NO;
>         JobNotifyCheckPrefix = 600;
>         JobNotifyDefaultTimeZone = MET;
>         JobNotifyFromAddress = "ogo@mydomain";
>         JobNotifySendmailPath = "/usr/sbin/sendmail";
>         JobNotifySendmailToExternal = NO;
>         JobNotifySendpageEnabled = NO;
>         JobNotifySentResourcesFile = "/var/log/opengroupware.org/ogo.log";
>         JobNotifySkyrixPassword = MyPassword;
>         JobNotifySkyrixUser = ogoadmin;
>     };
> - 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.

> - same logic behind the values stored in notification_time as for appointments, 
>   minutes before the end_date of the job which are later compared to the
>   end_date of the 
>   fetched jobs.
> - skyjobnotify mostly relies on commands, runCommand:@"job::get-job-executants, 
>   runCommand:@"person::get-extattrs, job::set, job::get-skyjobnotify-jobs, ...
> - job::get-skyjobnotify-jobs just asks the database for all jobs that are not
> archived or 
>   done and have a notificationTime > 0 set
>   qualifier = [qualifier initWithEntity:[self destinationEntity]
>                            qualifierFormat:
>                               @"(%A <> '%@') AND "
>                               @"(%A <> '%@') AND "
>                               @"(%A > 0)",
>                               @"jobStatus", LSJobArchived,
>                               @"jobStatus", LSJobDone,
>                               @"notificationTime", nil];
> - skyjobnotify only checks for the mails (email, email1, email2) of the executer
> of the job, and sends the notification out to these addresses

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

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

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

> - maybe more...

What happens if the executant is a team?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBF+VYmLRePpNle04MRAhk/AJ0YyZSMOPMSdkc0jcG7B7VoBaOVUQCePECO
uvug+CEfYnIZIMdZEep5tE4=
=yQYT
-----END PGP SIGNATURE-----