The user can already send a confirmation email when the
Stock Picking is done. It'd be great to communicate the
same information by SMS.
In addition, the current mailing tool requires a manual
action. The idea is to automate the process via a
Setting instead.
id=1972567
closesodoo/odoo#35662
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In this commit we improve templates used in delivery. Purpose of this commit
is to have templates that embed or use standard Odoo email layouts to make
them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843376 (and 1868112) and closes PR #25349
(and #25889).
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
All those templates are basically the same except some bug fixes that
were not propagated about company. Let us use just the one we just
defined in the mail module.
In this commit we change notification templates used to render
notification emails from jinja-based mail.template to pure QWeb
templates.
There are several reasons to do so
* those are not real mail.template records. Indeed they cannot be used
outside of the notification process as some values are computed
and not available on the mail.message record used to render the
template;
* we do not really need other fields than body. Indeed fields like
subject, email_from or email_to are computed from the notification
process;
* we do not want people to update the mail.template without knowing
the consequences, especially for fields like recipients that may
broke the mail gateway;
* using the html editor easily break the mail.template as it is very
custom and very to break without really realizing it.
It also simplifies template management as it lessens number of mail
template people have in their list view of mail.template. It avoids
mixing technical and functional templates.
We move to QWeb templates as those are not too hard to customize and
allow to perform body rendering which is what we really need when
notifying people of a new message.
This commit does not change the functional purpose and layout of the
templates. Behavior should be the same before and after this commit.
When an order is shipped, a notification email is sent to the customer.
If there is a tracking URL, it is included in the email.
(and also a bit of refactoring)
* migration to new API
* removed delivery.grid object, has been merged with delivery.carrier
* change view of delivery.carrier (price rules, etc.)
* tests from yml to py
* website : restrict the list of countries for delivery address in the shop
jbm-odoo