Introduce official support for SVG files in the framework, including the
following parts:
1. When client-side SVG images are uploaded, the content is displayed until
you save using data URI scheme according RFC 2397 [1]. This scheme requires
to specify content format. Using hardcoded "image/png" works for all images
types except SVG.
Type-sniffing is done using "magic byte" detection via the first base64
encode byte, so that the proper data URI scheme can be used.
This should not cause SVG-related security problems as the file is
displayed through `<img>` tag, which does not allow SVG scripting [2].
2. Make /web/image controller compatible with SVG
3. Add support for SVG files for company logo, which uses a dedicated
controller.
4. Resizing of SVG files is a no-op, as it makes little sense for a
vector-based format. We also want to avoid micro-alterations to the SVG
document (in "natural" viewport parameters) as we would store multiple
copies of the files in the filestore.
5. Because SVG files are inherently dangerous, upload of SVG files is
restricted to administrators, either by blocking it directly before
saving it in the database (binary fields with attachment=False), or by
neutering them to text/plain mimetype (for binary fields with
attachment=True)
6. Add tests for the SVG upload cases and for the non-admin uploads.
[1] https://tools.ietf.org/html/rfc2397
[2] https://www.w3.org/wiki/SVG_SecurityCloses#26635
* web_editor, website
Add an opacity slider and an opacity input to control opacity over
the chosen color.
task-1887571
Closes https://github.com/odoo/odoo/pull/27289
Before this commit, when using the website editor, modifications were
saved in place in the original view. The view was also marked as non
updatable so that when an user migrates its database, he does not lose
its modifications.
The problem with this system is that users were able to keep their
modifications at the cost of having views which are not up-to-date with
the latest odoo updates.
Now, the views' content which is inside an oe_structure element is saved
in an inheriting view instead of the original view. The original
view is not marked as non updatable anymore.
Note 1: we only consider elements with the 'oe_structure' class which
also have an id containing the 'oe_structure' string.
Note 2: if a non oe_structure but editable content is edited, the
original view is still marked as non updatable (however, with the new
multi-website feature, this may not be necessary as the edited view will
be duplicated to be website-specific... we may want to disable the
behavior in a future update).
* web_editor, website_blog, website_crm_partner_assign, website_links,
website_livechat, website_mail_channel, website_mass_mailing,
website_slides
Calling a model's method thanks to an RPC will now always send the
web_editor context automatically, making sure the method gets the
website_id all the time, removing the need to guess the current website
(now the get_current_website method uses the context website_id if any).
Note: other routes already have the website_id via request.env.context
if they correctly set website=True (this commit also adds website=True
for scss files customization routes).
Setting a black low-transparency filter on a parallax element was
leaving the text color black too as the filter did not act as a
background color. Now the filter is computed from the parallax
background color.
Before this commit, the view create by editor (to change the scss file in asset for example) was not website specific.
Now we override (use the new hook method) to add the website_id.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
* web_editor, website_slides
Current system is styling all navbars with the user color. This was not
the expected behavior but it is in fact quite nice, so we decided to
keep it. There was however a problem: choosing the menu text color only
applied to the main navbar (as it was an xpath toggling the navbar-dark
class).
This commit solves the problem by forcing navbar-light to behave as
navbar-dark automatically if the menu background is dark, and this
without any JS or extra CSS rules. This allows to get rid of the menu
text color option.
This commit also reviews the light and dark colors which are used when
website is not installed.
Rev. 2f7c03d added a second admin user (id 2), the 'human' one, on
top of the 'technical' one (id 1, also known as the superuser).
Basically, all calls to _is_superuser() should have been changed to
_is_admin(). They weren't. As a consequence, some features that
were previously available for the admin weren't anymore (e.g.
tours).
This rev. replaces all calls to _is_superuser() by calls to
_is_admin().
The ir_translations were pretty slow to load, this was mainly caused by
the condition in variable 'find_expr' and the import of po values in the
temporary table.
To improve the load performance, we made two improvement:
1. Insert the row in the temporary table by batch instead of making an
insertion for each record.
2. Replacing the condition in the variable 'find_expr' by partial unique
index. To perform such a thing, we had to separate the type model in
two types, 'model' and 'model_terms' because it wasn't possible to
create a partial unique index on type 'model' because the type was
used for two different use cases. The type model is now used for
fields that have have a value not callable for the attribute
translate, these field can only have one record for the same field,
model, res_id and language. And the type 'model_terms' is used for
the fields callable, because they can have multiple sources for the
same res_id.
We also removed the deprecated types 'report', 'help', 'view', 'field'.
Thanks to @rco-odoo for the improvement of the first point.
As an `form-group` can contains element having `form-control` class and other
not having it, we should not force height on `form-group` elements.
Typically, we could have:
div.form-group
input.form-control
button
Forcing height only on `form-control` will make the input thinner than the
button.
The menu item dialog is an extension of the link dialog where all the
.form-group elements which contain a .link-style option element are
removed. A new link style option was recently added but with the wrong
class, preventing it to be removed for the menu item dialog.
task-1878245
By default, all btn colors are suggested in the link dialog (alpha,
beta, gamma, delta, epsilon, link, primary, secondary, success, info,
warning and danger). In lots of themes (and the default one), primary
= alpha and secondary = beta, which led to having two suggestion with
the same apparent color.
A new system was introduced to automatically remove the duplicates...
but this system also removed the button preview as it considered it to
be a duplicate.
This commit also adapts the preview to BS4.
task-1878245
Commit https://github.com/odoo/odoo/commit/903ff171acbef7f9fe6e533f43b99eba801b200f
lowered the font-size to 14px for the frontend by customizing the
bootstrap variable in the portal app. It changed the web_editor
rte_inline tour accordingly.
This however broke the test on runbot "base" database, as the font-size
in the editor without having installed the portal app was still set to
16px. Commit https://github.com/odoo/odoo/commit/e3bc059c3649a05c12cd3c8099092282c10141b7
only moved the failed test from "base" to "all" database.
This commit unifies the font-size for all frontends by setting it in the
web app. So, after this commit: reports, editor, login screen and
frontend will always have a font-size of 14px no matter the application
which is installed (except themes).
With BS4, the website's font size was set to 16px instead of 14px as
before. We finally decided to force the 14px back. This commit also
moves some bootstrap variables extensions to portal as it should have
been done and reformat the files to match the bootstrap _variables.scss
file.
* website
```
$map: (
test: 1,
black: 2,
);
@debug map-get($map, 'test');
@debug map-get($map, test);
@debug map-get($map, 'black');
@debug map-get($map, black);
```
The above code leads to a:
1
1
null
2
This is because maps' keys can be *anything* in sass (even other maps).
In the example, the map is defined with unquoted `test` and `black` as
keys which are understood as the string 'test' and the *color* black.
When asking for the value for the 'black' string key... there isn't any.
This commit forces the use of quoted string as color maps' keys.
Odoo Translation Bot