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