acb9e5fe4908ba0a2ea2be4eccdffaa8a034ae60
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Xavier Morel
|
01875541b1 |
[CHG] core, web: deprecate t-raw
Add a big fat warning when the qweb compiler finds a `t-raw`.
`t-esc` should now be used everywhere, the use-case for `t-raw` should
be handled by converting the corresponding values to `Markup`
objects. Even though it's convenient, this constructor *should never
be made available in the qweb rendering context* (maybe that should be
checked for explicitely?).
Replace `werkzeug.escape` by `markupsafe.escape` in
`odoo.tools.html_escape`, this means the output of `html_escape` is
markup-safe.
Updated qweb to work correctly with escaping and `Markup`, amongst
other things QWeb bodies should be markup-safe internally (so that a
`t-set` value can be fed into a `t-esc`). See at the bottom for the
attributes handling as it's a bit complicated.
`to_text` needed updating: `markupsafe.Markup` is a subclass of `str`,
but `str` is not a passthrough for strings. So `Markup` instances
going through would be converted to normal `str`, losing their safety
flag. Since qweb internally uses `to_text` on pretty much
everything (in order to handle None / False), this would then cause
almost every `Markup` to get mistakenly double-escaped.
Also mark a bunch of APIs as markup-safe by default
* html_sanitize output.
* HTML fields content, sanitization is applied on intake (so stripped
by the trip through the database) and if the field is unsanitised
the injection is very much intentional, probably. Note: this
includes automatically decoding bytes as a number of default values
& computes yield bytes, which Markup will happily accept... by
repr-ing them which is useless. This is hard to notice without `-b`.
* Script-safe json, it's rather the point (though it uses a
non-standard escaping scheme).
* Note that `nl2br`, kinda: it should work correctly whether or not
the input is markup-safe, this means we should not need to escape
values fed to `nl2br`, but it doesn't hurt either.
Update some qweb field serialisations to mark their output as
markup-safe when necessary (e.g. monetary, barcode,
contact). Otherwise either using proper escaping internally or doing
nothing should do the trick.
Also update qweb to return markup-safe bytes: we want qweb to return
markup-safe contents as a common use-case is to render something with
one template, and inject its content in an other one (with Python code
inbetween, as `t-call` works a bit differently and does not go through
the external rendering interface).
However qweb returns `bytes` while `Markup` extends `str`. After a
quick experiment with changing qweb rendering to return `str` (rather
unmitigated failure I fear), it looks like the safest tack is to add a
somewhat similar bytes-based type, which decodes to a `Markup` but
keeps to bytes semantics.
For debugging and convenience reasons, MarkupSafeBytes does *not*
stringify and raises an error instead (`__repr__` works fine). This is
to avoid implicit stringifications which do the wrong thing (namely
create a string `"b'foo'"`).
Also add some configuration around BytesWarning (which still has to be
enabled at the interpreter level via `-b`, there's no way to enable it
programmatically smh), and monkeypatch `showwarning` to show warning
tracebacks, as it's common for warnings to be triggered in the bowels
of the application, and hard to relate to business logic without the
complete traceback.
`t-out`
=======
`t-esc` is a bit confusing for the new behaviour of "maybe escape
maybe not", so add a `t-out` alias with the same behaviour.
Unlike `t-raw`, `t-esc` is only soft-deprecated for now: there are
thousands of instances, so editing all the templates is not
great. Eventually we'll add a `ci/style` to prevent addition of new
ones, and eventually we might do a bulk-replace and hard-deprecate.
Attributes handling
===================
There are a few issues with respect to attributes. The first issue is
that markup-safe content is not necessarily attributes-safe
e.g. markup-safe content can contain unescaped `<` or double-quotes
while attributes can not. So we must forcefully escape the input, even
if it's supposedly markup-safe already.
This causes a problem for script-safe JSON: it's markup-safe but
really does its own thing. So instead of escaping it up-front and
wrapping it in Markup, make script-safe JSON its own type which
applies JSON-escaping *during the `__html__` call.
This way if a script-safe JSON object goes through `markupsafe.escape`
we'll apply script-safe escaping, otherwise it'll be treated as a
regular strings and eventually escaped the normal way.
A second issue was the processing of format-valued
attributes (`t-attf`): literal segments should always be markup-safe,
while non-literal may or may not be. This turns out to be an issue if
the non-literal segment *is* markup-safe: in that case when the
literal and non-literal segments get concatenated the literal segments
will get escaped, then attributes serialization will escape
them *again* leading to doubly-escaped content in attributes.
The most visible instance of this was the `snippet_options` template,
specifically:
<t t-set="so_content_addition_selector" t-translation="off">blockquote, ...</t>
<div id="so_content_addition"
t-att-data-selector="so_content_addition_selector"
t-attf-data-drop-near="p, h1, h2, h3, .row > div > img, #{so_content_addition_selector}"
data-drop-in=".content, nav"/>
Here `so_content_addition_selector` is a qweb body therefore
markup-safe, When concatenated with the literal part of
`t-atff-data-drop-near` it would cause the HTML-escaping of that
yielding a new Markup object. Normal attributes processing would then
strip the markup flag (using `str()`) and escape it again, leading to
doubly-escaped literals.
The original hack around was to unescape() `Markup` content before
stringifying it and escaping it again, in the attribute serialization
method (`_append_attributes`).
That's pretty disgusting, after some more consideration & testing it
looks like a much better and safer fix is to ensure the
expression (non-literal) segments of format strings always result in
`str`, never `Markup`, which is easy enough: just all `str()` on the
output of strexpr. We could also have concatenated all the bits using
`''.join` instead of repeated concatenation (`+`).
Also add a check on the type of the format string for safety, I think
it should always be a proper str and the bytes thing is only when
running in py2 (where lxml uses bytestrings as a space optimization
for ascii-only values) but it should not hurt too much to perform a
single typecheck assertion on the value... instead of performing one
per literal segment.
Note: we may need to implement unescape anyway, because it's still
possible to get double-escaping with the current scheme: given an
explicitly escape-ed `foo` and `t-att-foo="foo"`, `foo` will be
re-escaped.
fixup! [CHG] core, web: deprecate t-raw
|
||
|
Sébastien Mottet (oms)
|
e8a5af2e28 |
[IMP] website: configurator for automatic website generation
On website app installation and on new website creation a configurator is launched. The purpose of this configurator is to generate a website that meet the user's needs. The configurator is composed of 4 steps: 1) Business description: the user is asked to describe its need with its website purpose (dropdown), its industry (autocomplete search) and its objective (dropdown). 2) Logo and palette selection: the user must select a color palette for its website. He can also upload its logo. In this case color palettes recommendations are generated based on the logo's colors. 3) Features selection: the user select the pages and applications he needs. 4) Theme selection: three themes are recommended to the user based on its industry. This screen display a preview of these three themes. task-id: 2451965 ENT PR: odoo/enterprise#16949 UPG PR: odoo/upgrade#2316 closes odoo/odoo#67537 Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com> |
||
|
Xavier Morel
|
d9a5a28baf |
[FIX] base: explicitly specify resampling filter when resizing
Pillow 7.0 changed the default resampling filter from NEAREST to BICUBIC. Because the logo parser resizes the image before sampling it and doesn't specify a filter, its behavior changes depending on the version of Pillow, even if the input image is the same. And there's a test depending on its output with a fixed image. Explicitly specify the old default as that's what's in the test. closes odoo/odoo#60121 X-original-commit: 3dbc0711b65ae47a230bcd8b3348962127bcaf14 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com> |
||
|
Nicolas Galler
|
e6fccbae92 |
[FIX] base: do not crash if uploading a grayscale image
Behavior before the fix:
Uploading a grayscale image with transparency in the company logo field
of the document layout causes a crash:
```
File "/data/build/odoo/addons/web/models/base_document_layout.py", line 89, in _compute_logo_colors
wizard.logo_primary_color, wizard.logo_secondary_color = wizard_for_image._parse_logo_colors()
File "/data/build/odoo/addons/web/models/base_document_layout.py", line 191, in _parse_logo_colors
color[1][2] > white_threshold) and color[1][3] > 0:
Exception
...
IndexError: tuple index out of range
```
To reproduce, use the `logo_ci.png` image included in the unit test
data and load it in the document layout (under General Settings).
The system does not detect that the image does not have color
information and attempts to read the R,G,B values (but the image only
has 2 values per pixel: the grayscale value and the alpha)
Versions affected: 13, 14
Behavior after the fix:
The image is loaded correctly (arguably, there is not a lot of interest
in detecting the primary color of a grayscale image, but the script
still returns a (gray) value which is preferrable to a traceback)
opw-2352394
closes odoo/odoo#59498
X-original-commit: 6d6e48f34f850fa533ce00532ada0e3464c8144b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
|
||
|
Martin Trigaux
|
064f995c1a |
[IMP] base: implement comment
Forgotten TODO Instead of checking in _for_xml_id (where 99% of calls are static), verify on the few calls that accept an arbitrary argument closes odoo/odoo#57117 X-original-commit: efc0263b2574fa355ea794514eb3285d8c449260 Related: odoo/enterprise#12975 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com> |
||
|
Simon Genin (ges)
|
618067aa3f |
[IMP] base: Document layout preview improvements
The document layout preview is a complete defferent simplified template with its own css that replicates at best the different styles. It does not have the external layout features and lack of fidelity. The new preview actually use the real documents templates and put the result in an iframe. It now has a high fidelity, though not perfect. The goal is for a better onboarding, where clients see easely how documents will look if they had an app to generate them. Of course, the data on the document is a false invoice. Refactor all this from base to web. Task ID 2304177 closes odoo/odoo#56995 X-original-commit: c121a246f16899735306266a3a12b526e08e7620 Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com> |