You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Swapnil Mane <sw...@hotwaxsystems.com> on 2017/11/25 08:03:05 UTC
Re: [Proposal] - Leverage the CMS capability for Product Store's Email
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.mane@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 <ni...@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.malin@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
Posted by Swapnil Mane <sw...@hotwaxsystems.com>.
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 <ni...@nereide.fr>
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.mane@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.malin@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.malin@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
Posted by Nicolas Malin <ni...@nereide.fr>.
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.mane@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 <ni...@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.malin@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
>>