This commit adds a little label on the top corner of animated shapes
previews.
Part of #70843
task-2319488
Related: odoo/design-themes#17
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
1. Change some shapes to apply correctly the color presets:
e.g. the default color of the shape erased the background
color of the preset.
2. Improve some shapes to have a better render by changing
the colors and/or adding animations.
3. Some svgs could give the same result. To have a clean list,
many svgs were combined.
4. Letting the old svg files to assure the compatibility with themes.
5. Improve the preview of some shapes for a better reading.
Part of #70843
task-2319488
The goal of this commit is to add a new page to the shapes
(Floating shapes) and new animated shapes in the current
categories.
Colors should be, as other shapes, linked to the theme.
Part of #70843
task-2319488
Before, only the url input was focused when initializing the link
tools.
Now, we also scroll to the bottom of the options so that the user
directly has access to them.
Part of https://github.com/odoo/odoo/pull/71909
task-2542318
closesodoo/odoo#72122
X-original-commit: 748418d95059ad7ed5638aa4e4aca76da30fa6b3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Computing the image quality in preview when the slider was moving was
problematic for large images on chrome and FF. The preview for this
option has been removed.
Part of https://github.com/odoo/odoo/pull/71909
task-2542318
X-original-commit: da79bb6b3216ee71fe283c394d4c8acb5f76cdab
A new parameter displayHandles was introduced on SnippetOptions to
display or not the handles on a snippet. If a snippet had no option
needing the handles overlay, the overlay (and handles) from its closest
parent with such option was.
Two use cases were not tackled correctly and should display overlay,
even with no option with displayHandles:
- root containers (which have no editable parent)
- inline snippets (movable snippets)
Part of https://github.com/odoo/odoo/pull/71909
task-2542318
X-original-commit: 4b7dd2dbd378a9dc465e3e3fd8e32806df66919a
Currently, adding a padding to media is done with a select, which gives
a limited amount of options based on bootstrap classes.
This opens up the play field for the user by letting them input their
own pixel value.
closesodoo/odoo#72112
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
HTML fields used to have a toggle button for a "code view" (which came
from the Summernote library), in debug mode. This allowed the advanced
user to edit content with jinja conditions. This was lost with the new
editor but reintroduced for Mass Mailing. As it turns out it was needed
elsewhere so this makes the code view available as a node option, and
already activates it for mail templates.
To activate the code view in an html field:
```xml
<field type="html" options="'codeview': True"/>
```
Task: 2561300
closes#71860closesodoo/odoo#71891
X-original-commit: 0f9684677676b563a0ff2712e42cea24a2ef27bb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
On safari in saas-14.2, opening the full mail editor cause an error:
Traceback: Error: The string did not match the expected pattern.
matches@[native code]
getMatchedCSSRules
This is happening because this cause an error in safari:
document.body.matches(".custom-range::-webkit-slider-thumb");
and we get selector with :: that we should ignore because in d50c3b07f1
we use a global regex with `test` and multiple call of the regex on the
same string iterates over the string, for example:
var x = /a/g;
[x.test('a'), x.test('a'), x.test('a')]
gives [true, false, true]
opw-2489730
opw-2489515
opw-2502066
opw-2504051
opw-2518635
opw-2532695
closesodoo/odoo#71834
X-original-commit: ad0160de12d362baf56181478ee509ad223147fe
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit will fix a bug related to the position
of the shapes Blocks/01 and Blocks/02.
- Now, they can be connected when using together.
- Avoid a bug of position when the snippet is too tall.
Fix related to the PR #70843closesodoo/odoo#71809
X-original-commit: b5f135f83e576f6b552392249913dacca45a7650
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The shape is a particular one which connects at the top and bottom with
two sub-shapes. Those two parts used the same color which made it
impossible for an user to control them individually. This is now the
case.
This allows for a theme override in themes which used them at the top
of their homepage to have the first part with the same color as the
header, and the second part with the same color as the next snippet.
Part of https://github.com/odoo/odoo/pull/68336
task-2491890
closesodoo/odoo#71768
X-original-commit: e00bdd7bfd36a1205055a829807f5b8ab2d83221
Related: odoo/design-themes#14
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A shape is made of different colors which are mapped to user color
combination colors (e.g. if a shape use the #3AADAA color, it is by
default mapped to color combination background color n°4). We allow
to add other arbitrary mappings for each shape should a theme want it,
thanks to another created class. This is especially useful for header
and footer connections in default generated pages where the combination
of classes "o_web_editor_Airy_12 o_footer_extra_shape_mapping" will
use a color mapping using the footer color if the theme configured the
Airy 12 shape to do so.
This commit also modifies the generation of pages made by the website
configurator to automatically add the header and footer respective
classes on first and last shape if one is found (if one is found but
should not have a specific color mapping, this is not a problem as the
class has only an effect if the theme declares it).
Part of https://github.com/odoo/odoo/pull/68336
task-2491890
X-original-commit: 232224ff8c54c5027ec20dd9ddd5c0afc121a092
A shape is made of different colors which are mapped to user color
combination colors (e.g. if a shape use the #3AADAA color, it is by
default mapped to color combination background color n°4). We allow
to change that arbitrary mapping for each shape should a theme want it
(for example so that its built default page can use that shape with
a different color without having to hardcode it).
Part of https://github.com/odoo/odoo/pull/68336
task-2491890
X-original-commit: 2be9718e686e97e30a043a687be725c9a986ea7a
Previously, the default colors of background shapes was based on the
base palette colors o-color-1 to o-color-5. We generated classes for
those shapes that used the default colors, so that shapes would adapt
with the palette, so that if the user switched palettes their shapes
would still use the palette colors. While this works, shapes are meant
to connect together (no problem here) as well as with the previous or
following section's background color, but since shapes were using the
palette colors directly instead of using the *background* colors defined
by the palette, if the palette (or the user) customized any background
color, switching palette would break some shape-section connection.
Part of https://github.com/odoo/odoo/pull/68336
task-2491890
X-original-commit: 527af189eac381844280c9dbd716aa2465172f59
This commit allows not to display the popover where we don't need it.
Like on the next or prev buttons of the carousel for example.
task-2537840
closesodoo/odoo#71721
X-original-commit: 60853837a234f9fbfee5816f8a4766cc5a0b7d19
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Apparently libsass has never actually supported compound
selectors (or at least never the way people interpreted it should
work).
Therefore since libsass 3.5 (July 2017) that is deprecated and emits a
warning. Which is problematic because libsass is also hard-coded to
emit its deprecation warning to stderr[^1], resulting in a
few issues:
* because it's not decorated (let alone as a warning) it's not really
noticeable on the runbot or in most dev logs
* but because it's not associated with a logger it's basically the
only thing which shows up when running in `--log-level=warn` (as
it's printed at least once per tour)
* and it's pretty gnarly to get the information back in Python as,
again, hard-coded to stdout
odoo/odoo#70927 explored messing around with fds to intercept the
writes and re-emit them to the proper location, but that was
considered a bit too iffy.
And of course the intent was always to eventually fix the warning
itself, which qsm provided for in [a comment][fix-extend], the
important bit was the extension of `:disabled` so that's what's left
here to fix the warning. The logic of the fix is that the loader is
always used with the `form-control` class (internally) and the
`:disabled` part of the `form-control` styling is what we really want
to copy over. It's possible that third-party lose the styling if they
use `o_wysiwyg_loader` alone (without an explicit `form-control` next
to it) but that seems like an unlikely situation.
[^1] libsass 4 (sass/libsass#3135) surfaces warnings at the API level,
and removes the hardcoded / direct stream writing
[fix-extend]: https://github.com/odoo/odoo/pull/70927#issuecomment-847964413closesodoo/odoo#71667
X-original-commit: 5c2c6b881152630ffbf68d55c7c77fa2234f3ac1
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Range.extractContents resulted in an icon being duplicated when trying
to just apply a link to it.
closesodoo/odoo#71354
X-original-commit: 1a9423a223dcd049d939bfe62fbcbd5659a5c808
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
As replace and delete are already in the right panel, this is kind of a
duplicate. Related to f3ccc91d42
Also, add border around selected image so the used knows what image is selected
task-2502679
Closes#69340
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Indenting a checklist item duplicated its checkbox. This properly copies
the css from the editor that was lost in translation.
X-original-commit: 14efea8ac944eba483f7300d6ba6e51592f26b80
Issue:
> Set bg color combination for a snippet... > Save
> Edit mode > Select the snippet
> Open color palette in bg option
> Hover a color option
> When a color button is left, the preview is cancelled
but the color combination class is not applied anymore.
In '_computeWidgetState' (for 'selectStyle' method), the right
value ('o_cci') is not returned because we get empty "colorNames"
(the "colorPalette" is not rendered on start).
The goal of this commit is to fix this behaviour by rendering the
colorPalette in start for snippet options, this way, the new code
won't affect the speed fix added in [1] for 'OPTIONS' tab.
[1]: https://github.com/odoo/odoo/pull/65223/commits/ce54c3f21293513673cb1fc6073ada5f0a2b5641
task-2538326
closesodoo/odoo#71365
X-original-commit: fd31c9a10f97c92a48d0589a8bbeaf13a641e891
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Slightly improve the overall UI of Odoo with a more modern feel by updating the
current 'loading' icons that look quite old school.
Use fa-circle-o-notch instead of old style fa-spinner
task-2346142
closesodoo/odoo#59454
Related: odoo/enterprise#13908
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Wherever there is a sidebar, this moves all icon and image options to
their own section of it. This also enables previews.
The "spin" option was deemed unnecessary and therefore removed.
TODO: restore the link option for icons. It wasn't working properly
before this and was removed until it is fixed so as not to do any
unnecessary coding for a broken option.
closesodoo/odoo#70952
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When changing the number of columns of a snippet, the history was
recorded too many times and at wrong moments, resulting in a mess of
undos to trigger before restoring the original column state.
The issue was due a combination of dead code and the fact that
`_updateColumnCount` triggered `remove_snippet` for each of its columns
while `remove_snippet` in turn triggered a history step at every
execution.
This fixes it by removing the dead code, replacing it where necessary
with a call to the editor's `historyStep` method, and adding an option
to `remove_snippet` so its triggering of a history step can be bypassed.
closesodoo/odoo#70932
X-original-commit: 877e5c807087afed880aeba3eab79def3a7b583c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
`_(xyz)` will wrap them in an underscore.js object, which when used in
a string context will just return the string. So it's basically a
no-op, but it certainly doesn't translate the terms.
closesodoo/odoo#70476
X-original-commit: 92352ed2b5524c97b0aeeba3193c6a8d93ed82a1
Related: odoo/enterprise#18172
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit will add the needed ESLint configurations on the JS files.
These configurations are added if the JS file uses a different
environment (serviceworker, node, etc) or if it uses a specific global
(google, ace, etc).
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Previously, when toggling on background shapes, they always had the
default colours. In [1] we made it so that when you toggle on a shape on
a section, it would automatically reuse the colors of the surrounding
shapes if any.
Unfortunately, when the "implicit" colors were also the default colors,
they were still marked on the shape, and it got an explicit background
image that would no longer react to changes in the palette.
This was caused by the fact that the call to _getDefaultColors returns
an empty object when the section doesn't already have a shape-container,
this was not a problem before since we were not passing in any colors
when creating the initial shape previously, the the aforementioned
change made it so that we did.
This commit fixes the issue by creating the shape-container before
calling the method that will set the colors on the shape, this way
getDefaultColors works as expected, and the colors are not marked on the
section when they are the default ones, restoring the ability of the
shape colors to adapt to the palette
[1]: https://github.com/odoo/odoo/commit/875aca63f7dab287c61485ebe999b3b8dd89d91c
task-2500607
closesodoo/odoo#70054
X-original-commit: 63acc2b0d1957dedd40af2033722f9ea4ef2e597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Tom De Caluwé <tdc@odoo.com>
On creating a new note, the focus was automatically set into the "tags"
field. This was inconvenient and was replaced with an autofocus on the
note itself so we the user can immediately start typing.
closesodoo/odoo#70195
X-original-commit: 8fe89c5ebc138cb517938dbd6d975b8bec4eaf4d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Scenario:
- add a file in mass mailing editor => an generic icon (instead of lower
version where icon depended on mimetype) is added linking the file
- save and send mail => no icon is shown in email received
The system is targeting `a[href*="/web/content/"][data-mimetype]:empty`
to add real image inside instead of using background-image attribute
which is stripped in sanitized.
With this commit, data-mimetype is not removed when image processing
attributes are removed when a file is inserted.
opw-2474053
closesodoo/odoo#70022
X-original-commit: eb3772508ce518ff3f84724eebbe43fd1e040d77
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The media modal's document tab has cells with icons and filenames. If
the filename was too long, it would overflow its cell, which caused an
ugly design glitch. This ensures an ellipsis on the filename when it is
too long.
closesodoo/odoo#69990
X-original-commit: 8a4f4bf04bd5e5f9cf827273ea27a189a43c2515
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The "note-editable" class was lost on the editable element when loading
it into an iframe. As a result, some selectors failed, making it so that
some options wouldn't activate when they should.
closesodoo/odoo#69908
X-original-commit: d71b7d87daa5b33f16eb9c6ade29580fb2076313
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In an iframe, we need to make sure the element is using jquery on its
own window and not on the top window lest jquery behave unexpectedly.
This was apparent with tooltip which was called in snippets.editor with
the "wrong jquery", with the result that tooltip.js had a reference to
the top window/document instead of that of the iframe. Because of that,
it appended its tooltips to the top window instead of the iframe, and
as a result, said tooltips were wrongly positioned.
closesodoo/odoo#69879
X-original-commit: 19be8709efa8f690ccff8d04dd9a17e4ef4d82fd
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
The overlay around an image when cropping it is positioned absolutely.
If it has no relative ancestor, it will cover the entire body. This is
what happend in mass_mailing, making it impossible to scroll the page
while cropping. This commit addresses the issue by positioning that
editable relatively so that the overlay never goes beyond its bounds.
closesodoo/odoo#69878
X-original-commit: c4d423640a9f1f9892e9d24dc08531ba0bbf8887
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
