+1 Swapnil for content driven template. Also, like idea to remove redundancy of email templates settings.
-- Thanks & Regards --- Arun Patidar Manager, Enterprise Software Development HotWax Systems Pvt Ltd.www.hotwaxsystems.com On Thu, Aug 17, 2017 at 10:19 AM, Swapnil Mane < swapnil.m...@hotwaxsystems.com> wrote: > Thanks Nicolas for your inputs and sharing more details. This proposed > model is making sense to me. > Please give me some more time to look into the details, will get back to > you in next week. > > Also, please see my comments inline. > > On Tue, Aug 15, 2017 at 1:52 AM, Nicolas Malin <nicolas.ma...@nereide.fr> > wrote: > > > Hello Swapnil, in line > > > > > > Le 14/08/2017 à 04:35, Swapnil Mane a écrit : > > > >> Thank you Nicolas for your inputs and interest. I highly appreciate it. > >> > >> Based on my understanding, please see my comments inline and let me know > >> if > >> you have further inputs. > >> > >> On Fri, Aug 11, 2017 at 3:10 PM, Nicolas Malin < > nicolas.ma...@nereide.fr> > >> wrote: > >> > >> Hello Swapnil, > >>> > >>> In past I tried to refactoring email interface with the idea to : > >>> * deprecate current ProductStoreEmailSetting to link it to > >>> TemplateEmailSetting. The purpose is to centralize all email > >>> configuration > >>> in this entity > >>> > >>> We may have multiple product store and can have different email > templates > >> for them, ProductStoreEmailSetting will allow us to do that. > >> > > My fault, I'm not clear. ProductStoreEmailSetting and > EmailTemplateSetting > > are redundancy, > > I'm in favor to keep all email template information in > > EmailTemplateSetting and use ProductStoreEmailTemplate to link a email > > template to a productStore throw a purpose. > > So we can deprecate all email template fields in ProductStoreEmailSetting > > to centralize all this part in EmailTemplateSetting > > > > +1 > > > > * link TemplateEmailSetting with Content through > >>> TemplateEmailSettingContent and TemplateEmailSettingContentType. This > >>> offert the possibilty to link header, body, footer or some more complex > >>> case like link documents, pdf invoice, order, etc ... > >>> > >>> Having content model with us, the customizable header, footer > >> (decoratorContentId at content level) and other complex case can be > >> handled > >> easily with content model. > >> > > Completely, except for attached file. I agree for rendering the email > > content, but if you want link the file to your email its more easier to > > indicate it on EmailTemplateSetting. > > > > An example, when you send a order confirmation, you want attach to this > > email the the legal notice. We would be link directly the contentId where > > is the legal notice and an other content for the email body. > > > > I guess, this can be achieved by ContentAssoc model, but yes, your proposal > of using TemplateEmailSettingContent and TemplateEmailSettingContentType > is > also looks reasonable to me. > > > > * review all send email function to manage the content rendering > >>> Yes, during the proposed implementation, we were planning to do this as > >>> well. > >>> > >>> But the time has been missed :( > >>> If you are motivate, we can try to revive this idea ? > >>> > >> > >> :-) > >> I would love to hear more about your idea, will it be possible for you > to > >> share more information about this. > >> > > The issue where I started https://issues.apache.org/ > jira/browse/OFBIZ-4333 > > > > Nicolas > > > > > > - Best Regards, > Swapnil M Mane, > www.hotwaxsystems.com > www.hotwax.co >
