On a products category page, there is an element ready to host a heading
but it's not explicitly marked as unremovable so when the user tries to
remove any snippet inside it, the heading host is removed as well. This
fixes it by using the `isUnremovable` utility function instead of simply
checking for the `oe_unremovable` class.
Steps to reproduce the issue this commit fixes:
1. Go into the website module
2. Click "Shop"
3. Click "Furnitures"
4. Click "Edit"
5. Drop a title block in "Drag building blocks here to customize the
header for "Furnitures" category."
6. Click the trash bin on your snippet to remove it.
It doesn't get removed. Well now it does.
task-3383348
closesodoo/odoo#128744
X-original-commit: d1836d2830d098e2c29cca2643b0b354859daeca
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Colors of headings are inherited between levels. (E.g. if no color is
defined for `<h4>`, it uses the color of `<h3>`)
This commit changes it so that all levels only inherit from `<h1>`.
task-3140991
closesodoo/odoo#111621
Related: odoo/design-themes#633
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor, website_mass_mailing
Because the shape is now also part of the theme options for primary and
secondary button, it does not make sense to select it when the button
is either primary or secondary.
This commit makes the Shape option shown only for Custom buttons, and
therefore also nests it under the Style option.
task-3140991
Part-of: odoo/odoo#111621
This commit reorganizes the theme options to make them easier to find.
It also adds the following options:
- 'Font size' for each of the six headings
- 'Font (family)' for each of the six headings
- 'Margins' (top & bottom) for paragraph & the 6 headings
- 'Line Height' for paragraph & the 6 headings
- Harmonize buttons options with the custom button ones
task-3140991
Part-of: odoo/odoo#111621
Protect left/right arrow key handling against an empty selection (no
previous/next character to find without a selection).
Example of steps to reproduce the issue (= lose the selection while keeping the
focus):
- create such a configuration in the editable:
```html
<p [p1]><br></p>
<table>...</table>
<p [p2]><br></p>
```
- Place the cursor inside [p2] and delete the node with `CTRL + BACKSPACE`
- The cursor should have moved in the last cell of the table
- Place the cursor inside [p1]
- Start the table deletion process with `CTRL + DELETE`
- The table should be selected, as well as [p1]
- Type `DELETE` (this time without CTRL) a second time.
- The table and the paragraph are replaced by a single `<br>` node and the
selection is lost.
- Type `LEFT/RIGHT ARROW KEY`
=> Traceback
- A paragraph is inserted again when clicking in the editable afterwards
- The isolated `<br>` node stays until it is deleted by pressing on `DELETE` in
the last (reinserted) paragraph.
Typically, any other case where the selection is manipulated programatically and
not put back in the editable (be it through a bug, or because a target
selection has become obsolete and can not be found) would produce such a
taceback.
task-3425395
closesodoo/odoo#128631
X-original-commit: 2ee6e08f42f913e3102ca7340bb40b0203432b67
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Fix `deleteBackward` and `deleteForward` processes around nested editable
zones, i.e.:
```html
<div class="odoo-editor-editable" contenteditable="true">
<div class="nesting" contenteditable="false">
<div "nested" contenteditable="true">
<p>content</p>
</div>
</div>
</div>
```
- `deleteBackward`, when used:
- just after the nesting element; should remove the nesting element
- at the start of the nested element; should do nothing
- `deleteForward`, when used:
- just before the nesting element; should remove the nesting element
- at the end of the nested element; should do nothing
This commit also move some existing tests that were related to the handling of
non-editable elements in their correct `describe` section.
task-3425395
X-original-commit: a52deabecef8a5d489743b0ae07d4d32302fd76e
Part-of: odoo/odoo#128631
This commit fixes the method so that it is not allowed to probe outside the
boundaries of the `root` editable element, no matter the value of `parentLimit`.
This also allows to not specify `parentLimit` (becomes the editable element by
default).
task-3425395
X-original-commit: ffeb1abcc675dd05fb9546e39aac4498e510bbbc
Part-of: odoo/odoo#128631
The commit [b7b05a2] added a `PLACEHOLDER_TEXT` constant to consistently
change the text in `we-toggler` when no element is selected from "/" to
"None", but forgot to update one comparison.
Steps to reproduce the issue:
- Drag and drop an "Add to cart" button
=> The "Product" toggler menu shows "None" when nothing is selected.
With the updated code, it says "Choose a record...".
- Type a partial name (e.g. "desk") in the search box and press enter
=> It still shows "None".
It should select the first item available in the list. In this case with
demo data, "desk" would be "[FURN_118] Corner Desk Left Sit".
[b7b05a2]: https://github.com/odoo/odoo/commit/b7b05a2d1c1d5
task-3266751
closesodoo/odoo#128617
X-original-commit: f0f9094334e5a09b89c1fc50865c9da339d0605d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Error responses are already ignored, but connection errors would blow
up the entire thing, which breaks `test_resequence_images` (and
possibly others).
Part-of: odoo/odoo#128497
Since [1] dropped images are saved as attachments.
When such an image is a WEBP, its pre-computed resizes and conversions
to jpeg are not generated.
This commit adds the behavior of saving an `o_modified_image_to_save`
when a `o_b64_image_to_save` is a WEBP.
[1]: https://github.com/odoo/odoo/commit/3bbce756c69a206d07abd31059f0392c26b36096
task-2774352
Part-of: odoo/odoo#85494
`libwebp` cannot be used to perform resize operations on webp images on
the server.
This commit uploads all resizes of webp images whenever a webp image is
uploaded:
- resized to any smaller size in 1024, 512, 256 & 128,
- each size converted to jpg as well to be usable in `wkhtmltopdf`.
When an Image field requires `_imageProcessing` to resize a webp image,
it retrieves the pre-resized image instead of running through the
Pillow toolbox.
Pre-converted images are stored as `ir.attachment`s with:
- `res_model` = ir.attachment
- `res_id` = id of transformed attachment
i.e. id of original size webp for resized images
id of webp for jpeg-converted images
- `description` = "format: image/jpeg" for jpeg conversions,
"resize: [size]" for resized images.
task-2774352
Part-of: odoo/odoo#85494
The library used to generate PDFs does not support the WEBP image
format. For those images to be included in reports, they need to be
converted. For security reasons, this conversion cannot be done on the
server, therefore it was decided to keep an already converted copy of
such images.
This commit converts uploaded WEBP images to JPEG and uploads them both
so that the report generation can use the JPEG instead.
task-2774352
Part-of: odoo/odoo#85494
Before this commit two options of images are named "Width":
- the one that adjusts the image resolution
- the one that changes the `width` CSS property
This commit makes the following changes:
- the option about the image resolution is renamed to "Format"
- the "Format" option combines the image resolution and the file format
- an option item gives access to the initially uploaded file format and
resolution
- for all sizes the image format is set to `image/webp`
- for the uploaded size, an `image/webp` version of it is available too
- upon upload, the default selection is an `image/webp` version of the
image
task-2774352
Part-of: odoo/odoo#85494
*: mail, mrp, test_website, web, web_editor
Before this commit '.webp' images could not be used in odoo.
After this commit '.webp' images can be uploaded to odoo.
- can be used in image field
- can be used in HTML field image
- can be used in mails and website
- can be transformed (shape mask, filter effect, crop, rotate, resize,
adjust quality)
task-2774352
Part-of: odoo/odoo#85494
Before this commit:
When user try to create link with / it is not recognized as a link.
After this commit:
Now when user try to create link with / it is recognized as a link.
Task-3347775
closesodoo/odoo#127842
X-original-commit: e99ccfa1ed7aa338f99c4142d109b2860cc9be4a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since the edited website pages are inside an iframe, the options panel
cannot base its display on the CSS rules of the page. When changing the
theme colors, only the edited page's CSS is reloaded, not the option
one. Because of this, the background shapes are displayed using an
obsolete color palette inside the options panel.
This causes colors to be forced on background shapes within the iframe
because their default colors do not match the ones inside the options
panel when different theme colors are set. Once forced, the colors of
the background shapes within the content do not follow the theme
palette changes anymore.
This commit forces the background shapes displayed in the options panel
to use the current palette.
This is done by recovering the current edited page's shape background
images from the CSS rules. This approach was chosen as opposed to
adding a `d-none` version of the shape `div` to the edited page and
getting the background image from its computed style.
This fixes the color comparison between the background shapes of the
content and the ones of the options panel, thus not forcing colors if
the theme colors are used.
Steps to reproduce:
- Edit a website page.
- Drop a "Banner" block.
- Enable background shapes.
- Go to the theme tab.
- Select a different theme color palette.
- Select the "Banner" block.
- Open the "Shape" option's menu.
=> The shapes were displayed with the old color palette and if selected
were applied with the old color palette.
Additionally, to avoid a race condition when leaving a theme color
picker by either clicking on the BLOCKS tab or re-selecting the
snippet with a shape, a re-rendering of the existing snippet editors
is requested and the shape cache is invalidated if the palette has
changed in the meantime.
task-3370939
closesodoo/odoo#127951
X-original-commit: c511e100cad2febc0ebb9ce61b5eb52232e60f7d
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Before this commit the function getContentEditableAreas passed in options
was not correctly called.
The OdooEditor which receives it too passes itself to it.
This commit corrects the call in Wysiwyg to that function and passes the odooEditor instance
Part-of: odoo/odoo#126963
Before this commit, whenever some nodes had some attributes similar
to QWeb (t-if, t-else, t-out etc....) the QWebPlugin's style applied.
This was unpractical when that style needed to be customized.
After this commit, the HtmlField add a class signaling that it should apply that style.
Part-of: odoo/odoo#126963
When popping the color selector of the wysiwyg, sometimes the OdooEditor
returns an error code instead of a list of elements.
In that case, the code crashed as it expected a list (implicitly, by calling Array methods)
This commit accounts for that and tests whether the return is an Array.
Part-of: odoo/odoo#126963
The previous comment referenced in this commit is no longer reflects
the code section that follows it, as it has undergone modifications in a
previous commit [1]. The code segment responsible for pasting image and
video has been relocated and is no longer positioned beneath the
comment, rendering it obsolete.
The comment has been reworded to accurately reflect the content of the
code section that follows.
[1]: https://github.com/odoo/odoo/commit/e53962594c5baaa6d644161fef7e314497dc190fclosesodoo/odoo#128025
X-original-commit: 7929389a1c2f9e6cfdf34de813abc6f8c90b8371
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when pasting the clipboard content as plain text
(CTRL+SHIFT+V), line breaks ('\n') got converted to `<br>` elements.
This made the behaviour of the pasted section inconsistent with the
other parts of the edited document, in which line breaks are obtained
via paragraphs (`<p>`). In particular, when converting the pasted
content to a list, the whole multi-line content would be added to a
single list item, instead of one item per line.
This commit makes sure pasted line breaks result in new paragraphs.
task-3323873
X-original-commit: 18026ed2d4efaa6323e38b53eced77b1db666453
Part-of: odoo/odoo#128025
When an HTML field is empty and no block can be dropped inside it, it
is very difficult to locate or even notice.
This commit adds a placeholder text inside sanitized HTML fields.
Steps to reproduce:
- Install website_crm_partner_assign.
- Go to a contact without website description.
- Go to its website page.
- Edit page.
=> The `partner.website_description` field is difficult to locate.
task-3293600
closesodoo/odoo#120588
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: web_editor
When an HTML field sanitizes its attributes, it can still be filled with
HTML content (blocks, styling, power box commands) using the website
builder. This causes problems because those elements can then be broken
by the sanitizing.
It is possible to break elements so badly that the page cannot be
edited anymore to fix the problem.
This commit prevents the user from dropping snippet blocks inside the
content of such fields.
Steps to reproduce:
(Unless `slide.slide`'s `description` becomes
`sanitize_attributes=False` in the meantime.)
- Edit a single Course's slide.
- Drop a Carousel into the description field at the bottom.
- Save.
=> Carousel did not work.
Worse:
- Instead of the Carousel, drop a Countdown.
=> An error happens on each page reload, and the edit mode cannot be
reached anymore.
task-3293600
Part-of: odoo/odoo#120588
Ensure to close all connections before setting the flag that prevents any
notification (notably the notification to disconnect).
task-3392096
closesodoo/odoo#127953
X-original-commit: 905307e8d08ed3595a1f965fe846f1fe6ebe9d5c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when opening the media dialog, the optimized images
would be fetched too.
An optimized image is an image related to an original one which received
some modification (crop etc).
Those optimized images are hidden by default, and can only be shown when
toggling the "Show optimized" option, which can be shown only in debug
mode.
So, fetching those images outside debug mode is:
1. Useless, as we don't do anything with those and never show them
2. Buggy sometimes, as a full patch of "Load more" images could be
composed of only optimized images, meaning the "load more" will
actually look like it did nothing, as all received images are (and
will remain) hidden.
There is a tiny exception: if the edited image is an optimized one, we
still need to fetch it's attachment so we can show this image in the
media dialog as selected.
This fix thus filter out all the optimized images (except the one from
the explained exception) from the `search_read()`.
opw-3372811
closesodoo/odoo#127853
X-original-commit: 24177b5e2b56a94a51ac4b922d555beda9347611
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When converting a row with items that are supposed to be stretch-aligned
we need to set each of its column's height. However this failed when
the row contained less than two columns.
opw-3371134
closesodoo/odoo#127813
X-original-commit: 7df4cc0d9aaccf0dabcc4a7863549b276efaa403
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
- The icon of table menu is fa-bars which looks like drag 'n' drop handle.
- Menu width is not 100%.
After this commit:
- Changed the icons to fa-ellipsis-h and fa-ellipsis-v.
- Made the menu 100% width so it's easier to intuit it's not a drag 'n'
drop handle.
Task - 3297710
closesodoo/odoo#127843
X-original-commit: 479c0a87b0b676f5fa9252efdef3ede99f6d7ea7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
- Drop a Title block in a webpage.
- Select text.
- Set the text color to a custom gradient. (Not the background color)
- Hover a gradient preset.
- Leave the gradient preset.
gradient color applied on the background.
In this commit,
1. Modified the condition which was blocking some mutations from being
processed. Before this commit condition got executed successfully on an empty
array(`excludedClasses`) too, which should not be.
2. Introduced new tests which were breaking before this commit to preventing
them from breaking in the future.
task-3120090
closesodoo/odoo#127810
X-original-commit: 994fe756db8f1a45ef864cb7848644ea204539b7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Divyesh Vyas (divy) <divy@odoo.com>
Commit [1] addressed the following situation: when we have a parallax on
an element, it adds the background on a `<span>` child of said element
instead of applying it directly on the element. Retargeting the `<span>`
is needed to display all the options linked to the background image.
Following [1], building blocks whose children are allowed to have a
background image are also applied their 1st child's background when one
of their children's background is modified. This happens because, when
changing the background of a child item, `BackgroundOptimize` is called
both on the child and on the main snippet due to
`_onBackgroundChanged()` bubbling up and `_loadImageInfo()` targetting
any child in the tree with the class `.oe_img_bg`.
This commit prevents `_onBackgroundChanged()` from bubbling up and
modifies the behavior from [1] by making sure the element identified as
the target within `_loadImageInfo()` can only be either the original
target or the parallax element.
Steps to reproduce:
- Drop a carousel building block
- Change its style to bordered
- Change the background image of the 2nd slide
=> the background of the entire snippet is also changed. It is then
impossible to remove the image on the snippet.
[1]: https://github.com/odoo/odoo/commit/31ba906
task-3349669
closesodoo/odoo#127756
X-original-commit: ab0ae8dadf55baa258d733835acc3a12771932be
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Steps to reproduce:
- Drop a block, hide it on desktop and save
- Add a second language and click on translate
=> This raises an error.
The bug happened after the forward-port of [1] to 16.3, because
`_updateInvisibleDOM` was called prior to `_loadSnippetsTemplates`: it
then tried to `_createSnippetEditor`, requiring `templateOptions` while
they were still undefined.
opw-3383659
[1]: https://github.com/odoo/odoo/commit/959ea3d361fclosesodoo/odoo#127139
X-original-commit: c92ea9f10cdd38b275157e1ba7e79b84e3e45cbb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before the task
when the default language for a website is not en_US, and users try to
edit_translations from the website, all terms are marked "translated"
because odoo adds
`data-oe-translation-state="to translate"` if the term is not extracted from
the en_US value and is the same as its en_US term
After this commit:
if the record's bounded website's default language is lang_base
odoo adds
`data-oe-translation-state="to translate"` if the term is not extracted from
the lang_base value and is the same as its lang_base term
closesodoo/odoo#127468
Task-id: 3344973
X-original-commit: 7c20510bda2f1312a9392df445ee38aea7b2267b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
Before this commit:
EmojiPicker was in separate group as widget.
After this commit:
EmojiPicker should be grouped together.
task-3414175
closesodoo/odoo#127561
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Purpose:
This commit adds Emoji_picker functionality to the web_editor,
allowing users to conveniently add emojis to their text and
improving the overall user experience.
Specifications:
Now we can insert emoji in web_editor using `/emoji`.
Task id: 3253958
closesodoo/odoo#125137
Related: odoo/enterprise#42772
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
When the `s_nb_column_fixed` class is present on the row, it should not
be possible to change the number of columns in the "Columns" option (the
option is supposed to be hidden).
However, since commit [1], this behavior is broken. It happened because
the "Columns" option needs to always be displayed in order to display
correctly the "Grid" option and this class was therefore ignored.
This commit restores this class behavior by hiding only the widget
changing the number of columns and not the complete "Columns" option, in
order to still be able to toggle between the grid and the normal modes.
[1]: https://github.com/odoo/odoo/commit/84d684d8bdf43d3db11defd8174dee44775085c2
task-3369847
closesodoo/odoo#127144
X-original-commit: 8148521f052268877f36947e0533843a25d17b83
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a URL is entered to add an attachment through the media dialog
a URL attachment is created. If the source material is removed the
attachment will not be reachable anymore.
This commit fetches the data and adds it as an uploaded file when
adding a URL image in website.
If the image binary cannot be fetched by the client (e.g. CORS), the
old approach is used instead.
This commit also adapts test tours which relied on the image's `src` to
verify if the entered URL had been taken into account by making them
rely on the image's `data-original-src` instead.
task-3129360
closesodoo/odoo#118877
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Drag and drop several snippets onto a web page in edit mode to make
the vertical scrollbar appear.
- Drag and drop a popup onto the page.
- Drag and drop snippets into the popup so that the height of the popup
exceeds the height of the viewport.
- Try to scroll the popup downwards by clicking and dragging on the
scrollbar (not using the mouse wheel).
- Bug: the page is scrolled instead of the popup.
Note: This bug occurs in Chrome (not in Firefox).
This issue occurs because two scrollbars are present at the same
location (one for the page and one for the popup) and they overlap each
other. Normally, Bootstrap removes the scrollbar from the body when a
modal is opened, and this behavior was adapted for the #wrapwrap element
with this commit [1]. However, when transitioning to Bootstrap 5, the
code that overrides Bootstrap was removed instead of being adapted (this
was done in this commit [2]).
In later commits [3] and [4], we continued to remove code that updated
the scrollbar based on the opening of a modal because this code was
causing errors due to the fact that it was incomplete without the part
removed by commit [2].
This commit restores the original behavior (before the deletions made by
the aforementioned commits) by restoring the missing code and properly
adapting it to Bootstrap 5.
[1]: https://github.com/odoo/odoo/commit/9cf8b97fe40444b44ebb6e6fb992bc658a087d32
[2]: https://github.com/odoo/odoo/commit/0b94da214b7017e8580e671cbaa68ade6de2fbc7
[3]: https://github.com/odoo/odoo/commit/cb7cf77ed080e86f800af61c9a3dc4ad36ad6cfb
[4]: https://github.com/odoo/odoo/commit/51939d09f84579f61f1ff77aacd754beba036dc2
task-3102275
closesodoo/odoo#126709
X-original-commit: 0e75f1c01ca4fcc3eb483a7256bcf72b2bca39c3
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
The code snippet removed by this commit had no useful effect, as
`selection.addRange(range)` a few line above triggers
`OdooEditor._onSelectionChange`, which repositions the toolbar
elsewhere.
The result was a "glitch": the toolbar would briefly be displayed over
the top left corner of the media before finally being displayed above
(or below) it.
This commit removes such undesirable effect.
task-3347942
closesodoo/odoo#126445
X-original-commit: f0272411f6cab059cc8bc2ceed37d9ce59ffe80c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Before this commit the position of the arrow was incorrect when the
editor is inside an iframe.
For the calculation of `arrowLeftPos` we need the difference between
the selection rectangle border and the toolbar's left position.
While `correctedSelectionRect.right` is relative to the current iframe's
borders, `left` is relative to the top document's window, as it has been
offset with `parentContextRect.left`. We need both values to be relative
to the same referential in order to make this calculation make sense.
task-3347942
X-original-commit: 8bad3a3fb00d59498455205e8d286a38adaf1335
Part-of: odoo/odoo#126445
Before this commit, an error in the toolbar position happened when the
editor was inside an iframe and the iframe's window had scroll bars.
Steps to reproduce:
- go to the Market Automation app (enterprise edition)
- create new campaign
- add new activity
- create a new mail template by typing a name and selecting "create and
edit"
- select the "plain text" theme
- add a lot of content in order to have the scroll bars
- scroll down
- select something to display the toolbar
The `scrollX` and `scrollY` variables in `_positionToolbar` are ment to
correct the floating toolbar position in case the document in which the
toolbar is mounted has some scrolloffset.
As the floating toolbar is always mounted on the body of the top
document, this is the document to watch for scroll offsets, and not the
inner document when the editor is mounted inside an iframe.
task-3263463
X-original-commit: fb080218def7c47e7b96cf284d613fc03b8325f6
Part-of: odoo/odoo#126445
Previously, copy-pasted tables from other spreadsheet editors did not
keep their style once in our editor. This is simply because the way
style information is embedded in the HTML is not inter-compatible across
editors.
Google Sheets places all the cell's style on <td> tags, which can't be
styled in Odoo 15. This has been fixed by moving all possible style
attributes to a direct <span> children, which is created if necessary.
In Odoo 16 and forward, the styles are left on <td> tags.
Microsoft Excel defines the style in the standard <style> tag (in the
<head> of the HTML), using custom CSS classes on tags. We parse that
<style> and copy it to the style attribute of <td> tags with matching
classes. Those styled <td> tags are later handled as described above.
Libre Office makes use of deprecated <font> tags and its specific
attributes. Those attributes are mapped to equivalent values for the
standard style attribute. It also places eventual <s> and <u> tags as
parents of <font> tags, which means the strike or underline doesn't
inherit the style of the text. We invert those for nicer styling as is
the default in our editor.
Tests have been added for each of those aforementioned Spreadsheet
editors, ensuring we save exactly their style values that are compatible
with the Odoo editor, nothing less and nothing more.
Note that for v15.0, background color of cells is discarded as it is not
supported in our own editor. For v16.0 and on, it is supported and kept.
Task-3255167
closesodoo/odoo#126248
X-original-commit: 8b0f7e32ac73636cd3ce142dd44fe921fcc4c849
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Previously, when copy-pasting HTML with styles on styleable tags, those
styles could still be removed by the editor if they had a default value.
This was supposed to be a way to keep the DOM clean and lighter.
However, styles with default values still serve a purpose when
overriding non-default values inherited by their parents. Therefore,
removing them was a conceptual mistake.
One example in the editor where this purpose can be served is in
tables where spans can override the style of the cell or parent span.
This commit ensures we no longer remove style attributes because of
their default value.
Task-3332955
X-original-commit: 39acbc23929f6004e6cb5fe1059ccabf87799e8c
Part-of: odoo/odoo#126248
This reverts commit [1]. It broke all snippet button colors, making
them invisible. Besides that, the fix seems not obvious to make properly
and would thus require some more testing, thus the need of reverting
this urgently.
There is probably more things to consider when remaking that fix:
- mass_mailing scss code in web_editor should not be a thing. Even if
the comment about variables not being accessible is true, there are
definitely other ways to do it (make them accessible, add those rules
generically with a custom selector and fill that custom selector when
mass_mailing is installed, etc etc)
- More than scss code, we really do not want mass_mailing *CSS* rules
in website pages, especially in that code that generates *many* CSS
rules. Of course web_editor.common.scss contains many things that
should not be there and mass_mailing has probably already a lot of
useless code in the frontend assets... but the goal is to fix those
inconsistencies in the future.
- The fix impacts buttons which are not hovered while the goal seemed to
be to have their hover style disabled...
- The fix impacts buttons which are in o_ccX environments only (?) but
seemed to be about disabling all hover styles.
- Much doubt on the need of an at-root instruction, especially since
it creates a bug in frontend pages without o_mail_wrapper containers
so it probably does not work as intended.
- The fix should probably not be about overriding/duplicating the CSS
rules but rather post-processing the mass_mailing assets to remove all
hover rules. I guess it is even possible to do in JS removing the
:hover CSS rules, at worst by moving all CSS rules to inline <style>
rules or something like that.
Note: the main bug about button text being invisible is apparently from
16.0 and up only. This still reverts the code at its root (15.2) for all
mentioned reasons above.
[1]: https://github.com/odoo/odoo/commit/55aff2dcdf5537e16bdaf01ee68d776510572171
task-3376724
closesodoo/odoo#126116
X-original-commit: a6e861b19002b02e369d6b7c1ed5fe1401e77028
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds a margin top on the we-alert to make it prettier.
Otherwise, the alerts are too close to the elements above them.
task-3302433
closesodoo/odoo#120874
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
*: web_editor, website
The goal of this commit is to add the reorder option on the carousel
slides. Because the option is now shared between the "Carousel", the
"Image Gallery" and the "Images Wall" snippets, a common super option
(`GalleryHandler`) has been created to handle this reordering.
task-2930786
closesodoo/odoo#117369
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit, website and email editing was very limited on
devices that have a touchscreen. The blocks tab, the we-lists, ... were
unusable.
Example of issues (on a device that has a touchscreen):
- The users cannot drag & drop snippets in the page.
- The users cannot reorder the values of a multiple checkboxes field.
- ...
This commit allows to handle touchscreen events by translating them
into mouse events to allow users to fully use the editor.
opw-3195487
closesodoo/odoo#125976
X-original-commit: 142684dbe7e5c9d5c5fc1baa00b1027367a45213
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Fixes an issue introduced in a forward-port:
https://github.com/odoo/odoo/commit/db0c092973f480f3336a44e5f6868dc5a79f0e3a
The listener was not set on the correct target, `historyStep` event is triggered
on `odooEditor` and not `odooEditor.editable`.
This meant that the FormStatusIndicator was not properly notified and
the `save/discard` button was not visible after an editor `historyStep` on form
views
task-3373603
closesodoo/odoo#126006
X-original-commit: f76585530d7387ff2f44639252829aa4546cea1b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When converting inline svg shapes to images, we checked if the source
ended with ".svg", which is not enough, as it can include query
parameters (eg, .svg?color=red). We now simply check if it includes
".svg" instead.
We also need to make sure we didn't make a clone of the image in an mso
before converting it, as the source wouldn't get converted in the mso.
closesodoo/odoo#125839
X-original-commit: 3e9fa219ce612875aa034d95080f9cca1f972d27
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
After preventing "async" code on link tools update in [1], the
`'link_tools'` test is still failing because of another race condition
issue:
The click on "save" after setting the link style to secondary triggers
an event handler that destroys the link tools widget (see `Wysiwyg` >
`destroyLinkTools()`), leading to calling the `_removeHintClasses()`
method first (both `_addHintClasses()` and `_removeHintClasses()` will
disable the editor observer while adding / removing the link hint
class to prevent their mutations to be recorded...).
Since the observer is inactive, the changes made to the link using the
link tools will not be processed, and the block will not be set as
`.o_dirty`.
As mentioned previously, (and starting from [2]) the editor observer is
inactive (while handling the `.oe_edited_link` class) in order to
prevent recording the mutations... But since [3], the editor had the
ability to prevent some classes (including `.oe_edited_link`) from being
taken into consideration in the `filterMutationRecords()` method...
The goal of this commit is to fix this race condition issue by simply
keeping the observer activated while handling the link hint class...
Remarks:
- These changes are supposed to fix the `link_tools` test that fails on
16.0+, but 15.0 was targeted here since the `.oe_edited_link` class is
ignored by the editor starting from 15.0 and also to prevent any future
issue linked to disabling the observer...
- Adding and removing the `active` class should not affect the history,
since it targets the `linktTools` toolbar button...
[1]: https://github.com/odoo/odoo/pull/109250/commits/f42715fdc89a6a88446c5f88ecec29e6a9c96fe1
[2]: https://github.com/odoo/odoo/pull/90064/commits/26377710a6e3ad61a8c266e9f7c0b8ade98f657d
[3]: https://github.com/odoo/odoo/commit/1c25ddb42393b136cac2a0ee0b9b7280fd803e7d
runbot-18747
closesodoo/odoo#125793
X-original-commit: 6a15cbe7b320989866ce143610dbea9ac00caa5e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when using the LinkTools (website, mass_mailing),
if an http URL contained a "@" (ex: https://www.youtube.com/@iRopes),
it got incorrectly recognized as an e-mail URL and the option to open
the link in a new windown was hidden from the UI.
This commit fixes the issue by making the test for e-mail URL slightly
more robust than just checking for the presence of a "@".
task-3356685
opw-3349704
closesodoo/odoo#125742
X-original-commit: 3f1db2397e50b26e2658d270cbb7ce908d5c05cd
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
'replace() argument 1 must be str, not bool' is generated if the user edit a
float or monetary section in the website view.
Steps to Reproduce
- Make debugger mode ON.
- Go to Settings > Translations > Languages.
- Remove the value of the 'Thousands Separator' field from the current user
language.
- Install the 'eCommerce' module.
- Go to the website.
- Go to the shop menu, and click any product from the product list.
- Click on the Edit button and try to edit any float or
monetary section like a product price (eg. change a product price from 750 to
70) and click on the Save button.
And traceback will be generated.
Applying this commit will resolve this issue.
sentry-4148693017
closesodoo/odoo#125684
X-original-commit: b895175cfc487f3db6e53351fd5774303f193698
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Antoine Guenet