Re: Due date email notification

"Jorge Uriarte Aretxaga" <[email protected]> Tue, 12 Aug 2008 10:32:08 +0200
Newsgroups gmane.comp.java.scarab.user
Message-ID <[email protected]>
If I'm getting it right, you're trying to implement a behaviour in some
fields so the system is able to routinely check (in the background) some
condition on them and report. In your case the condition is simple, as easy
as "has this date value finally come?".

In the apporach you're probably thinking about, you'll need to check some
flag in a date field so it's marked as "to be notified".
You might want to use this at the attribute_type level, or in the
issue_type_attribute (checking it when defining the issue type).
Using this info, when recording issues' real values (in attribute_value),
you'd need to mark in some place that the attribute is 'to be notified', so
you'd probably need still another field to hold that.

In parallel, you'd add a new Job to the planification service (quartz). This
Job will be responsible of routinely query the system for pending
notifications, and then triggering the email. Take a look at the classes in
org.tigris.scarab.notification, because they implement both the planificated
Job and the email sending for the notification manager. Ask here (or better,
in dev's) for any information on how do that system works.

Another possible approach (more decoupled): The admin  would get a
management screen in which to mantain which "module->issue_type->attributes"
wants to have under constant control, and what condition would every one be
checked against. Initially, you can just restrict this to 'date' attributes,
and the condition internally be hardcoded to 'date >= currentdate'. This
data would be stored in a new table.

You'll then intercept current recordissue system to check against the new
table, and you'll create/update a record for each changed one, with a
structure like 'issue_id | attribute_id | status'.
'status' might be 'pending => tobenotified => notified'.

Every change in one of the 'controlled' attributes will update this info to
'pending' (this is just a call to be placed in a very central part of
Scarab, and probably the only point of possible code-conflict with future
upgrades => easy to manage).

You'll also need a Job that routinely checks for 'pending' records, and then
checks the condition for that values. If the condition is true, you'll
update the 'pending' flag to 'tobenotified'.
Then, you'll search for every 'tobenotified' to send the notifications to
the associated users. If it goes ok, you'll check the 'notified' flag.
(you might as well implement two different jobs, one to evaluate conditions
to 'tobenotified', and another one to check for 'tobenotified' and send the
emails).

Just a draft, and probably not so correct, but might help you to think about
it...

_
Jorge


On Tue, Aug 12, 2008 at 7:15 AM, FRED.YY.LIN ???
<[email protected]>wrote:

>
> We are thinking of creating a due date notification capability on the
> scarab.
>
> It comes to mind that we need to modify the database table to record if a
> date attribute has a notification request checked.
>
> The other modification will be to record how long before shall a email
> notification be sent e.g. 1,2,3 date or 1 week, two week or even to assign a
> calendar date.
>
> However, if scarab has a new revision, this database table change would
> need  to be migrated into the future release with lots of effort.
>
> Are there existing properties or any files I can use to record these due
> date information?
>
>
> Fred
>
>
> *************************************************************************************************************************
> This email message, including any attachments, is for the sole use of the
> intended recipient(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please contact the sender
> by reply e-mail and destroy all copies of the original message. [Delta
> Electronic, INC. Taiwan]
>
> *************************************************************************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>


-- 
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte