[#OQ-215] Products need to be able to email customers

OpenQuote

Products need to be able to email customers

Created: 03/Mar/10 07:23 AM Updated: 03/Sep/10 08:31 AM

Component/s:

None

Affects Version/s:

None

Fix Version/s:

1.3

Release Notes Comment:

« Hide

~~OQ-215~~ adds the facilityaf to notify proposers by email at various points in the quotation process. Previously, only broker notifications were supported. As well as adding the new notification channel, email templates are now defined within the product structure in CMS - meaning they can be easily altered and that products may define their own specific templates.

A new PageFlow actions has been added to support proposer notifications, and for consistency, the old "SendNotification" action has been removed - as it is now ambiguous.

Upgrade note:

If you have any notification actions in your QuotationPageFlow.xml, you will need to update them to make them compatible with this release.

Replace:
    <action id="SendNotification" when="onRenderResponse" commandName="SendNotificationAction"/>
With:
    <action id="SendBrokerNotification" when="onRenderResponse" commandName="SendNotificationAction"/>

The new proposer notifications can be included into a QuotationPageFlow.xml as follows:
    <action id="SendProposerNotification" when="onRenderResponse" commandName="SendNotificationAction"/>

Default templates for the emails are defined in the Base product; in the space: Product/Base/Templates. These can be edited in place, or copied into individual product spaces (in a Templates space), and edited as necessary.

Description

« Hide

Products can currently email the broker to notify them of quotations/referrals/acceptance, but it would also be useful to be able to email customers to notify them of cover start dates (when they accept cover), and of their quotations and referrals. Also, possibly, email warning when quotes near expiry.

All

Comments

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Dick Anderson - 19/Mar/10 01:54 PM

As part of this we should look at making the body of the email configurable by product. i.e. parsed html content or similar. We should also consider doing the same for the broker notification emails as their body text is currently hard coded.

[ Permlink | « Hide ]

Dick Anderson - 01/Apr/10 07:26 AM

Making the email body configurable suggest a template based approach. The Base product would define default templates which other products could use or override as necessary. The question is, which templating engine should we use?

The most obvious would be XSLT - especially as we already have a command adaptor for XSLT in the Core which would allow us to simply define a service which wraps stylesheet (referenced by URL) and can be invoked like any other command. However, XSL is not the simplest beast to learn and has the drawback that XSL can't easily be edited online. As the templates will be heavy on HTML and quite light on logic (judging by the current hard coded implementation) it would be preferable to be able to edit the templates in standard rich-text JS editors like the one in Alfresco.

For these reasons, it would be worthwhile looking at alternatives like Velocity (http://wiki.apache.org/velocity/FrontPage) which is considerably easier to get started with (as a template author) and is compatible with rich-text editors. Adding a Velocity command adaptor to the core might be a good starting point and would allow template authors to choose the engine which best suits their needs.

Should we consider some other engines too?

[ Permlink | « Hide ]

Dick Anderson - 22/Jun/10 05:33 AM

As an additional observation: we currently handle email generation in exactly the same way that we handle the generation of any other content - i.e. a widget with hard coded HTML. This approach is fine up to a point, but it would make the system as a whole considerably more flexible if all of these widgets were driven by templates.

This would give product developers enormous flexibility in how UIs are generated without introducing any additional complexity for those who are happy to use the base templates.

This JIRA should be used to cover the wholesale refactoring of the UI to a template driven approach.

[ Permlink | « Hide ]

Dick Anderson - 30/Jul/10 12:16 PM

I'm going to backtrack on that last comment. This JIRA should be used to create the facility to generate UI elements from templates, and should implement templates for the user email elements themselves. But the work of converting the whole UI to use templates will be covered under another JIRA to avoid holding this one up.