Prior to this fix, elements with background images were converted to
images via the html2canvas library. This made them work in Outlook at
the cost of several tradeoffs:
- the process was slow and asynchronous
- there could be no interactivity (links, buttons, etc.) in the
converted element
- responsive behavior was wonky: if only a slice of the image was shown
when it was converted (due to background-size cover behavior), the
rest was lost so if more width was needed in mobile, we would be
zooming on that slice, making it sometimes irrelevant and pixelated
This replaces all that with a conversion to VML, which is a vector
format supported by Outlook. This conversion is done only for Outlook,
which means that all other clients are getting the original background
element again.
There is a way to keep the background-size cover behavior in VML, using
the "aspect" attribute with value "atleast" but this only works on
v-fill elements and sadly putting the image on a v-fill element bugs in
Windows Mail (which is the default mail client on Windows 10 and 11) and
this client can't be singled out of mso conditionals. To get around this
issue, since this is only for desktop clients, we assume the width of
the screen to be large and mimick the cover behavior by cropping the
image to the target size. This allows us to put the image on the v-image
element and have proper rendering in Outlook and Windows Mail on
desktop.
Note:
When retrieving the image by URL in Python in order to crop it, we need
to ensure we have an absolute path. This is done - perhaps seemingly
naively - by checking if the URL contains '//'. Here's the reasoning
behind that choice. To check if a URL is absolute, we could use
`urllib.parse.urlparse` and check if it has a scheme but that would lead
to `www.odoo.com/path` being considered relative (and thus we'd add a
host to the URL even though there's already one). Instead, we could
check it it has a netloc but that would lead to the same issue since the
documentation of `urlparse` says:
> Following the syntax specifications in
[RFC 1808](https://datatracker.ietf.org/doc/html/rfc1808.html), urlparse
recognizes a netloc only if it is properly introduced by ‘//’.
Still, it would be more technically correct since `//some/path` would be
considered absolute (which it should be since it resolves to
`<current_scheme>//some/path`).
Base on that documentation, it seems that simply checking if the URL
contains '//' is pretty much equivalent to checking if it has a scheme,
with the double advantage that it's simpler and that it works for
`//some/path` as well. However, note that it doesn't solve the issue of
`www.odoo.com/path`.
In summary, here are the results with the current method:
```
http://www.odoo.com/path -> http://www.google.com/path // OK
some/path -> http://localhost:8069/some/path // OK
/some/path -> http://localhost:8069/some/path // OK
//some/path -> //some/path // OK
www.odoo.com/path -> http://localhost:8069/www.google.com/path // WRONG
```
X-original-commit: 9561ba31917024825705c876442139405e7a7957
Part-of: odoo/odoo#124465
When activating the option "Restrict Template Rendering" the employee
group no longer gets the group automatically via the Implied Groups
field. However this did not have much effect because
- all the existing employees still had the group
- new users had the group via the template user
Remove the group with active_test=False to include the Default
Template User in the list.
Before this commit it was a bit confusing that new users still got the
group by default, even after deactivating the option in the settings.
closesodoo/odoo#110900
X-original-commit: ea0f674ac15964aaeb3def31758cec558b354a99
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In this commit we support calling rendering methods on void or falsy record
sets. Currently some rendering methods prevent from having 'None', some do
nothing specific. As Qweb or inline template support rendering on void records
we can safely support rendering on [], (), [False], [None]. Returned result
will either be void, either contain the rendered on void record for the
False or None key.
In this commit we also add a protection against trying to render a non
existing field. Instead of raising a KeyError, a ValueError is raised with
a clearer error message.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#106072
Purpose is to try to have code easier to read and to update by having a
common way of sorting / writing code. Reorder some fields definitions and
dictionaries, update docstrings, ... in mail applications or when invoking
mail thread API.
Additional stuff worth noting here
* add some tagged in tests helping debugging / choosing tests to execute;
* in a test about mail generation with server action: correctly check
body_html field, not body which comes from the mail.message inheritance
(currently filled due to a side effect but actual field to check is the
html one);
* add same check on input for ``_render_template_qweb`` as done on other
rendering methods (even if rendering on [False] should be supported);
* move code translation update from specific tests into main test class
(code update due to new translations, followup of odoo/odoo@f8c2b02abe);
Some test linting done here
* reorder mail_render tests, remove some duplicated tests;
* reorder mail_template tests, remove some duplicated tests;
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#106025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
Website: the context install_filename='dummy' is used to prevent
arch_updated from becoming True while updating translations of
ir_ui_view.arch_db (if arch_update becomes True, test_inherit_specific
fails)
Fuzzy search for jsonb translated fields has been adapted in the case of
website. It may require some refactoring later.
As an overridable _neutralize model method was added in a previous
commit, the method is now implemented for various models.
closesodoo/odoo#67825
Related: odoo/enterprise#19042
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
`_replace_local_links` ensures urls are given as absolute rather
relative paths, for link `href`, img `src` and within styles. This
failed when the style contained escaped single quotes (eg:
`background-image: url("/my_url/path");`). This commit adapts the
failing regex appropriately.
X-original-commit: 2af980e8cdc72d35729ef2fbaf5067fe7e72bbb8
Part-of: odoo/odoo#80621
This adds a test for the _replace_local_links function of mail render
mixin, in the case of urls in style attributes.
X-original-commit: 199b45c7f6b0155d3828487b2f7771e1500820b1
Part-of: odoo/odoo#80621
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
Purpose
=======
Purpose of this commit is to add a new group for the mail template designer.
Goal is to make roles clearer: managers edit templates, users use them. This
commit allow some designers / managers to make email template and to let
others users use those email templates.
Specifications
==============
When this feature is enabled in the Settings page, a new group is required to
modify email templates in a composer like wizard or to make dynamic content.
This allows to separate managers editing / composing templates from standard
users that use them.
If the current does not have this group, the email body will be in readonly
mode if he selected an email template. That way we force him to use the email
template that the manager made.
Technical
=========
New Group
---------
Only users in this group will be able to create / write email template or
to write Jinja code in the mail composer (including other fields like subject
in mailing).
By default, all internal users have this group. Mass mailing users also have
this group as writing mailings is about the same management level as writing
templates.
Mail Composer Mixin
-------------------
In comment mode, the template is rendered and then saved on the body field
so non-"Mail Template Editor" users can load email templates.
But in mass mode, the body of the template is saved and then rendered and
many things change the body (HTML sanitizer, web editor move inline CSS
properties, add / remove spaces...). So in this case, we can not know if
the user changed the body or not. That is why we put the body field in
readonly mode so, it is not modified by the web editor.
Jinja code detection
--------------------
To detect dynamic Jinja content, we compile the template, and we browse the
AST. If we do not have a single "Template Data" node, we assume that the
template is dynamic.
When we detect the template as static, we do not render it. That way we
avoid unnecessary rendering.
Code cleaning
-------------
Move Jinja import into tools so that it is outside of mail framework code.
Task-2187263
closesodoo/odoo#75840
Related: odoo/enterprise#20547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
Purpose of this commit is to prepare ground for future improvements by already
supporting QWeb rendering in ``mail.render.mixin``.
We temporarily support new field parameters allowing to tune the rendering
directly from field. Notaby choosing engine (jinja or qweb) can be done
from field directly. This is considered as experimental, used mainly to
prepare QWeb support.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Currently ``mail.render.mixin`` offers rendering tools, some of them being
based on a ``model`` field. It allows to know which model to use to fetch
records on which we perform rendering. However this field is not defined at
mixin level but in inheriting models without being clearly implemented that
way (see ``mail.template`` or ``sms.template`` models).
In order to clean this mixin it is now defined at mixin level, using a
not stored computed field allowing to define how to find this model. Sub
models are updated accordingly.
Other cleaning is done in the render mixin
* rename ``_render_template_qweb`` to ``_render_template_qweb_view``
to indicate it works on views, not on raw qweb templates;
* extract some common available variables for rendering in a method then
called / upated for jinja and qweb views;
* correctly set same rendering context for jinja and qweb views rendering;
* allow to propagate an additional context from _render_field to sub
rendering methods;
* allow to propagate options through rendering methods (notably for escaping
or safe attributes in jinja);
* allow to specify engine used to render lang;
* clean or update some docstrings;
Some tests are also added, as render mixin lacks some more detailed test to
ensure various use cases will be correctly migrated to other engines like
QWeb.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Co-Authored-By: Stéphane Debauche <std@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Add some tests for ``mail.render.mixin`` in order to assert its base behavior.
SPECIFICATIONS
Add tests for
* jinja rendering tools;
* QWeb rendering tools;
* translation support;
Also add tests for jinja markers: block, variable and line statement markers
should be tested.
Also improve docstrings of tool methods. Add notably explanation of parameters
and better explain methods purpose.
LINKS
Task ID-2500615
Prepares Task ID-2484296 (improve markers use in Jinja)
Prepares Task ID-27033 (support QWeb in templates)
COM PR odoo/odoo#68874
X-original-commit: f3dba8e020a0be72321427ed839b80ad77386946
Antoine Guenet