Hi, I've been able to find some more information by examining the code, but am still unsure on a few items:
JS wrote > 1) If I wanted to effectively "disable" these automatic emails which are > generated from each webapp, is it enough to simply not define that > EmailType in my Product Store, or do I need to hunt down all SECA's and > the like which send these emails and disable them manually? A good example of this is: currently in the order application, there is a SECA on the changeOrderStatus service which will trigger when the order goes to status ORDER_COMPLETED. This SECA will call the sendOrderCompleteNotification service which will send an email to the party who placed the order. It checks the ProductStoreEmailSetting entity to determine if emailTypeId PRDS_ODR_COMPLETE is defined for that store. If not, the service will return a failure. If I do not want this email to trigger, what is the best method for suppressing this? Is it better to not configure the PRDS_ODR_COMPLETE type for my store in ProductStoreEmailSetting entity and let the service fail OR is it better to disable this SECA entirely from secas.xml? Is there a listing (or a quick way for me to identify) all of the services in the framework which automatically send emails so that these can be selectively enabled as needed? JS wrote > 2) Additionally, in order for me to facilitate emails in my custom > application, I plan to: define new EmailTypes, and configure them in my > ProductStore (along with defining the screen). I'm wondering if this is > the preferred approach? It seems that there's a mixture of approaches in the framework applications. For example, the "forgot password" (in LoginEvents) queries the EmailTemplateSetting entity for the appropriate email template to use. Whereas other places use the ProductStoreEmailSetting entity to configure email templates per product store. It appears that the sendMailFromTemplateSetting (which uses EmailTemplateSetting) will not generate the email if no record is found in the entity for the given emailTemplateSettingId. However, for services which utilize the ProductStoreEmailSetting entity, there does not seem to be the same guarantee of: if the template is not defined, an email is not generated. I've seen instances where a service will check ProductStoreEmailSetting and if there's nothing found, it will use a "default" template. According to this thread: http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201107.mbox/%[email protected]%3E and the associated JIRA issue (https://issues.apache.org/jira/browse/OFBIZ-3894) the EmailTemplateSetting entity should be used for these types of things. I will explore this path, unless this approach is no longer recommended? JS wrote > 3) I haven't been able to determine the link between party Communications, > and emails. I noticed that some of the email services will accept a > 'communicationEventId' (though optional), and through various SECA's, will > update the status of the communication once the mail is sent (or not > sent). I see that there are SECA's on the various sendMail* services which will automatically run createCommEventFromEmail when a partyId is specified and no communicationEventId is specified. On the sendMailFromScreen service definition, there is a max-retry of 3 set. If the email fails to send, where does it become queued for retrying? Does it just get put in as a scheduled job? Is there a way to retry the email after hitting the threshold of 3 failures? Thanks -- View this message in context: http://ofbiz.135035.n4.nabble.com/Preferred-Email-Implementation-in-Hot-Deploy-Component-tp4650230p4650274.html Sent from the OFBiz - User mailing list archive at Nabble.com.
