[Proposal] - Leverage the CMS capability for Product Store's Email

[Swapnil Mane]

Hello Devs,

While looking into the support of email templates for Product Store, we
found it is managed by screens.

Like for Order Completion

<ProductStoreEmailSetting
bodyScreenLocation="component://ecommerce/widget/EmailOrderScreens.xml#OrderCompleteNotice"
emailType="PRDS_ODR_COMPLETE" fromAddress="[hidden email]"
productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
#${orderId}"/>

Here you can see, we are having dependency on screens (i.e. templates
defined in file system)
Due to this, the user is unable to edit the email template on the fly.

We can enhance this mechanism by making the template as content driven.
Here is the design plan,

We can extend the ProductStoreEmailSetting entity by contentId field.
While rendering email based on its type, if the contentId is present, this
content will render, else system will look for bodyScreenLocation (our
existing implementation)

Using this we can leverage the CMS capability of the OFBiz.
Right now if end user (client) wants to make any change in the email
template, it required the changes in the file.
If we manage this by content, the user can edit this on the fly with the
help of CMS.

All the inputs and suggestions are welcome!


- Best Regards,
Swapnil M Mane
www.hotwaxsystems.com
www.hotwax.co

[Pierre Smits]

Hi Swapnil,

Great idea!

Best regards,


Pierre

On Fri, 11 Aug 2017 at 08:01 Swapnil Mane <[hidden email]>
wrote:

> Hello Devs,
>
> While looking into the support of email templates for Product Store, we
> found it is managed by screens.
>
> Like for Order Completion
>
> <ProductStoreEmailSetting
>
> bodyScreenLocation="component://ecommerce/widget/EmailOrderScreens.xml#OrderCompleteNotice"
> emailType="PRDS_ODR_COMPLETE" fromAddress="[hidden email]"
> productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
> #${orderId}"/>
>
> Here you can see, we are having dependency on screens (i.e. templates
> defined in file system)
> Due to this, the user is unable to edit the email template on the fly.
>
> We can enhance this mechanism by making the template as content driven.
> Here is the design plan,
>
> We can extend the ProductStoreEmailSetting entity by contentId field.
> While rendering email based on its type, if the contentId is present, this
> content will render, else system will look for bodyScreenLocation (our
> existing implementation)
>
> Using this we can leverage the CMS capability of the OFBiz.
> Right now if end user (client) wants to make any change in the email
> template, it required the changes in the file.
> If we manage this by content, the user can edit this on the fly with the
> help of CMS.
>
> All the inputs and suggestions are welcome!
>
>
> - Best Regards,
> Swapnil M Mane
> www.hotwaxsystems.com
> www.hotwax.co
>

--
Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

[Jacques Le Roux]

+1

Jacques


Le 11/08/2017 à 08:29, Pierre Smits a écrit :

> Hi Swapnil,
>
> Great idea!
>
> Best regards,
>
>
> Pierre
>
> On Fri, 11 Aug 2017 at 08:01 Swapnil Mane <[hidden email]>
> wrote:
>
>> Hello Devs,
>>
>> While looking into the support of email templates for Product Store, we
>> found it is managed by screens.
>>
>> Like for Order Completion
>>
>> <ProductStoreEmailSetting
>>
>> bodyScreenLocation="component://ecommerce/widget/EmailOrderScreens.xml#OrderCompleteNotice"
>> emailType="PRDS_ODR_COMPLETE" fromAddress="[hidden email]"
>> productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
>> #${orderId}"/>
>>
>> Here you can see, we are having dependency on screens (i.e. templates
>> defined in file system)
>> Due to this, the user is unable to edit the email template on the fly.
>>
>> We can enhance this mechanism by making the template as content driven.
>> Here is the design plan,
>>
>> We can extend the ProductStoreEmailSetting entity by contentId field.
>> While rendering email based on its type, if the contentId is present, this
>> content will render, else system will look for bodyScreenLocation (our
>> existing implementation)
>>
>> Using this we can leverage the CMS capability of the OFBiz.
>> Right now if end user (client) wants to make any change in the email
>> template, it required the changes in the file.
>> If we manage this by content, the user can edit this on the fly with the
>> help of CMS.
>>
>> All the inputs and suggestions are welcome!
>>
>>
>> - Best Regards,
>> Swapnil M Mane
>> www.hotwaxsystems.com
>> www.hotwax.co
>>

[Michael Brohl-3]

Hi Swapnil,

you can achieve this by just putting something like:

<@renderSubContentCache subContentId="${yourContentId!}"/>

in your template file for the corresponding screen and edit the content
like you proposed.

This solution does not support the fallback mechanism you proposed but
does not require any code changes.

Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de



Am 11.08.17 um 08:01 schrieb Swapnil Mane:

> Hello Devs,
>
> While looking into the support of email templates for Product Store, we
> found it is managed by screens.
>
> Like for Order Completion
>
> <ProductStoreEmailSetting
> bodyScreenLocation="component://ecommerce/widget/EmailOrderScreens.xml#OrderCompleteNotice"
> emailType="PRDS_ODR_COMPLETE" fromAddress="[hidden email]"
> productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
> #${orderId}"/>
>
> Here you can see, we are having dependency on screens (i.e. templates
> defined in file system)
> Due to this, the user is unable to edit the email template on the fly.
>
> We can enhance this mechanism by making the template as content driven.
> Here is the design plan,
>
> We can extend the ProductStoreEmailSetting entity by contentId field.
> While rendering email based on its type, if the contentId is present, this
> content will render, else system will look for bodyScreenLocation (our
> existing implementation)
>
> Using this we can leverage the CMS capability of the OFBiz.
> Right now if end user (client) wants to make any change in the email
> template, it required the changes in the file.
> If we manage this by content, the user can edit this on the fly with the
> help of CMS.
>
> All the inputs and suggestions are welcome!
>
>
> - Best Regards,
> Swapnil M Mane
> www.hotwaxsystems.com
> www.hotwax.co
>

[Vaibhav Jain]

+1 Swapnil

Thanks & Regards
Vaibhav Jain
Hotwax Systems,
[hidden email]

On Fri, Aug 11, 2017 at 11:31 AM, Swapnil Mane <
[hidden email]> wrote:

> Hello Devs,
>
> While looking into the support of email templates for Product Store, we
> found it is managed by screens.
>
> Like for Order Completion
>
> <ProductStoreEmailSetting
> bodyScreenLocation="component://ecommerce/widget/EmailOrderScreens.xml#
> OrderCompleteNotice"
> emailType="PRDS_ODR_COMPLETE" fromAddress="[hidden email]"
> productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
> #${orderId}"/>
>
> Here you can see, we are having dependency on screens (i.e. templates
> defined in file system)
> Due to this, the user is unable to edit the email template on the fly.
>
> We can enhance this mechanism by making the template as content driven.
> Here is the design plan,
>
> We can extend the ProductStoreEmailSetting entity by contentId field.
> While rendering email based on its type, if the contentId is present, this
> content will render, else system will look for bodyScreenLocation (our
> existing implementation)
>
> Using this we can leverage the CMS capability of the OFBiz.
> Right now if end user (client) wants to make any change in the email
> template, it required the changes in the file.
> If we manage this by content, the user can edit this on the fly with the
> help of CMS.
>
> All the inputs and suggestions are welcome!
>
>
> - Best Regards,
> Swapnil M Mane
> www.hotwaxsystems.com
> www.hotwax.co
>

[Nicolas Malin-2]

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
* 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 ...
* review all send email function to manage the content rendering

But the time has been missed :(
If you are motivate, we can try to revive this idea ?

Nicolas

Le 11/08/2017 à 08:01, Swapnil Mane a écrit :

> Hello Devs,
>
> While looking into the support of email templates for Product Store, we
> found it is managed by screens.
>
> Like for Order Completion
>
> <ProductStoreEmailSetting
> bodyScreenLocation="component://ecommerce/widget/EmailOrderScreens.xml#OrderCompleteNotice"
> emailType="PRDS_ODR_COMPLETE" fromAddress="[hidden email]"
> productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
> #${orderId}"/>
>
> Here you can see, we are having dependency on screens (i.e. templates
> defined in file system)
> Due to this, the user is unable to edit the email template on the fly.
>
> We can enhance this mechanism by making the template as content driven.
> Here is the design plan,
>
> We can extend the ProductStoreEmailSetting entity by contentId field.
> While rendering email based on its type, if the contentId is present, this
> content will render, else system will look for bodyScreenLocation (our
> existing implementation)
>
> Using this we can leverage the CMS capability of the OFBiz.
> Right now if end user (client) wants to make any change in the email
> template, it required the changes in the file.
> If we manage this by content, the user can edit this on the fly with the
> help of CMS.
>
> All the inputs and suggestions are welcome!
>
>
> - Best Regards,
> Swapnil M Mane
> www.hotwaxsystems.com
> www.hotwax.co
>

[Swapnil Mane]

Thank you so much Michael for your input and suggestion :)

This will work, but I still feel suggested proposal could be a good
improvement we can have OOTB.
What do you say.

On Fri, Aug 11, 2017 at 1:11 PM, Michael Brohl <[hidden email]>
wrote:

> Hi Swapnil,
>
> you can achieve this by just putting something like:
>
> <@renderSubContentCache subContentId="${yourContentId!}"/>
>
> in your template file for the corresponding screen and edit the content
> like you proposed.
>
> This solution does not support the fallback mechanism you proposed but
> does not require any code changes.
>
>

We have explored the code base, the implementation on contentId at
ProductStoreEmailSetting, will not required heavy code changes.

> Best regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
>
>
> Am 11.08.17 um 08:01 schrieb Swapnil Mane:
>
> Hello Devs,
>>
>> While looking into the support of email templates for Product Store, we
>> found it is managed by screens.
>>
>> Like for Order Completion
>>
>> <ProductStoreEmailSetting
>> bodyScreenLocation="component://ecommerce/widget/EmailOrderS
>> creens.xml#OrderCompleteNotice"
>> emailType="PRDS_ODR_COMPLETE" fromAddress="[hidden email]"
>> productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
>> #${orderId}"/>
>>
>> Here you can see, we are having dependency on screens (i.e. templates
>> defined in file system)
>> Due to this, the user is unable to edit the email template on the fly.
>>
>> We can enhance this mechanism by making the template as content driven.
>> Here is the design plan,
>>
>> We can extend the ProductStoreEmailSetting entity by contentId field.
>> While rendering email based on its type, if the contentId is present, this
>> content will render, else system will look for bodyScreenLocation (our
>> existing implementation)
>>
>> Using this we can leverage the CMS capability of the OFBiz.
>> Right now if end user (client) wants to make any change in the email
>> template, it required the changes in the file.
>> If we manage this by content, the user can edit this on the fly with the
>> help of CMS.
>>
>> All the inputs and suggestions are welcome!
>>
>>
>> - Best Regards,
>> Swapnil M Mane
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>>
>
>

- Best Regards,
Swapnil M Mane,
www.hotwaxsystems.com
www.hotwax.co

[Swapnil Mane]

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 <[hidden email]>
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.


> * 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.


> * 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.

> Nicolas
>
>
> Le 11/08/2017 à 08:01, Swapnil Mane a écrit :
>
>> Hello Devs,
>>
>> While looking into the support of email templates for Product Store, we
>> found it is managed by screens.
>>
>> Like for Order Completion
>>
>> <ProductStoreEmailSetting
>> bodyScreenLocation="component://ecommerce/widget/EmailOrderS
>> creens.xml#OrderCompleteNotice"
>> emailType="PRDS_ODR_COMPLETE" fromAddress="[hidden email]"
>> productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
>> #${orderId}"/>
>>
>> Here you can see, we are having dependency on screens (i.e. templates
>> defined in file system)
>> Due to this, the user is unable to edit the email template on the fly.
>>
>> We can enhance this mechanism by making the template as content driven.
>> Here is the design plan,
>>
>> We can extend the ProductStoreEmailSetting entity by contentId field.
>> While rendering email based on its type, if the contentId is present, this
>> content will render, else system will look for bodyScreenLocation (our
>> existing implementation)
>>
>> Using this we can leverage the CMS capability of the OFBiz.
>> Right now if end user (client) wants to make any change in the email
>> template, it required the changes in the file.
>> If we manage this by content, the user can edit this on the fly with the
>> help of CMS.
>>
>> All the inputs and suggestions are welcome!
>>
>>
>> - Best Regards,
>> Swapnil M Mane
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>>
>

- Best Regards,
Swapnil M Mane
www.hotwaxsystems.com
www.hotwax.co

[Swapnil Mane]

Thanks Pierre, Jacques and Vaibhav for looking into the proposal and
approval :-)



- Best Regards,
Swapnil M Mane,
www.hotwaxsystems.com
www.hotwax.co

On Fri, Aug 11, 2017 at 2:46 PM, Vaibhav Jain <
[hidden email]> wrote:

> +1 Swapnil
>
> Thanks & Regards
> Vaibhav Jain
> Hotwax Systems,
> [hidden email]
>
> On Fri, Aug 11, 2017 at 11:31 AM, Swapnil Mane <
> [hidden email]> wrote:
>
>> Hello Devs,
>>
>> While looking into the support of email templates for Product Store, we
>> found it is managed by screens.
>>
>> Like for Order Completion
>>
>> <ProductStoreEmailSetting
>> bodyScreenLocation="component://ecommerce/widget/EmailOrderS
>> creens.xml#OrderCompleteNotice"
>> emailType="PRDS_ODR_COMPLETE" fromAddress="[hidden email]"
>> productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
>> #${orderId}"/>
>>
>> Here you can see, we are having dependency on screens (i.e. templates
>> defined in file system)
>> Due to this, the user is unable to edit the email template on the fly.
>>
>> We can enhance this mechanism by making the template as content driven.
>> Here is the design plan,
>>
>> We can extend the ProductStoreEmailSetting entity by contentId field.
>> While rendering email based on its type, if the contentId is present, this
>> content will render, else system will look for bodyScreenLocation (our
>> existing implementation)
>>
>> Using this we can leverage the CMS capability of the OFBiz.
>> Right now if end user (client) wants to make any change in the email
>> template, it required the changes in the file.
>> If we manage this by content, the user can edit this on the fly with the
>> help of CMS.
>>
>> All the inputs and suggestions are welcome!
>>
>>
>> - Best Regards,
>> Swapnil M Mane
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>
>

[Pranay Pandey-3]

Good idea +1.

Best regards,
Pranay Pandey
www.hotwaxsystems.com
www.hotwax.co

On Fri, Aug 11, 2017 at 11:31 AM, Swapnil Mane <
[hidden email]> wrote:

> Hello Devs,
>
> While looking into the support of email templates for Product Store, we
> found it is managed by screens.
>
> Like for Order Completion
>
> <ProductStoreEmailSetting
> bodyScreenLocation="component://ecommerce/widget/EmailOrderScreens.xml#
> OrderCompleteNotice"
> emailType="PRDS_ODR_COMPLETE" fromAddress="[hidden email]"
> productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
> #${orderId}"/>
>
> Here you can see, we are having dependency on screens (i.e. templates
> defined in file system)
> Due to this, the user is unable to edit the email template on the fly.
>
> We can enhance this mechanism by making the template as content driven.
> Here is the design plan,
>
> We can extend the ProductStoreEmailSetting entity by contentId field.
> While rendering email based on its type, if the contentId is present, this
> content will render, else system will look for bodyScreenLocation (our
> existing implementation)
>
> Using this we can leverage the CMS capability of the OFBiz.
> Right now if end user (client) wants to make any change in the email
> template, it required the changes in the file.
> If we manage this by content, the user can edit this on the fly with the
> help of CMS.
>
> All the inputs and suggestions are welcome!
>
>
> - Best Regards,
> Swapnil M Mane
> www.hotwaxsystems.com
> www.hotwax.co
>

[Nicolas Malin-2]

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 <[hidden email]>
> 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
>> * 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.

>> * 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

[Swapnil Mane]

Thanks Pranay!


- Best Regards,
Swapnil M Mane

On Mon, Aug 14, 2017 at 12:52 PM, Pranay Pandey <
[hidden email]> wrote:

> Good idea +1.
>
> Best regards,
> Pranay Pandey
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Fri, Aug 11, 2017 at 11:31 AM, Swapnil Mane <
> [hidden email]> wrote:
>
>> Hello Devs,
>>
>> While looking into the support of email templates for Product Store, we
>> found it is managed by screens.
>>
>> Like for Order Completion
>>
>> <ProductStoreEmailSetting
>> bodyScreenLocation="component://ecommerce/widget/EmailOrderS
>> creens.xml#OrderCompleteNotice"
>> emailType="PRDS_ODR_COMPLETE" fromAddress="[hidden email]"
>> productStoreId="9000" subject="OFBiz Demo - Your Order Is Complete
>> #${orderId}"/>
>>
>> Here you can see, we are having dependency on screens (i.e. templates
>> defined in file system)
>> Due to this, the user is unable to edit the email template on the fly.
>>
>> We can enhance this mechanism by making the template as content driven.
>> Here is the design plan,
>>
>> We can extend the ProductStoreEmailSetting entity by contentId field.
>> While rendering email based on its type, if the contentId is present, this
>> content will render, else system will look for bodyScreenLocation (our
>> existing implementation)
>>
>> Using this we can leverage the CMS capability of the OFBiz.
>> Right now if end user (client) wants to make any change in the email
>> template, it required the changes in the file.
>> If we manage this by content, the user can edit this on the fly with the
>> help of CMS.
>>
>> All the inputs and suggestions are welcome!
>>
>>
>> - Best Regards,
>> Swapnil M Mane
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>
>

[Swapnil Mane]

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 <[hidden email]>
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 <[hidden email]>
>> 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

[Arun Patidar-2]

+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 <
[hidden email]> 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 <[hidden email]>
> 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 <
> [hidden email]>
> >> 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
>

[Aditya Sharma]

+1

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems <http://www.hotwaxsystems.com/>
<https://www.linkedin.com/in/aditya-sharma-78291810a/>

On Thu, Aug 17, 2017 at 10:39 AM, Arun Patidar <
[hidden email]> wrote:

> +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 <
> [hidden email]> 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 <[hidden email]
> >
> > 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 <
> > [hidden email]>
> > >> 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
> >
>

[Marek Mosiewicz]

17.08.2017 10:56 "Aditya Sharma" <[hidden email]>
napisał(a):

> +1
>
> Thanks and Regards,
>
> *Aditya Sharma* | Enterprise Software Engineer
> HotWax Systems <http://www.hotwaxsystems.com/>
> <https://www.linkedin.com/in/aditya-sharma-78291810a/>
>
> On Thu, Aug 17, 2017 at 10:39 AM, Arun Patidar <
> [hidden email]> wrote:
>
> > +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 <
> > [hidden email]> 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 <
> [hidden email]
> > >
> > > 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 <
> > > [hidden email]>
> > > >> 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 TemplateEmailSettingContentTyp
> e
> > > 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
> > >
> >
>

[Renuka Srishti]

+1 Swapnil

Thanks & Regards,

On Thu, Aug 17, 2017 at 2:42 PM, Marek Mosiewicz <[hidden email]>
wrote:

> 17.08.2017 10:56 "Aditya Sharma" <[hidden email]>
> napisał(a):
>
> > +1
> >
> > Thanks and Regards,
> >
> > *Aditya Sharma* | Enterprise Software Engineer
> > HotWax Systems <http://www.hotwaxsystems.com/>
> > <https://www.linkedin.com/in/aditya-sharma-78291810a/>
> >
> > On Thu, Aug 17, 2017 at 10:39 AM, Arun Patidar <
> > [hidden email]> wrote:
> >
> > > +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 <
> > > [hidden email]> 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 <
> > [hidden email]
> > > >
> > > > 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 <
> > > > [hidden email]>
> > > > >> 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
> TemplateEmailSettingContentTyp
> > e
> > > > 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
> > > >
> > >
> >
>

--
Renuka Srishti

[Swapnil Mane]

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.

@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 :-)

- Best Regards,
Swapnil M Mane



On Thu, Aug 17, 2017 at 10:19 AM, Swapnil Mane <
[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]
>>> >
>>> 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
>

[Nicolas Malin-2]

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 <
> [hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]
>>>> 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
>>

[Swapnil Mane]

Thanks Nicolas :)

Hello team,
Added comment related to steps planning for this improvement.

https://issues.apache.org/jira/browse/OFBIZ-3894?focusedCommentId=16265653&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16265653


Thanks again everyone for your kind inputs.

- Best Regards,
Swapnil M Mane

On Sat, Nov 25, 2017 at 1:45 PM, Nicolas Malin <[hidden email]>
wrote:

> 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 <
>> [hidden email]> 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 <[hidden email]
>>> >
>>> 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 <
>>>>> [hidden email]
>>>>> 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
>>>
>>>
>