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