[
http://issues.apache.org/jira/browse/OFBIZ-435?page=comments#action_12451860 ]
Si Chen commented on OFBIZ-435:
-------------------------------
This is most of what I had in mind, except:
1. This line:
+ sendMailParams.put("communicationEventId", communicationEventId);
way at the top block would always put in a communicationEventId, and I think it
would make this block moot:
+ if (!
contactList.getString("contactListTypeId").equals("NEWSLETTER")) {
+ sendMailParams.put("communicationEventId",
communicationEventId);
+ }
Also, shouldn't ! be right before the "c"? Or does that not matter?
2. With
contactListCommStatusRecord.getString("statusId").equals("COM_COMPLETE"), it is
better to write as "COM_COMPLETE".equals(...getString('statusId")) in case
there are any null values. Otherwise sooner or later you'd get an NPE
This actually brings up a question: should this service fail when some of the
emails fail? If so, running it as async would cause it to repeat itself over
and over again if some of the email addresses could not be sent.
I think the idea is sound - IN_PROGRESS emails get sent over and over again,
but there should be a max-retry on the service so eventually we'd give up
rather than blow up the server?
3. David -- are you OK with the UtilValidate changes?
> Re-factor and improve email sending to contact lists
> ----------------------------------------------------
>
> Key: OFBIZ-435
> URL: http://issues.apache.org/jira/browse/OFBIZ-435
> Project: OFBiz (The Open for Business Project)
> Issue Type: Improvement
> Components: marketing
> Reporter: Si Chen
> Assigned To: Si Chen
> Attachments: OFBIZ-435_1.patch.zip
>
>
> Re-factor sending of email to contact lists in the following way:
> 1. A separate service will be used to send comm event when there is a
> contactListId on the commevent and the commevent type is "Email".
> 2. The new sendEmailToContactList will not use a global transaction but
> rather will use a separate transaction for each address on the contact list.
> If there is a service error from any particular sendMail, it will skip that
> email and move on.
> 3. UtilValidate.isEmail will be re-factored into two methods, isEmail(String
> email) which just calls isEmail(email, false) and isEmail(String email,
> boolean requireDot) which is the current isEmail code, except that the block
> for checking "." will be turned on if requireDot is true. where requireDot
> will force
> 4. Each email will be cleaned up with a .trim() first and then validated
> using UtilValidate.isEmail(infoString, ".")
> 5. A new entity ContactListCommStatus will be created with keys
> contactListId, commEventId, contactMechId, processedTimestamp to record when
> an email has been sent to a contactMechId. Before any email is sent, we will
> check if there is a not null processedTimestamp for this email address
> (contactMechId) for the commEventId and contactListId. If so, then it will
> no longer be sent. After an email is sent, a record (by direct
> delegator.create to speed things up) will be created in
> ContactListCommStatus. This will make contact lists "transactional" in the
> sense that it can recover in the middle of a list.
> 6. A new field ContactList.logSentCommEvents (indicator) will be created.
> If it is set to "N", then communicationEventId will be passed into the
> sendMail service so that the storeCommEventAsEmail service will not be
> triggered. This will prevent mass marketing emails from being stored for all
> recipients and clogging up the database, while still allowing important
> emails (recall notifications, etc.) to be stored.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
