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

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

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

[Nicolas Malin]

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

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

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

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

[Renuka Srishti]

+1 Swapnil

Thanks & Regards,

On Thu, Aug 17, 2017 at 2:42 PM, Marek Mosiewicz 
wrote:

> 17.08.2017 10:56 "Aditya Sharma" 
> napisał(a):
>
> > +1
> >
> > Thanks and Regards,
> >
> > *Aditya Sharma* | Enterprise Software Engineer
> > HotWax Systems 
> > 
> >
> > On Thu, Aug 17, 2017 at 10:39 AM, Arun Patidar <
> > arun.pati...@hotwaxsystems.com> 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 <
> > > 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
> 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

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

[Marek Mosiewicz]

17.08.2017 10:56 "Aditya Sharma" 
napisał(a):

> +1
>
> Thanks and Regards,
>
> *Aditya Sharma* | Enterprise Software Engineer
> HotWax Systems 
> 
>
> On Thu, Aug 17, 2017 at 10:39 AM, Arun Patidar <
> arun.pati...@hotwaxsystems.com> 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 <
> > 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 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
> > >
> >
>

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

[Aditya Sharma]

+1

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 


On Thu, Aug 17, 2017 at 10:39 AM, Arun Patidar <
arun.pati...@hotwaxsystems.com> 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 <
> 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  >
> > 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
> >
>

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

[Arun Patidar]

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

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

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

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

[Swapnil Mane]

Thanks Pranay!


- Best Regards,
Swapnil M Mane

On Mon, Aug 14, 2017 at 12:52 PM, Pranay Pandey <
pranay.pan...@hotwaxsystems.com> 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 <
> swapnil.m...@hotwaxsystems.com> 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
>>
>> > bodyScreenLocation="component://ecommerce/widget/EmailOrderS
>> creens.xml#OrderCompleteNotice"
>> emailType="PRDS_ODR_COMPLETE" fromAddress="ofbizt...@example.com"
>> 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
>>
>
>

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

[Nicolas Malin]

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

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

[Pranay Pandey]

Good idea +1.

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

On Fri, Aug 11, 2017 at 11:31 AM, Swapnil Mane <
swapnil.m...@hotwaxsystems.com> 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
>
>  bodyScreenLocation="component://ecommerce/widget/EmailOrderScreens.xml#
> OrderCompleteNotice"
> emailType="PRDS_ODR_COMPLETE" fromAddress="ofbizt...@example.com"
> 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
>

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

[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 <
vaibhav.j...@hotwaxsystems.com> wrote:

> +1 Swapnil
>
> Thanks & Regards
> Vaibhav Jain
> Hotwax Systems,
> vaibhav.j...@hotwaxsystems.com
>
> On Fri, Aug 11, 2017 at 11:31 AM, Swapnil Mane <
> swapnil.m...@hotwaxsystems.com> 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
>>
>> > bodyScreenLocation="component://ecommerce/widget/EmailOrderS
>> creens.xml#OrderCompleteNotice"
>> emailType="PRDS_ODR_COMPLETE" fromAddress="ofbizt...@example.com"
>> 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
>>
>
>

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

[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 
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
>>
>> > bodyScreenLocation="component://ecommerce/widget/EmailOrderS
>> creens.xml#OrderCompleteNotice"
>> emailType="PRDS_ODR_COMPLETE" fromAddress="ofbizt...@example.com"
>> 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

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

[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 
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
>>
>> > bodyScreenLocation="component://ecommerce/widget/EmailOrderS
>> creens.xml#OrderCompleteNotice"
>> emailType="PRDS_ODR_COMPLETE" fromAddress="ofbizt...@example.com"
>> 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

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

[Nicolas Malin]

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



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

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

[Vaibhav Jain]

+1 Swapnil

Thanks & Regards
Vaibhav Jain
Hotwax Systems,
vaibhav.j...@hotwaxsystems.com

On Fri, Aug 11, 2017 at 11:31 AM, Swapnil Mane <
swapnil.m...@hotwaxsystems.com> 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
>
>  bodyScreenLocation="component://ecommerce/widget/EmailOrderScreens.xml#
> OrderCompleteNotice"
> emailType="PRDS_ODR_COMPLETE" fromAddress="ofbizt...@example.com"
> 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
>

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

[Michael Brohl]

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



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






smime.p7s
Description: S/MIME Cryptographic Signature

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

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



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

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

[Pierre Smits]

Hi Swapnil,

Great idea!

Best regards,


Pierre

On Fri, 11 Aug 2017 at 08:01 Swapnil Mane 
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
>
> 
> bodyScreenLocation="component://ecommerce/widget/EmailOrderScreens.xml#OrderCompleteNotice"
> emailType="PRDS_ODR_COMPLETE" fromAddress="ofbizt...@example.com"
> 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 
OFBiz based solutions & services

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