Hello Swapnil,
Le 25/11/2017 à 09:03, Swapnil Mane a écrit :
Thanks, Nicolas and everyone for sharing your thoughts.
The model we discussed in https://issues.apache.org/jira/browse/OFBIZ-3894
is making perfect sense to me. I guess, we should proceed in small steps to
implement this.
Nice to learn that previous discussion will help you. I will try to
follow your step and if I can help you to implement it.
@Nicolas, the patch provided by you will be really helpful.
P.S. Apologies for the delay in the reply, I was engaged with some other
high priority tasks :-)
No pb, this is also my life :/ ;)
Cheers,
Nicolas
- Best Regards,
Swapnil M Mane
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
