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
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>
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>
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>
When the selectedChildren array was empty it generated an error and a traceback appeared in Odoo.
Task-2580158
closesodoo/odoo#73846
X-original-commit: 65b8ffb56485895cc08be024b18928d1e51949b7
Signed-off-by: Antoine Guenet <Zinston@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#73952
X-original-commit: 9478cfa0942ad2aee69de197024660cdd6f6c739
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
ISSUE
When selecting colors options from the editor toolbar on a html field,
the colorpicker was not displayed under the toolbar.
CAUSE
Before this commit, the colorpicker dropdown position was computed with
top, bottom and height css properties.
After a new colorpicker was introduced with multiple sections of
different sizes, the size of the dropdown-menu could not be fixed
anymore and [1] broke the existing computation to display the dropdown
above or below the toolbar.
SOLUTION
Using bootstrap dropdown 'dropup' class instead of top, bottom and
height css properties.
[1]: https://github.com/odoo/odoo/commit/96ab729850983162a0039e40c77537ef65cd039eclosesodoo/odoo#73947
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When pasting text containing url, the url was pasted twice.
One being simple text and the other one being a link.
Task ID: 2602785
closesodoo/odoo#73709
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Inserting text that contain multiline does not work.
One "\n" is removed.
Two "\n" become only one.
Task ID: 2602881
closesodoo/odoo#73835
X-original-commit: 89450137653526d9947bc21410cc4163e8b9b440
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
When using drag&drop for adding elements to a product's page through
the website edit mode, users sometimes find the feature confusing to
use. Two examples of said confusion can be seen here:
- https://dashboard.userbrain.net/shared/qwl65bqlk6jg?t=404
- https://dashboard.userbrain.net/shared/k796mnj95pow?t=258
The suggestion for improvement was to reduce height and opacity for
the top and bottom droppable zones (available on all products), and
make any element not explicitly dropped in those zones go to the
zone below the product, available only on the product's own page.
This behaviour is extended to be more generic and is applied when
a dropzone has the class oe_structure_not_nearest, which excludes
it from the nearest search, unless the element is dropped explicitly
in a zone that has the class oe_structure_not_nearest.
task-2581641
closesodoo/odoo#73580
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Since their convertion to "snippet" options with [1], the media options
were not handling previews correctly anymore, but also were recoding
their entire logic for each of the options instead of using generic
methods like selectClass or selectStyle.
One example of a bug was that previewing the 25% width option on an
image, not enabling it and saving the editor forced the image to a fixed
px width (its original one). Changing that image to another would keep
that wrong fixed width.
Note: this reveals that selectClass and selectStyle need more parameters
to handle all of this correctly. Most was added as a specific override
for these features but it could be handled even more generically.
[1]: https://github.com/odoo/odoo/commit/d934b81aaae8d68b5579d1489b1fbe8ea347b4ed
Related to task-2578242
task-2577848
closesodoo/odoo#73734
X-original-commit: f59affcdfe9529645a02680214f3d7d96ebacf6e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Sorry but not sorry, I have to fix this file's "codestyle" (unread
variable, missing or extra ";" characters, etc) post-editor merge...
hard to work inside of it in the current state.
closesodoo/odoo#73629
X-original-commit: dbf245891099b506f21a66ea8e7a9146f6c9e28b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, if the user chose the "red" color suggestion, "red"
did not appear as a custom color (but the color suggestion was marked
as selected). This made sense in the previous colorpalette widgets but
not anymore as the suggestions do not always appear in all colorpickers
anymore.
Now those colors are always considered custom when used in the page and
at worst appear as "common" and "custom" at the same time (the "common"
one being the one which can appear as selected in that case).
Part of https://github.com/odoo/odoo/pull/67545
task-2476601
closesodoo/odoo#67545
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In order to save space and gain clarity, the colorpicker elements are
now displayed in two separate tabs: "theme" and "custom".
It is still possible to display the combinations tab instead of the
theme one (for the background color option for example).
Part of https://github.com/odoo/odoo/pull/67545
task-2476601
Unbreakable elements were being considered as unremovable in some deleteBackward cases.
With these changes it is now possible to remove a unbreakble element if it is empty.
task-2580158
(cherry picked from commit 18abf537f07bd9c504dc19c3fa8eda5b1f4d4e9e)
closesodoo/odoo#73592
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Color and background-color styles on `<font>` tags were being wrongly overridden when applying another color or background color to the element.
Task-2580158
(cherry picked from commit a532d096faf55550ac6d01795aaa2b6843ebc988)
- Exclude '.o_we_pager_header' from click behaviour so clicking on the
shape dropdown does not close it if an user misclicks next to a pager
button.
- Add borders on navigation buttons in shapes option to improve
visibility.
- Cut the last visible option in the shapes list, this way the user
will understand that he can scroll.
Part of https://github.com/odoo/odoo/pull/69857
task-2431484
X-original-commit: 0d8e4368775bf7fd1aca1376e57c5847b283bded
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: web_editor
The goal of this commit is make the whole we-collapse elements
clickable for theme color palettes.
Part of https://github.com/odoo/odoo/pull/68061
task-2431484
*: web_editor
The goal of this commit is to add the "MultipleItems" option
to be able to add new elements in snippets with a list of items.
In this commit, the option is used for "Media List" & "Tabs".
Part of https://github.com/odoo/odoo/pull/68061
task-2431484
The goal of this commit is to add BS tooltips for editor
sidebar elements using "data-tooltip" attribute to select targets.
The code used to show tooltips on sidebar tab buttons is removed
in this commit since it has no effect after [1].
[1]: c71cf6c618b48da36fbc5063140703312248bc09
Part of https://github.com/odoo/odoo/pull/68061
task-2431484
The code of the Odoo editor was on another repository
and that created unnecessary overhead. This commit move
the code inside Odoo and slightly change the folder
structure.
Related PR:
saas-14.3: #73345
saas-14.4: #73348closesodoo/odoo#73272
Master: #73272
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
When starting a drag and drop of a snippet, a loading effect on the
editor panel was performed for the whole duration of the drag. Worse:
even if the drop was done immediately, the loading effect still occurred
for 400ms as it was only marked as finished after the scroll to the
dropped snippet.
The loading effect addition was in fact a side-effect of first disabling
all editor overlays at the start of the drag... but that action was in
fact entirely unnecessary because this is not possible to have any
overlay enabled when the snippet panel is opened (because opening it
already disables all editor overlays and enabling an overlay forces the
editor to switch out of the blocks panel).
closesodoo/odoo#73437
X-original-commit: adad8a33071fbbff16d78741904ec33b3595e00b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Forward-port of a commit that was wrongly forward-ported with [1], half
of the diff was lost because it landed in master before the merge of
another commit which removes what was being reintroduced here...
[1]: https://github.com/odoo/odoo/commit/e7f497b027d5931b1cf57febcab5deda573b45bbclosesodoo/odoo#73287
X-original-commit: 68d7d42cce012269342e18373a30970e2c582ba3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When selecting a "basic" color from the color picker, it was displayed
as a custom color.
It was due to the fact that the basic colors were not correctly computed
to build the existing colors: the array of the rows was used instead of
the array of the colors.
Part of https://github.com/odoo/odoo/pull/72978
task-2476601
closesodoo/odoo#73139
X-original-commit: 23b182ab1bce9a00cb75d12b0d0c504d1fe19e2f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The commit fixes the display of custom colors in the color picker.
It improves previous fix from #72294, which was not returning all
editables from the editor, thus only the custom colors of the target
were displayed.
For that the request_editable event is reintroduced at the SnippetsMenu
level.
Part of https://github.com/odoo/odoo/pull/72978
task-2476601
X-original-commit: 68d7d42cce012269342e18373a30970e2c582ba3
Emilien Durieu (edu)