Up to now, there was no possibility to format a date
within a specific language, such as the customer
language. The date was always displayed with the format
YYYY-mm-dd.
(There was for the datetime, thanks to format_tz, but
not for a simple date without time)
This revision adds this possibility, but doesn't change
the according email templates
(such as the invoice date on the invoice email template)
as it would require to update all translations, in
the .po files and on transifex.
If a user absolutely want this, he has to add
the call to `format_date` himself, manually.
opw-704260
Other modules that was overriding old name method was just ignored.
Drop retro compatibility fixes in next freeze (saas-14) and stop
useless renaming.
This commit closes#13865
This reverts commit dc02f773ce.
This commit caused a side-effect that is worse than the issue
it tried to fix, which was purely cosmetic.
Now in mass-mail mode the template is only rendered once
and all recipients receive the same PDF, which completely
defeats the goal of a dynamic report. We have static
attachments for that.
Original fix related to opw-657152
Reverts PR #10568
This commit is a port of a17c09af to master
The email templates may contain non-html content (mako) which should not be
sanitized.
Changing this attribute to sanitize_attributes made the translations to be split
when translated.
Now having
* sanitize: run the sanitizer to clean the html (removing javascripts,
unwanted tags, ...)
* sanitize_tags: only a subset of tags is allowed in html content.
Unwelcomed tags are remove dand their content stripped.
* sanitize_attributes: only a subset of attributes is allowed.
* sanitize_style: only a subset of style attributes is allowed. Style
attributes are parsed to keep only a white list.
* strip_style: all style is removed. It bypasses sanitize_style as there
is no need to sanitize something that is removed.
* strip_classes: remove class attributes
Fields parameters have also been updated to match the sanitize options. Html
fields by default are sanitized with sanitize_tags activated but without any
further options. All addons have been updated to match the new options
according to their previous behavior.
This commits adds the check W0101 to test_pylint and fixes the errors.
The index in sequence.py was added in rev 1381ac139e and cancelled a day later in 83fdc271e6
so i guess it is safe to remove it.
The mail template rendering system use "autoescape" for subject, body,
email_to, ...
Using autoescape is good for the body, but for the subject it means
variables insertions have to be marked as safe.
This commit add another environment without autoescaping enabled for the
subject field.
From https://tools.ietf.org/html/rfc2822:
The "Subject:" and "Comments:" fields are unstructured fields as defined
in section 2.2.1, and therefore may contain text or folding white space.
2.2.1. Unstructured Header Field Bodies
Some field bodies in this standard are defined simply as "unstructured"
(which is specified below as any US-ASCII characters, except for CR and
LF) with no further restrictions.
closes#10547
opw-659231
opw-666801
opw-665863
When editing an email template with the wysiwyg,
the `<` and `>` operators are automatically converted
to `<` and `>`, even for the Jinja2 conditions,
therefore breaking these conditions, and the render
of the email templates.
We avoid to use these operators in the email
template, so users can customize the notification
email template without having an advanced
knowledge on how to edit an email template containing
Jinja2 code.
Besides, the line return at the end of the email template,
just after the `% endif`,
is done on purpose as well: the wysiwyg adds automatically,
at the time of this revision,
`<p></p>` at the end of the email template source, but
this cannot be added on the same line than `% endif`,
otherwise this is considered as Jinja2 code, and it's not.
opw-659113
Notification emails have been redesigned. They notably include buttons
allowing to perform some action directly from the email.
The notification creation and sending has been partially rewritten
and improved. The purpose is to lessen the number of rendering to perform
when sending emails to recipients. Recipients are first categorized into
groups. Basic groups are partners and users. The notification template
is then rendered twice, one for followers and one for not-followers. In most
cases there will be few rendering to perform. Through inheritance it
is possible to further categorize users. For example HR users / officers
that have approve / refuse buttons in their email.
A custom data structure is used to store data about buttons and actions.
URLs, follow / unfollow are added in the structure and used in the
template to render the email for a given group.
New routes are added in mail. Those allow to perform some action, like
going to a form in create mode, following / unfollowing, executing a method,
sending a signal for a workflow. Those routes are for users only and rely
on classic access rights.
A generic route for viewing records is added. It replaces the old redirect
action. According to some specific action given by the already-existing
get_access_action, the record will be visible for everybody (forum, blog)
or restricted (going on the Inbox / login / form view, according to access
rights).
The next commit will add the various inherits necessary to add the actions
in the main addons.
Christophe Simonis