Enhancement #1148

Updated by Blatti Yves about 4 years ago

In V4 notifications have been simplified (many fields have been removed compared to V2).

Some of the fields in mails are important for users, validators and suppliers.

Here are the *needs of ASIT VD for notifications* as an example, elements in %{color:green}green% are present in the V4 mails:

|_.item/event |_.recipient (note) |_.mail subject |_.mail body |
|new order |user (order created) |id_order |id_order
%{color:green}order_name% |
|new order |extraction responsible |id_order
client_org_name |id_order
%{color:green}order_name%
client_name
client_org_name
[list]products_name *(1)* |
|new order |notified users |id_order
client_org_name
*note(2)* |id_order
%{color:green}order_name%
client_name
client_org_name
[list]products_name *(1)* |
|partial response
(first product ready)
see #1136 |user |id_order |id_order
%{color:green}order_name%
direct_access_order *(3)* |
|final response
(order_completed) |user |id_order |id_order
%{color:green}order_name%
direct_access_order *(3)* |
|new order validation |validation managers (TP) |id_order
client_org_name |%{color:green}id_order%
order_name
client_name
client_org_name
third_party_name
mandate_descr
mandate_contact
mandate_mail
%{color:green}direct_access_request% *(4)* |
|validation done |validation managers (TP) |id_order
client_org_name |%{color:green}id_order%
order_name
client_name
client_org_name
third_party_name
mandate_descr
mandate_contact
mandate_mail
%{color:green}direct_access_request% *(4)* |
|validation rejected |validation managers (TP) |id_order
client_org_name |%{color:green}id_order%
order_name
client_name
client_org_name
third_party_name
mandate_descr
mandate_contact
mandate_mail
%{color:green}direct_access_request% *(4)* |
|validation rejected
(*does not exists,
see #1146*) |user |id_order |%{color:green}id_order%
order_name
third_party_name
mandate_descr
mandate_contact
mandate_mail
direct_access_order *(3)* |
|supplier rejected
(when all products are
rejected by supplier) |user |id_order |%{color:green}id_order%
order_name
direct_access_order *(3)* |

Table notes:
1) See #1150 group by suppliers How should we format a list for text mails ? I see that easySDI sometimes send html content. Can we sent <li><ul> elements ?
2) This mail subject has currently no specific string (it's the same as the one for the extrection manager)
3) This doesn't exist yet, and should be secured by unique token
4) This link exists but is not secured by token, if a user knows the id of the validator he can validates his own order : #1147

h2. Problem :

The current mailing system uses @sprintf@ mechanism, it results in a limitation of fields usable and their order.
For example:
<pre>
COM_EASYSDI_SHOP_BASKET_SEND_MAIL_CONFIRM_ORDER_BODY="Your order '%s' has been sent. \n\n You can view it in your account on http://myeasysdi.org \n\n My EasySDI"
</pre>

h2. Solution proposal :

We could introduce a tag replacement system, with all elements of an order.
We can then pass the type of notification and an order id to the new mailer system.
For example the previous string could become:
<pre>
COM_EASYSDI_SHOP_BASKET_SEND_MAIL_CONFIRM_ORDER_BODY="Your order '{ORDERNAME}' has been sent. \n\n You can view it in your account on http://myeasysdi.org \n\n My EasySDI"
</pre>
EasySDI admins could then override the strings in joomla and for example change it to :
<pre>
COM_EASYSDI_SHOP_BASKET_SEND_MAIL_CONFIRM_ORDER_BODY="Your order {ORDERID} name '{ORDERNAME}' has been sent. \n\n You can view it in your account on http://mysite.ch \n\n My site admins"
</pre>

h2. Notes :

* We should use this change to correct some easySDI defects: #1136, #1146 and #1147
* To avoid breaking previous versions of easysdi (4.2.x), we should introduce new strings for mail, but keep the content (except if )
* This string mechanism should be applied to Subject and Body of the mails.
* This mechanism will have to be documented in the wiki for admins

Back