This commit completes [1] by further reviewing the drag and drop
technical flow order:
- The content_changed event should be triggered before starting snippets
as well as it is only useful to signal the snippet modifications made
by onBuilt.
- The undroppable snippets update which was done first could probably be
done anywhere -> best to put it at the end when everything in the DOM
is done, and it is also the last thing the user expects to be done.
Note: in the new editor the role of 'content_changed' became however
unclear and should be further reviewed. This commit fixes problems with
the old flow in master though (problems around removing items in a
snippet during its onBuilt call).
[1]: https://github.com/odoo/odoo/commit/60d7bf6d7daea83db9332b4fc47a4ac6892d21d7closesodoo/odoo#75596
X-original-commit: efdfe261afd933972869305fd3358c764f7c18c3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Regarding previous commit, the option parameter can be removed
from _get_asset_content api, followed by a nice snowball effect.
Part-of: odoo/odoo#75248
Since [1], this commit the controls for the background image positioning
were not accepting events anymore and were below margin handles.
After this commit the controls for the background image positioning can
be used again.
[1]: https://github.com/odoo/odoo/commit/a37f27d08fe2113a81668959d23282e9ae741115
task-2627710
closesodoo/odoo#75576
X-original-commit: e266669361cde6f799683fa6b082777d0f416c57
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit editing a link that was saved with fill styles
did reset it to a different value and even changed the 'type' to 'link'.
After this commit re-editing the link works for each style.
task-2629461
closesodoo/odoo#75512
X-original-commit: 4f6cc912260c5b5689b0e87644ad119ef5a1389c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
When an option notifies that it was used, its ancestor SnippetEditor
instances were in charge of asking for an UI update of all their options
(see [1] where this was already fixed). This was inconsistent with the
logic of our UI where the value of one option might affect the value and
visibility of another option which comes *after* it, e.g.:
- the user sets a badge type to 'info'
-> the badge background option (below) is shown as blue
- the user adds a shadow
-> more options are shown afterwards to control it (not above)
After this commit, we now update the whole editor panel (parent and
child options) wherever the updates come from. The only important thing
is to first update the options UI then their visibility as their
visibility may depend on their UI status.
This allows at the same time to fix the source of a race condition, as
enabling a snippet also triggers an UI update whose async parts were not
properly awaited (which thus may lead to inconsistencies if the user
clicked everywhere in the DOM too quickly).
[1]: https://github.com/odoo/odoo/commit/7623a0c771495cd41bf40af37c0d2b6e4beb7cdc
Part of https://github.com/odoo/odoo/pull/74959closesodoo/odoo#74959
X-original-commit: 488b9ae45e728327e0d43b91b7c2d6edf2a33be1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The editor panel keeps tracks of the SnippetEditor instances which are
enabled at the current time. When previewing one (by hovering its UI),
that tracking was messed up making onFocus and onBlur calls inconsitent.
Part of https://github.com/odoo/odoo/pull/74959
X-original-commit: 0d7e660d8c0941b1af83b08a90d936933287d681
Before this commit, with some animations (e.g. Bounce In-Left) the
overlay of the animated element or the overlay of selected element
inside it no longer reappeared after the animation.
task-2630112
closesodoo/odoo#75444
X-original-commit: fb98430b1cdbc63896d152b39bcf23c0f2241cb4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web
After this commit pre-configured gradients can be used as snippet
backgrounds, snippet filters or as text effects / highlight effects.
The background colors (and now gradients) are now possible to add
*alongside* a color combination class (editing one does not remove the
other). Background colors and gradients are mutually exclusive.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
closesodoo/odoo#73611
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
All background-color classes (bg-XXX) were defined before the color
combination classes. Except for the Odoo colors ones (bg-o-color-X)
which were defined after. That inconsistency was not a real problem
before as those two type of classes could not be combined but this will
change in the future.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
The editor sometimes compare CSS values, in particular in the
selectStyle method where a given style is not applied if it would have
no effect (e.g. applying an inline pink background-color is useless if
the block is naturally pink because of CSS rules). That comparison
failed when it was comparing 'var(--XXX)' and 'YYY' as 'var(--XXX)' was
not processed as the CSS variable 'XXX' to be read.
Related to task-2599770
closesodoo/odoo#75201
X-original-commit: 22b5d90539895bb7c2b14de4abbb2d7d978a6f79
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Whenever using the `getPowerboxElement`, it is possible to have a
null node.
closesodoo/odoo#75163
X-original-commit: 03d7021b251d31cfda055c6ffe9684fad191903c
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Some templates contain empty <li> elements for styling purposes
only and should be blacklisted in the context of Odoo editor hints
as these elements are not editable.
task-2550858
closesodoo/odoo#74944
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
If the active element is an Odoo field (ie. a field with the
`data-oe-model` attribute) it means the content should not be
considered html, unless its type is specifically `html`.
If the Odoo field is of the `html` type, the Powerbox should only
be triggered if the active element is _within_ that field rather
than _being_ the field itself.
task-2550858
Old shortcut (ctrl+K) was conflicting with the new command palette feature, so we change it to CTRL+M.
task-2593213
closesodoo/odoo#75069
X-original-commit: 0371fe2b9e54ff557265a8f8fc919d351ed6a7d5
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Mass mailing form view currently has a scrollbar for the contents of the
editor, one for the form view itself, and one for the sidebar. In
consequence we can sometimes end up with three scrollbars side by side,
which is ugly and confusing.
This ensures the height of the iframe is always that of its contents so
there is no need for a scrollbar.
When inserting a new snippet we want to autoscroll to that snippet. That
is a complicated situation because the element we want to scroll is not
in the same document as the element we want to scroll _to_.
To address that situation, a new option is added to `scrollTo` so we can
pass it the element to scroll. It can then check if we are in the
aforementioned situation, in which case it can correct the scrolling and
apply it to the right element.
We use that option in mass_mailing to prevent the bug.
Task-2545445
closes#71511
Currently, editing a mail feels a little claustrophobic because of the
boxes within boxes within boxes design. This commit removes the chatter
and the sheet from the form view so the mail editor can take up more
horizontal space. The chatter is then moved into one of the notebook's
tabs.
Task-2545445
closes#71511
The command bar hints were not properly text-aligned, and the color was sometime not visible depending on the background.
task-2607335
task-2607337
closesodoo/odoo#75028
X-original-commit: 0cd597558c2da268148ca8871442014edba3fdcb
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
The bold command used `assignInlineStyle`, which misidentified when a text node needed
to be wrapped in an inline element in some situations, eg:
`<p>aaa<span style="font-weight: normal;">[bbb<span>c]cccc</span>bb</span>dddddd</p>`
task-2613476
closesodoo/odoo#75015
X-original-commit: a61fe7a338289b9195dfca56389593411daf2401
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Because of css rules, when a space was inserted (which is supposed to close the power box), it wouldn't be present in the innerText string.
It was fixed by using the textContent property instead, which contains all the spaces, including the invisible ones.
This might cause problems in some situation where the markup that the editor is modifying contains formatting spaces.
task-2584101
closesodoo/odoo#74766
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
The auto-link making feature would insert two spaces when the user would try to add one space.
It is no longer the case.
Some selection management with the link making has been fixed as well.
task-2584101
When the user selects text, the editor compares its closest block type
with a pre-made list of text types (eg. p, h1...).
In case of a match, the 'active' class is applied on the relative
toolbar component.
This commit will extend the comparison list adding text styles that were
initially missing (= the code, h4, h5 and h6 tags were never marked as
active).
Related to task-2496339
closesodoo/odoo#74925
X-original-commit: 1f1157c7e5c2df1bf318ad3a32e7030c969f5261
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When inside a specific color preset, active dropdown items' background
color is set to that preset's primary color. However, their text color
was not properly computed mainly because of [1] which forced other rules
as important.
[1]: https://github.com/odoo/odoo/commit/2172295cefa1d8780332709bf0c97cfa23def3a5closesodoo/odoo#74776
X-original-commit: 67fb206e2ef4828712a53052282aa0791edb74e7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the popover would be displayed on top of the clicked
element if that element was a menu in a dropdown.
Indeed, there was not enough room for the popover to be shown correctly, as the
available space was the dropdown itself.
Note that if there was more than 2 menus in the dropdown, it would work
correctly as it would create enough space for the popover to be shown bellow or
above the menu.
Step to reproduce:
- Create a menu and a submenu
- Click on the menu, it opens a dropdown with the submenu inside it
- Click on the submenu, the popover position is wrong
task-2618494
closesodoo/odoo#74755
X-original-commit: b0b9fd2fd07fec96dd870467e8d9d8da7996c8ef
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Issue:
- [1] Edit mode > Set a shape on image (mimetype = 'image/jpeg')
- [2] Replace it by an animated GIF.
- [3] Replace the .GIF image again by the old one.
- The shape is not applied on it.
After the step [2], the image a dataset of:
{..., mimetype: "image/svg+xml", originalMimetype: "image/gif"}.
But when replaced by the JPG image in [3], we get (in '_applyOptions()')
an image with the following dataset:
{..., mimetype: "image/jpeg", originalMimetype: "image/gif"}
This incoherent state is caused by the fact that the mimetype from
attachment will be added on shape image in loadImageInfo(), which
affects the result of '_isImageMimetypeSupported()' method
(image is considered as a .GIF), and as a consequence, the shape
won't be applied.
We already have code (in '_onImageChanged()' method) to fix mimetype
in this case, but the goal of this commit is to move this code to
'_loadImageInfo()' to prevent this kind of incoherent mimetype values.
IMPORTANT: after this commit, the right mimetype value for GIF images
is passed and shapes cannot be applied on them (shape data will be
removed from non-supported images)
task-2578242
closesodoo/odoo#72639
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Added documentation to the methods of the ImageTools SnippetOption.
Also, removed unnecessary config from the transform method, which was
specific to the wysiwyg transform method to allow for reset on double
click.
The ImageTools transform and crop options now correctly set their button
to active or not.
Two reset buttons are added next to the transform and crop buttons,
visible when a transformation was made on the image.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
closesodoo/odoo#74592
X-original-commit: fc3706a0736c2c76dfd1a261a1455146b1699ce7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds two events to either enable or disable and cancel
loading effects at the SnippetsMenu level.
This is useful if we want for a snippet to be edited without showing the
loading effect. In the context of this PR it is used for image
transforms.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
X-original-commit: c45896fdd5a89e7954d8afeeb89ff51bb16ab438
Before this commit, the editor overlay was not correctly applied to
rotated elements.
After this commit, we apply the transformation of the element to the
overlay. For that, we needed the original top and left offsets of the
element. These values are obtained by cancelling the transform before
computation, and reapplying it after application to the overlay.
With these original top and left values and the transform property also
applied to the overlay, we are able to display it with the correct
rotation over transformed elements.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
X-original-commit: 8c7815bc02b06914966aca524cf95675706944b8
REASON FOR THE FIX
To correctly display the overlay over a rotated element, we need to
reset the transform of the element, to be able to apply it on the
overlay.
Changing the style of the element in the SnippetEditor cover method
would trigger a DOM mutation, which will result in setting the
odooEditor observer unactive.
The issue was that flushing the observer (when setting it unactive)
would always send an event observerApply, even if no record was
processed.
It was an issue as the SnippetsMenu was triggering a content_changed
event at the reception of this event, which would rerender the
SnippetEditor overlay cover (and create an infinite loop of events).
SOLUTION
To avoid that, the observerApply event is sent only if records were
processed.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
* Remove AST in favor of pure Pyhon. This should make it easier for
developers to understand and create new directives because they do not
need to know AST.
* Remove `t-call-options` as it has been merged into `t-options` for more
consistency. Support for t-call-options is retained.
* Use generators for lists. This increases performances as the rendering
can be sent directly without having to wait for the creation of the
entire list.
* Optimize expressions runtime computation by pre-computing the static
parts.
Example:
'<' + 'div' + '>' + '<' + dynamic_value + '>'
Now compiles as:
'<div><' + dynamic_value + '>'
Trying to delete forward a non editable was erasing the first
character of the non editable.
Trying to delete backward one character after the contenteditable false
made the cursor jump before the contenteditable.
closesodoo/odoo#74623
X-original-commit: 9b7d9ad3771579ccb60a1be526f5d7571f64e638
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
The generator was quite confusing and also
did not provide enough flexibility for when to
stop traversing and under which condition it is
going down the tree.
This refactor was necessary for a future commit
that require to use the new parameters `isNodeDescendantTraversable`
and `stopFunction`.
X-original-commit: c8d44120b49ac967ac12f3715bdaf83cdff3c4c6
Progress bar on image upload was introduced with #65828 in saas-14.3.
Since, it has been broken in saas-14.3 with 3765ac1 which broke the flow for
image unrecognized by PIL, see the other commit of this PR.
It was also completely broken in master (saas-14.5) with the wowl refactoring,
where no progress bar were shown at all. It would show empty toastr.
This was fixed with #74027
This commit introduces a complete testing suite for that progress bar:
- Single image upload
- Multi image upload
- Success upload
- Unsupported error
- Unrecognized error
task-2607393
Closes#74122closesodoo/odoo#74454
X-original-commit: 381d432faf8d19e71ff1d63c29a14064a6d7f57f
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Since 3765ac1f1f16, uploading an image not recognized as such by PIL would not
behaves as it should.
Step to reproduce:
- Enter edit mode, drag & drop a snippet with an image
- Double click on the image to open media dialog
- Upload a local image of type `.webp`
- 2 toaster are shown:
1. A progress bar toaster with a generic message "File could not be saved"
2. A generic warning toaster on top of the previous one with the correct
error message "[..] format is not supported. Try with: .gif [..]"
Instead, only the progress bar toaster should be shown, and the error message
should be displayed in it.
task-2607393
Closes#74122
X-original-commit: c143e7d27ce25c88854fc3c2980f399add848cb3
This commit adds an option to disable horizontal scrolling in the
smoothScrollOnDrag feature options and use it when dragging and
dropping a snippet into the editor to prevent the wrapwrap from
scrolling horizontally when an element overflow the page (e.g. an
animated element).
task-2215118
closesodoo/odoo#74518
X-original-commit: fdbc109780f336c4b7dcac31585beaad682e029a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The goal of this commit is to add a "Python version" of the
shape-on-image feature using a controller.
Since the whole logic to apply shapes on image is JS-based, we need
to use this URL (just like for background shapes) when we want to add
a shape by default on images in themes. When the configurator replaces a
snippet image (which the theme defines to have a shape), the shape
option should still be applied on the new image.
On the JS side, loadImageInfo() is overridden in order to mark
images (with theme default shapes) with corresponding attachment
data (original-id, original-src, mimetype).
Here is an example of the minimum xpath required to add a shape on a
snippet image in a theme:
```
<template id="s_image_text" inherit_id="website.s_image_text">
<xpath expr="//img" position="attributes">
<attribute name="src">/web_editor/image_shape/website.s_image_text_default_image/web_editor/solid/blob_1_solid_rd.svg?c2=o-color-1</attribute>
<attribute name="data-shape">web_editor/solid/blob_1_solid_rd</attribute>
<attribute name="data-original-mimetype">image/jpeg</attribute>
<attribute name="data-file-name">s_image_text.svg</attribute>
<attribute name="data-shape-colors">;o-color-1;;;</attribute>
</xpath>
</template>
```
task-2593454
closesodoo/odoo#73938
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
Provide the user with an option to hide or display a section tag
depending on the visitor's location (if geoip enabled), language,
utm_medium, utm_source and utm_campaign.
Users can use a M2M widget to select different records. These will be
used to create a CSS selector on save that will hide the section tag
depending on the various options they selected.
This CSS selectors will be applied, as well as various data attributes
when the page loads to hide the targeted tag. All of these operations
are handled client side.
The geoip country had to be added to the session for the feature to work
with countries.
Part of https://github.com/odoo/odoo/pull/67140
task-2381049
closesodoo/odoo#67140
Related: odoo/enterprise#19907
Related: odoo/upgrade#2658
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
ISSUE
Since 14.4, dropping the image gallery to a website was causing a
traceback.
CAUSE
The bug appeared when new options were added to i.fa elements (such as
Alignment, Shape, Padding). It was an issue for the image gallery as in
the start method of the snippet widget, o_indicators_left and
o_indicators_right elements are removed if not necessary. They are
removed and not only hidden in order to keep the snippet responsive.
In that situation, there was a concurrency issue, as an editor of a
child snippet removed from the DOM (here in the chevrons, removed in the
start method of the parent snippet) was created and initializing options
for an element that was not there anymore.
SOLUTION
When a snippet is dropped on a page, we wait for its options to be
created before starting its widgets.
task-2604383
closesodoo/odoo#74422
X-original-commit: 60d7bf6d7daea83db9332b4fc47a4ac6892d21d7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
In odoo/odoo#72675 the new services were made available in the frontend,
and calls to the legacy notification services were redirected to the new
notification service. However, some of the behaviour of the legacy
notification service was not replicated in the new one, like the ability
to pass an HTML element to use inside the notification.
While html content can be passed, it is cloned, meaning that the DOM of
the element cannot be manipulated by the caller, which is what was being
done to show progress during media upload.
Although the upload progress toast looks like a notification, it's
hardly a standard notification and adds a lot of behaviour, because
manipulating DOM directly when it is managed by owl cannot be done
safely, it has been decided to simply make it its own widget separate
from the notification service, which can manipulate its own DOM freely.
task-2607393
closesodoo/odoo#74027
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
On windows when you copy paste text in and into Odoo (for example in the description when creating a ticket) a traceback occurs.
There is an isWhitelist function which verifies that a node is indeed in the authorized items via the following instruction
`item.matches (CLIPBOARD_WHITELISTS.nodes.join (','))`
But on windows there is a comment node containing `<--StartFragment-->`
Here is the clipboard data on linux and on windows for the same copied text (Hello):
- Linux
```
<meta http-equiv=\"content-type\" content=\"text/html; charset=utf-8\">
<span style=\"color: rgb(102, 102, 102); font-family: "Lucida Grande", Helvetica, Verdana, Arial, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;\">Hello</span>
```
- Windows
```
<html>
<body>
<!--StartFragment--><span style="color: rgb(102, 102, 102); font-family: "Lucida Grande", Helvetica, Verdana, Arial, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">Hello</span><!--EndFragment-->
</body>
</html>
```
Except for this additional comment on Windows, the `.matches()` method does not exist.
This PR uses the `Array.includes` function on the item's `nodeName`, which should work in all cases while keeping the same behavior.
opw-2591597
closesodoo/odoo#74029
X-original-commit: 41802bc518b4bcd1c71d8659ac560cb748befd95
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
qsm-odoo