With https://github.com/odoo/odoo/commit/55131b8f5becdd3d4776f4c3e7e4288a0b185706,
we automatically add the known editor context (containing lang,
website_id, etc) when using the `this._rpc` method. Some RPCs needed
however to explicitely not send a value from this automatic context...
but this was not correctly implemented. This can now be achieved by
using the `noContextKeys` key in the `this._rpc`'s *options* parameter.
closesodoo/odoo#28322
Unsplash API requirements does not directly allow to store their images on
our server (We should use hotlinking unless the image is edited (cropped etc)).
Still, they have the `Image Beacon Alternative` to allow to store their images
on our server if we really need it with our use case.
With the Beacon Alternative, we should ping Unsplash server to notify an image
view.
To do so, we need to be able to recognize Unsplash imagesin the DOM, this is
why we are now using /unsplash/ in the URL.
The Unsplash image name should be the image ID as it will be the identifier
needed to ping their server.
This commit also adds credit to Unsplash in the media dialog next to the
unsplash input search.
It also add the `w-100` on the media dialog card as we lost that UI behavior
from BS3 to BS4.
opw-35060
closesodoo/odoo#27377
When the user previews a background color, the background image of the
snippet is removed and re-added if the user chooses not to pick the
color. The background-image was not correctly added for carousel items.
- Handle the case where one select-class is a subset of another
select-class of the same group e.g.
<... data-select-class="hello"/>
<... data-select-class="hello world"/>
- Handle empty values <... data-select-class=""/>
Note: both cases worked but were not displaying the active checkbox
correctly in the editor UI.
For example, if primary = alpha, the primary button option is removed
in the link dialog. When editing a primary button, this lead to broken
behaviors. Hiding the button does the trick.
The code which removed the background image of a snippet when choosing a
background color worked kinda by chance. Indeed, on the final click on
the color option, the snippet background-image was reset... to the
current background-image, which is none thanks to the color preview.
Unfortunately, in some themes, the gradient color option interferes:
the current background-image at a color choice is equal to the current
gradient, and thus, that gradient is being moved as an inline style.
The bug was introduced with https://github.com/odoo/odoo/commit/285d95e946e5a15139c961e30dbe3598e0d99f6a
(as, before, the background reset was done by simulating a click on the
'background: none' option item, which was removed).
Closes https://github.com/odoo/odoo/pull/27808
If resetting a background color was the only edition that was done on a
page and that this page was saved, the change was not properly saved
as the page was not marked as dirty.
Closes https://github.com/odoo/odoo/pull/27625
task-1879524
On Safari, when editing the template of a mail.mass_mailing,
clicking the "Read more" button (or any button that can
have a link to the website) didn't open pop up to set
the URL of the website.
PS: inspired from https://github.com/textAngular/textAngular/issues/762
opw:1889643
Some snippet options uses an image or icon as description instead of
text (like the gradient option in some themes). Those were not working
anymore as the user click was considered on the image/icon instead of
the option itself.
closesodoo/odoo#27807
Adding bs4 `.is-invalid` class is supposed to add red borders on the
`form-control` element.
But the mixin `o-w-preserve-forms` prevents that style to be applied as it adds
`border: 1px solid $o-we-color-text-light;` on `.form-control`.
As the mixin selector has more strength (specificity), the bs4 is simply not
applied.
This is the case for `form-control` inside `o_technical_modal`.
closesodoo/odoo#27691
What was designed as a new feature appeared as a regression: users were
not able to choose a bootstrap gray as a background color anymore but
instead got the possibiility to choose a hardcoded gray. This commit
restores the use of the custom gray palette that themes can customize
and which automatically uses the correct text color when used as a
background. This also allows to remove ugly inline style from snippet
definitions and allows to solve bugs like the described below one:
---------------------------------------
Also add bg-* classes on snippet cards:
---------------------------------------
Snippet cards are often put (or may be put by the user) in an element
which have a bg-* class on it. This means that the card will still have
a white background (as chosen by BS4 by default) but the text color will
be adapted to that ancestor bg-* classed element.
This commit forces the card background color (as suggested by BS4) with
bg-* classes.
closesodoo/odoo#27637
* base, website
An image URL may be like "/web/image/<xml_id>" where <xml_id> is the
xml id of an ir.attachment. In fact, the route does not use the xml_id
but the 'key' field, which is normally equal to the xml_id for standard
attachment. In the context of themes + multi-website, the value used as
an xml_id may refer to a theme.ir.attachment instead of an ir.attachment
and this led to a bug as those must not be used the same way.
The crop route which gets image information is adapted by this commit to
always look for the *current website* *ir.attachment* related to the
given xml_id/key.
Thanks to @kig-odoo for spotting the issue.
Closes https://github.com/odoo/odoo/pull/27588closesodoo/odoo#27611
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).
Odoo Translation Bot