Steps to reproduce:
- Add an image on the website.
- Save.
- With the HTML editor, change the src of the image (to
"https://odoo.com/logo.png" for example) and remove the
`mimetypeBeforeConversion` data attribute of the image. Note that it is
important to change the src of the image to ensure that the system does
not add the `mimetypeBeforeConversion` data attribute back on the image.
- Enter in edit mode and click on the image.
-> Traceback of type "Cannot read properties of undefined (reading
'split')".
This traceback appears because the `_renderCustomXML()` method of
`ImageHandlerOption` relies on the presence of formats on the list
returned by the `_computeAvailableFormats()` method. Since [1], if there
is no `mimetypeBeforeConversion` data attribute on the image, one of the
format in the list is `undefined`. As `_renderCustomXML()` tries to
perform a `split()` on this format, a traceback appears.
Although the steps to reproduce the result seem tricky, it has been
decided to create a fix for this situation. Indeed, in version prior to
16.4, the equivalent steps to reproduce (in which the `mimetype` data
attribute is removed instead of the `mimetypeBeforeConversion`) do not
lead to a traceback. In those versions, if there is no mimetype on the
image, the options such as "Filter", "Width" and "Quality" are not shown
in the editor panel. The goal of this commit is to apply the same logic
for the version 16.4; hide the "Format" option if the image does not
have the `mimetypeBeforeConversion` data attribute. To do so, the
`_computeWidgetVisibility()` method has been adapted consequently. To
avoid the traceback, the `_computeAvailableFormats()` method has been
adapted. It now returns an empty list if the image does not have the
`mimetypeBeforeConversion` data attribute. As there is no `undefined`
format in the returned list of valid formats, the traceback is avoided.
[1]: https://github.com/odoo/odoo/commit/730588b802506844e6ca54df312333bfd8df1d52
task-3631487
closesodoo/odoo#148882
X-original-commit: 485a5d74198668fa2f2240b4e31a871f36225857
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When the content of the editor is reset, the collaborative selection
should be reset as well. Otherwise, the selection is not reset and
the user can still see the selection of the previous content.
task-3675074
closesodoo/odoo#148826
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit, when restoring a document was made, it would reset
the content of the editor without any consideration for the mechanism
that detect stale documents and without any consideration for the
collaboration.
This commit fixes 2 problems in one shot:
1) Any change made in the editor after a restore was impossible to
save. The reason is that the restored version would reset the wysiwyg
without the id `data-last-history-steps` of the version in database in
the historyIds of the odooEditor wich subsequently would trigger the
stale document detection, preventing the save.
2) The reset would be propagated to other peers in collaboration. The
reason is the same as the 1st problem, the wysiwyg would be reseted,
not informing other peers of that reset.
task-3675074
Part-of: odoo/odoo#148826
*: website
This basically reverts the parts of [1] that are the known cause of race
conditions in runbot tests (in particular, the link tools one:
`test_15_website_link_tools`). But more importantly, this just did not
make sense to stop observing changes for async period of time, at least
unless there is no alternative given the state of the related code.
Commit [1] test-hack was actually adapted with [2] which probably made
it even more unreliable and hacky.
On top of that, this commit is of course trying to restore whatever
purpose this was made for ("dirty" flag addition, the history steps
recording, etc). Although fixing those the most robust way would
probably require a deeper refactoring in master and other stable fixes.
Note: in this forward-ported version, the test is still disabled on
runbot and broken for other reasons. Those will be fixed later.
[1]: https://github.com/odoo/odoo/commit/8cab404dce3a65c0bdd635a93682ee14282a3ebb
[2]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35
runbot-18747
closesodoo/odoo#148728
X-original-commit: 003422a73f0b5fb5540fbf2bd95a26a6dd663530
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
The editor has a feature that allows to automatically select a whole
paragraph on click when that paragraph contains text by default. At the
origin, this happened at every click on the element, until its content
was replaced, by typing something while it is selected or the cursor is
inside. Placing the cursor inside was actually impossible by clicking on
the element, since this forced a selection on the whole text again.
Since [1], that behavior changed (for no apparent reason): only the
first click forces a selection on the element. This is done by removing
the marker class from the element ("o_default_snippet_text"). Also, the
code which removed that class while typing was left behind... even
though it did not work anymore due to a code typo.
This commit fixes that without changing the main behavior:
- On click, we do not remove the marker class anymore, but only force a
selection on the text if it was not already seen before. Small change
of behavior: not changing the text and coming back later in edit mode
will force a selection on the text again on click.
- While typing, the code removes the marker class and thus the text will
never have a forced selection again (fixed the code typo).
Note: we may reconsider restoring the behavior there was before [1], in
master. Automatically selecting default text that was never changed
could indeed be better, although it will require better code to allow
placing the cursor inside easily anyway.
The main purpose of this fix is to avoid a mutation of the DOM on click
(removing the marker class). Indeed, this wrongfully marked the page as
dirty.
Steps to reproduce:
- Enter edit mode
- Add a "Text - Image" snippet
- Save
- Enter edit mode again
- Click on the first paragraph of the snippet (=> it is auto-selected)
- Click on discard
=> A popup appears to say you will lose your changes... while you did
not make any.
[1]: https://github.com/odoo/odoo/commit/912996fe902c41cafa12dcfe09713ce9857f95ab
Related to runbot-18747
X-original-commit: 3cc5bbcab641d7d436ebfbb0f160c9e0d77da142
Part-of: odoo/odoo#148728
*: web_editor
Commit [1] made the multiple drag and drop feature of the editor stop
using jQuery and used our own implementation. Unfortunately, the
initialization of that implementation in the case of the "drag column
on image move" feature marked the page as dirty by mistake.
Steps to reproduce:
- Enter edit mode
- Add a "Text - Image" snippet
- Save
- Enter edit mode again
- Click on the image of the snippet (and do not do anything else)
- Click on discard
=> A popup appears to say you will lose your changes... while you did
not make any.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
Related to runbot-18747
Part-of: odoo/odoo#148728
*: web_editor
Next commits will extend the main new test to make sure the flows they
are fixing are not wrongfully marking the pages as dirty. This commit
introduces it on its own as it deserved some more detailed explanations.
In 15.0, where this commit is being merged, the final version of the
test was failing for no apparent reason on staging only. This is because
the staging builds are made with more apps... which fill the website
menu with more items in such a way the "+" auto-fold menu feature comes
in play. That feature is marking the page as dirty by mistake in this
version, 3 different ways for 3 different configurations:
- the menu is not folded outside of edit mode and when entering edit
mode, the "+" appears and some menu are folded
- the menu is folded outside of edit mode and when entering edit mode
the resize actually makes it so a different set of menu is folded
- the menu is folded outside of edit mode and when entering edit mode
it stays the same (known to have been broken because edit mode
tweaks the dropdown behavior)
The first problem with this is actually the way we check the page is
dirty in case of discard: we check the whole DOM and compare it to the
way it was when entering edit mode... the whole DOM, including the non
editable parts. This is wrong by definition but it is also weird that it
does not match what is done when we *save*: where we only consider
sections that are explicitly marked as dirty (.o_dirty) and other
exceptions. This can't be changed in stable though, some save / discard
override may rely on this (not marking with the o_dirty class etc).
In 15.0, the original commit of this forward-ported version fixed the
3rd case described above, which was less risky than fixing the 2 others.
The cause for the DOM diff in that case was the `data-toggle="dropdown"`
which mysteriously reappeared between the moment we check the "initial
DOM" and the "DOM when we try to discard". This was because of [1],
which makes the dropdowns behave differently in edit mode, combined with
the fact that the "+" menu is re-rendered after each resize (and one is
triggered when entering edit mode since [2], originally for that
actually). That behavior is however apparently not needed for the "+"
dropdown, so we simply disable it. Some lower level fix is still needed
but will be done in master, as the real problem falls in the dirty page
detection system. A test was added for this specific third case.
In 16.0, this is different: all 3 cases seem fixed, probably indirectly
thanks to the website-in-iframe refactoring at [3] and the bootstrap 5
migration at [4]. Not sure. This forward-port commit thus only adds
tests and a bunch of comments. Note that what was said about the 15.0
version was actually not entirely true: "That behavior is however
apparently not needed for the "+" dropdown, so we simply disable it." is
actually wrong. Indeed, it changed the behavior when clicking *outside*
of the extra items menu (which is less important). A patch in 15.0 will
be backported anyway to explain that.
To make the final test pass, it ensures most menus are removed so that
the "+" feature is basically disabled always during the test. Behaviors
will of course be fixed in further versions.
Note that in this 16.0 forward-ported version, a test kinda already
existed for this... although it was badly written and the code that was
merged with it actually worsened the dirty check behavior. See [5].
This commit adds comments around some more problematic parts.
[1]: https://github.com/odoo/odoo/commit/fe67b34f1a03d838df82a1307cf6467f994a8f3b
[2]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[4]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[5]: https://github.com/odoo/odoo/commit/650a97d1bd59254cc2115d54d58940b6112a8d70
Related to runbot-18747
X-original-commit: a0b741a53fef6a2a15d9283397dd7ec22d624382
Part-of: odoo/odoo#148728
Before this commit, when trying to remove a format of a
`data-oe-zws-empty-inline` of an empty block, the attribute was added to
that block and would never be removed. Also, unformatting a zws would
not remove the zws from the dom.
How to reproduce the original bug:
- put the selection inside an emtpy p
- ctrl+b (in windows/linux) or cmd+b (in mac)
=> The zws attribute data-oe-zws-empty-inline is added on the P rather
than creating a span.
- The next letter that will be typed will not be bold but should be
bold
- That attribute should not exists in a block, that could lead to
unexpected bug
task-3628480
closesodoo/odoo#148659
X-original-commit: 7b7e343e7b4fd5bab4f41eeead85dedbf2ab717d
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit:
The editor's code was unnecessarily adding an access token to attachments
created from external URLs. This addition of a query string with an access
token to an external URL made no sense and could lead to issues.
After this Commit:
This commit prevents such behavior by adding a condition to check if the
attachment is created from an external URL. If so, it will not generate and
add an access token, ensuring the integrity of the external URL.
task-3470982
closesodoo/odoo#148646
X-original-commit: e5d464660f29a3b0b2af1c0ed534b63f81f1b10d
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Sanjay Sharma (shsa) <shsa@odoo.com>
Before this commit, when an image was cropped in a record on which
multiple users were collaborating, multiple attachments would be created
for the same image (one per user).
Multiple attachments for the same image would also be created if the
user uploaded the same image multiple times in the same record.
This commit makes sure that, when about to create an attachment via the
'add_data', 'add_url' and 'modify_image' routes, if an attachment
already exists for the same field values, the existing attachment is
returned instead of creating a new one.
task-3524601
closesodoo/odoo#148556
X-original-commit: 0e2508388fc03b2ea7a4033e571d289efa4ac479
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Before this commit, when the user was in RTL mode, the row menu UI was
appearing on the right side of the table UI toggler, which would make
it invisible to the user.
This commit fixes the issue by making the row menu UI appear on the
left of the table UI toggler in RTL mode.
task-3664939
closesodoo/odoo#148543
X-original-commit: 25a9c993ff0bdbe30fca1e4306da9018a7ec836a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit, the row table UI toggler was positioned on the left
for RTL languages. Since the first TD was on the far right rather than
the far left, it was impossible to click on the row UI. It disappeared
whenever an attempt was made to click on it.
task-3664939
X-original-commit: fbc167bf84340b4bb6d0f8c59f2734814f56c6df
Part-of: odoo/odoo#148543
The border was adding 1px offset that made the o_table_ui children 1px
off.
task-3664939
X-original-commit: cd497d12031bc88c8b62151f432970024ce5ce84
Part-of: odoo/odoo#148543
When converting a card for e-mail client compatibility, we apply the
attributes of the card's block children to their respective cells and
unwrap them. However, that's an issue if the child is an image or a link
since their respective `src` and `href` attributes are meaningless on
the cells.
task-3631900
opw-3580317
opw-3630693
closesodoo/odoo#148529
X-original-commit: d3bdb08c97ad7eab005ac185f393807df35f383e
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Current behaviour before commit:
In website, space before the word is lost when deleting the word.
Desired behaviour after commit:
Now space is preserved when deleting the word.
task-3233352
closesodoo/odoo#148492
X-original-commit: 5f5d12dd1bbdc63a9565aa84f197c4a9bba55d7a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit, if a URL was contained in two or more text nodes,
e.g. <p>"link" ".com"</p>, pressing the space key after the URL failed
to convert it into a link. Such text node split can happen as a result
of backspace or delete in the middle of a text node.
This commit makes sure adjacent text nodes are merged before searching
for a URL in its content.
task-3468763
closesodoo/odoo#148362
X-original-commit: 04f9a90127eac2a403ffe77d1e90dbe659a8fa42
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Before this commit, the link preview in the Link Dialog would not be
updated after changes on the label input field, depending on other
actions to be updated (e.g. picking a different type of link/button or
changing the URL input field).
This commit makes sure the link preview reacts to changes on the label
input field.
task-3580621
closesodoo/odoo#148202
X-original-commit: c7954225e8680821a46c9628e5e05df2ae575da7
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
*: website
When the user uploads an image and remove the original image, some
image options continue to work thanks to a backend fallback on another
image. Unfortunately, this fallback is not available for images coming
from unsplash. This commit fixes this issue by preventing the UI to be
blocked when the original image is not found.
Steps to reproduce the bug:
- Activate the developer mode
- Configure Unsplash in the settings
- Add a Cover block on a page
- Replace the background image with an unsplash image
- Save
- Edit the page and via the media dialog, remove the original image
=> The options on the image cannot start anymore.
opw-3636499
opw-3474103
closesodoo/odoo#148197
X-original-commit: 3b0ac160a800f70ae965b60110e83e41655bca5f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit:
When inserting a star rating element, pressing 'Enter' would move the cursor
to the next line, and hitting 'Backspace' would delete the star rating element.
After this commit:
After inserting a star rating element and moving to the next line with 'Enter,'
pressing 'Backspace' now causes the cursor to move to the previous <p> tag
where star element is located. If 'Backspace' is pressed again, the star
element is deleted.
task-3555394
closesodoo/odoo#148198
X-original-commit: 64a1b38450e15162f89d370fbe30abda9e5f7fe7
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
The "grid images" are grid items that only contain an image (i.e. the
image is alone in its column). This distinction with other images in
grid mode allows to set the `object-fit` CSS property to `cover` so they
take the whole space of the grid item (see commits [1] and [2]). In
commit [3], the "Position" option has been added, allowing to switch
between the `cover` and `contain` values for this property, to have the
possibility to still choose to display the entire image, so it can keep
its ratio.
However, only the images that are direct children of the column have
been considered when checking if it was a grid image and in the related
CSS rules. This means that an image with a link cannot be one, since
the image is the child of an anchor element `<a>` in that case. It can
therefore not be set as "cover" or have the "Position" option.
This commit adds the support for images with a link set on them, so they
can be considered as grid images too.
Steps to reproduce:
- Drop the "Masonry" snippet.
- Click on the image and set a link on it.
=> The image is now "contain" and the "Position" option disappeared from
the right panel so we cannot change it.
[1]: https://github.com/odoo/odoo/commit/e9c7e020daf88022d6e02de0a5620074e8417b5a
[2]: https://github.com/odoo/odoo/commit/d8c374e3e6b31bf88aa42952aadf3379936f7600
[3]: https://github.com/odoo/odoo/commit/faf19ef7f87fc043fb9a814516e01b8eeafd9b61
opw-3580128
closesodoo/odoo#148022
X-original-commit: 085d70cea571ea80c141ac6005e8bd8333bd269f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Minor fix: the background grid is not observed in the first place,
setting a z-index on it should not be observed either.
Noticed when fixing `automaticStep(Un)active()` at [1].
[1]: https://github.com/odoo/odoo/commit/c2d952689c97add74a372c90aa18787094d5d93a
Related to task-3576046
closesodoo/odoo#147970
X-original-commit: 901ed6d8c6c6bdb8aff8e9366d63bba59051019a
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Current behaviour:
When changing the text color in the document layout
of the company to one of the first row colors,
the text stays black in the preview of the document.
Steps to reproduce:
1. Go to Settings
2. Click on Configure Document Layout
3. In Company Details, highlight the text
4. Change the font color to any of the first row
5. (By example the color #35979c)
6. The text color in the preview is still black
7. (Same when exporting to PDF)
Cause of the issue:
The css code for colors in top row (o-color-1 to 6)
is generated in web_editor (.text-o-color-1 to 6)
and was not in the report_assets_common bundle
See https://github.com/odoo/odoo/blob/01b42c7d76c814e13325f8880dc9de765b0f43c8/addons/web_editor/static/src/scss/web_editor.common.scss#L662
opw-3360456
closesodoo/odoo#147645
X-original-commit: 0b914f3d0dc209ca87837feb15e6ec3f063be534
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Since [1] when the `Colorpicker` template cache was moved from
`ColorPalette` to `getColorPickerTemplateService`, the custom buttons
fill color cannot be set as a gradient anymore.
This happens because the needed `getTemplate` props is injected for the
font and background colors, for the `we-colorpicker` but not for the
link tools color palettes.
This commit restores the gradient color selection for custom buttons by
linking the `getColorPickerTemplateService` to the link tools color
palettes.
Steps to reproduce:
- Edit Home page.
- Click on "Contact Us" link in header.
- Select link style "Custom" in link tools.
- Open "Fill Color" palette.
=> Gradient tab was not shown in palette.
[1]: https://github.com/odoo/odoo/commit/1d2e54088b0f0e28464ab6aa884fb2e1110e8e04
task-3641914
closesodoo/odoo#147373
X-original-commit: 087861bcbfe444765fdb0b81e0398c12d8db34e8
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit, the "on hover" animation option would be shown for
images of type url-attachment-redirect.
Selecting that "On Hover" option value would result in a crash if the
image was CORS protected (which is often the case).
Steps to reproduce:
- Drag & drop "Text - Image" snippet
- Double click on an image to replace it
- Select in the media dialog "Add URL" and insert a CORS protected
image URL
- The image is correctly added, and its url is something like
`/web/image/123-redirect/xxx.jpg`
- Click on the image and then click on its "Animation" option and select
"on hover" as value
-> It crashes
The same error will happen with absolute URL of a CORS protected image
(instead of the relative local redirect attachment-url
`/web/image/123-redirect/xxx.jpg`).
Technical stack:
> the XML option `data-animation-mode="onHover"`
> call the js method `animationMode()`
> calls `trigger_up('enable_hover_effect')`
> calls `setImgShape()`
> calls `_applyShapeAndColors()`
> calls `_writeShape()`
> calls `applyModifications()`
> calls `loadImage()` which fails to load the image
-----------
Technical note: JS `fetch()` takes advantage of the browser cache, no
need to create a `Map` cache for it, despite the `_computeVisibility()`
method being called multiple times.
----------
Related to commit [1].
The code is failing since commit [2] which added the "On hover" image
animation.
Other animation values won't fail. And not-cors-protected images will
work fine with the on hover option.
[1]: https://github.com/odoo/odoo/commit/f0fe283c761cd6b1d7293dd41795ac6fc721e341
[2]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85closesodoo/odoo#146732
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
There is a code in charge of removing image animation attributes, but
this code was not removing the `o_animate_on_hover` class.
Probably not that big of a deal but during the investigation of a bug,
this class was not removed while the attributes where, which seems to
lead to a crash later.
Related to commit https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
Part-of: odoo/odoo#146732
There is cases leading to have a `data-shape` but no
`data-shape-colors`. It then makes the code crash.
Step to reproduce:
- Drag & drop "Text - Image" snippet
- Double click on an image to replace it
- Select in the media dialog "Add URL" and insert a CORS protected
image URL
- The image is correctly added, and its url is something like
`/web/image/123-redirect/xxx.jpg`
- Click on the image and then click on its "Animation" option
-> It crashes
In such a case, the code was crashing on the line below this fix:
`img.dataset.shapeColors.split(';')`
The modified code here is related to commit [1].
But the code only break in Odoo 17, probably following commit [2].
[1]: https://github.com/odoo/odoo/commit/cd403480f90cf7103651f3be818a14b06d3c73ca
[2]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
Part-of: odoo/odoo#146732
Before this commit if invisible elements are in the DOM (e.g.
device-visibility restricted) the arrows to move snippets (columns,
sections) did show up and behave as if the neighbour elements were
visible.
This commit hides arrows that would not visually move the snippet, and
upon using the move arrow, it also moves the snippet beyond the first
visible neighbour.
Steps to reproduce as of 16.0:
- Drop a "Columns" snippet.
- Make the center column hidden on desktop.
- Move the first column to the right.
=> It did not move and an arrow to move to the left was displayed.
Steps to reproduce before 16.0:
- Drop three snippets.
- Make the second snippet conditionally visible.
- Hide it using the eye icon in the "Invisible Elements" list.
- Move the first block down.
=> It did not move and an arrow to move upwards was displayed.
task-3584947
closesodoo/odoo#146879
X-original-commit: 60e2a5bc9ed8721ed34eb952cd34375fe5a93395
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
To reproduce
============
- on studio > create new report from internal layout
- execute 2 columns command --> the second column will be under the first one
Problem
=======
the browser finds out that the `iframe` is small to keep two `col-lg-6` side by side.
Solution
========
use `col-6` instead, like in 17
opw-3585043
closesodoo/odoo#147074
X-original-commit: 246f42baf76b308210a2b03d46a6143ace4bb7cc
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
When we start dragging an element with an open mega menu, the dropzones
should only appear:
- inside the mega menu: we therefore should not be able to drop a mega
menu element outside of it.
- after the clone of the element, so we can still drop it where we
started the drag (if it does not come from the mega menu).
This is well the case for normal dropzones but the grid dropzones case
was forgotten. Some "clone dropzones" are also not added for inner
contents that are in a grid mode snippet.
Steps to reproduce:
1)
- Add a mega menu with the menu editor.
- In edit mode, drop the "Text-Image" snippet and toggle the grid mode.
- Open the mega menu and start dragging one of its columns (note that it
toggles the grid mode).
=> A grid dropzone appeared in the "Text-Image" snippet, outside the
mega menu.
2)
- Drop an "Alert" snippet in "Text-Image".
- Open the mega menu.
- Start dragging the "Alert" snippet.
=> No dropzone appeared where we started the drag (so after the clone).
This commit fixes these issues. The first issue is solved by properly
filtering the `selectorGrids` when a modal or a dropdown (so the mega
menu) is open. They were already filtered for the modal case (see commit
[1] which was then refactored in [2]) but it should have been done in
`_activateInsertionZones` at the already dedicated place, instead of
before the call to this function in `_onDragAndDropStart`. This made the
siblings and children selectors filtering redundant and this code was
therefore removed.
The second issue was happening because the "clone dropzone" was only
added if there was no "closest" grid, instead of only checking the
parent. This therefore prevented it for inner contents inside grid items
instead of only for grid items. This commit fixes that. For the case
where we are dragging a grid item (still with an open mega menu), a grid
dropzone is added.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
[2]: https://github.com/odoo/odoo/commit/34b534f75dbf3e4c475ca8cc40c8fafde5dbea5d
task-3594979
closesodoo/odoo#146714
X-original-commit: 8eebef20de144fe223feace39546d827a0952b23
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Step to reproduce:
- Create a mega menu
- Enter edit mode and select it
- You can duplicate the top level block (but not remove it)
- If you duplicate it, you end up with a second top level block that you
can't delete ever, even by deleting inner elements one by one.
Technical details:
1. The remove button of the mega menu is already hidden thanks to commit
[1] which used the `forceNoDeleteButton` editor option introduced
with commit [2].
2. The table of content snippet also need to hide both the delete and
clone button. It was done in an "non-ideal" way with commit [3].
3. The delete button removal for table of content snippet was actually
improved to use the `forceNoDeleteButton` option of commit [2].
4. It's also commit [1] which prevent the deletion of the top level
block when deleting inner elements one by one: when the last one is
deleted, it regenerates the whole block.
This commit thus simply makes it so `forceNoDeleteButton` also hides the
clone button.
A first solution was made by introducing a new `forceNoCloneButton`
option, but there is good chances that you always want to either hide
both or show both, so merging those options for now is the simplest
solution.
It also takes the opportunity to remove the (now) useless code in the
table of content snippet.
[1]: https://github.com/odoo/odoo/commit/97810a9c40396bb27cb5779937734849d185cf1f
[2]: https://github.com/odoo/odoo/commit/7ef484377a493ebe558242480d0da6b542d6c247
[3]: https://github.com/odoo/odoo/commit/9fb2dad97cfbd412bee3cb5d1358a9835e721f60#diff-ea32a091d6b1a47aeea680fa39bbc9111260cbdaf07e9f388a9d04741806ea8fR128-R129
opw-3604033
opw-3627319
closesodoo/odoo#146745
X-original-commit: 44b006778df913b847c58b3e405d2a177fcb1a7c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the CSS properties defined by the
`o_link_in_selection` class could be applied to a link outside the
editable. In particular, the link preview in the LinkDialog widget would
display the visual indicator of a link in selection, even though it is
not editable nor selected (this happens because the link preview
contains the classes of the original link being edited).
As the styling provided by `.o_link_in_selection` is only meant to be
applied to links inside the editable, this commit makes sure the CSS
rule is specific about that.
task-3580546
closesodoo/odoo#146679
X-original-commit: b7664dc8e8a0a7909101f45d5a58473ca64d71ca
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Current behaviour before commit:
-When creating a link, the 'unlink' button is
not getting appeared in the toolbar.
-When removing link through 'unlink' button,
the 'unlink' button is not getting disappeared
in toolbar.
-Before this commit, _updateEditorUI method is
responsible for hiding/ showing create-link
button.
Desired behaviour after commit:
-Now, When creating a link, the 'unlink' button
gets appeared in the toolbar.
-When removing link through 'unlink' button,
the 'unlink' button gets disappeared
in toolbar.
-This commit ensures that _updateToolbar
method is responsible for hiding/ showing
of create-link and unlink button.
task-3514639
closesodoo/odoo#146680
X-original-commit: 92ca62162e85a3c617ba73eaa974d342adc3e35a
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Before this commit, pasting a URL as plain text followed by picking
"Embed Youtube Video" in the command bar failed to embed the video,
inserting the following text instead: "[object Promise]".
This happened because [1], which is the result of a forward-port, failed
to `await` the call to getYoutubeVideoElement, which is an async
function since version 15.2.
[1]: https://github.com/odoo/odoo/commit/c2f0519fec40dcf529218f39829e0a09c0f7af69
task-3611566
closesodoo/odoo#146653
X-original-commit: 4891359210e2f921dbfb6d7c870ec5cf1b60d3f5
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Since [commit 1], the columns count in the options is updated while
dragging the width handle of a column. That behavior relies on
asynchronous code which is not awaited.
This commit corrects it to be in line with the behavior of all other
options: the count is updated after releasing the drag. It also freezes
the mutex during the resize.
[commit 1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba
task-3576046
closesodoo/odoo#141002
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when editing a snippet that is outdated, an alert
block is displayed above the options, warning about that. However, this
alert does not really catch the attention and it does not prevent the
user to still use the options.
This commit improves this alert block by making it cover the whole
outdated options section, to make it more visible. Moreover, it now
contains two buttons:
- one to replace the outdated snippet by its new version, and
- one to still access the options, despite the fact that they may not
work anymore.
task-3203590
closesodoo/odoo#117560
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [this other commit], we add ZWS characters to the edges of links.
Unfortunately, this breaks the label option of the link tools that has
been introduced in [this commit].
Steps to reproduce the issue:
- Go to website
- Edit a page
- Click on the contact us button in the header
- Using the label option of the link tools, delete the final character
=> Nothing happens.
The final character is not deleted as expected.
[this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35
[this commit]: https://github.com/odoo/odoo/commit/75166dbcd4962f30624fe19829757acbf8e76022
Related to runbot-44779
closesodoo/odoo#146361
X-original-commit: 593dc52cd5c3362c446395a52a7782f74f445e34
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Steps to reproduce:
- Add a "Text-Image" on the website.
- Replace the image by one of your own.
- Save.
- With the html editor, remove the `mimetype` attribute, the
`data-original-src` attribute and change the `src` of the picture into
the corresponding protocol-relative one. The `src` then looks like
"//domain/web/image/...".
- Save the modifications of the html editor.
- Enter in edit mode.
- Click on the image.
-> It is now impossible to change options such as `Filter`, `Width` and
`Quality`.
Because the `data-original-src` attribute was removed from the image,
the system tries to add it back thanks to the `loadImageInfo()` logic.
Because the `src` attribute of the image is now a protocol relative url,
`new URL(src)` will raise an error and the logic will use this url as
argument for the `/web_editor/get_image_info` route. Because the url
given in argument of the rpc call is not the relative one, the system
fails to find the original attachment. The `mimetype` attribute is
therefore not added back on the image, leading to the impossibility to
change some options.
To solve the problem, this commit modifies a bit [this commit]. In order
to be robust to absolute, relative and protocol relative URLs, an URL
object is first created from the image src. The relative URL
(`.pathname`) of the URL object is then used to retrieve the original
attachment linked to the image.
Let's synthesize the different `relativeSrc` obtained with different
image src. In the following examples, "https://test.com/blog/travel-1"
will be used as `img.ownerDocument.defaultView.location.href`.
(the complete URL of the document in which the image is located).
- `src` is an absolute URL (e.g.
"https://test.com/web/image/697-d0f2aaf8/shoes.jpg"). In this case,
`relativeSrc` = "/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a relative URL that begins with a slash (e.g.
"/web/image/697-d0f2aaf8/shoes.jpg"). This URL represents an absolute
path starting from the root of the domain. In this case, `relativeSrc` =
"/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a relative URL that does not begin with a slash (e.g.
"web/image/697-d0f2aaf8/shoes.jpg"). The interpretation of this URL
depends on the current location. In this case, `relativeSrc` =
"/blog/web/image/697-d0f2aaf8/shoes.jpg".
- `src` is a protocol relative URL (e.g.
"//test.com/web/image/697-d0f2aaf8/shoes.jpg"); there is only the
protocol missing. In this case, `relativeSrc` =
"/web/image/697-d0f2aaf8/shoes.jpg".
This solution takes the advantage of the second argument of the `URL()`
constructor which is used if the first parameter is a relative or
protocol relative URL and which is ignored if the first parameter is an
absolute URL.
This commit does not only modify [this commit] to handle more types of
URLs but also:
- To avoid having to use `.split()`. Indeed, `.pathname` does not
include query parameters.
- To avoid having to consider an error raised by `new URL()` as a normal
flow. Indeed, in [this commit], an error would be intercepted by the
`catch` if `src` was a relative URL. This was a legitimate flow. The
problem was that other unwanted types of src (for example protocol
relative URL) were also raising errors but were silently ignored (as
intercepted in the `catch`).
[this commit]: https://github.com/odoo/odoo/commit/89c14783846288a2de53f6258a93440e02550b13
task-3623731
closesodoo/odoo#146238
X-original-commit: 96324fe8443647a078756c98f9629af274ff38a5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
[Commit 1] made sure the history worked when resizing elements by
calling `odooEditor.automaticStepUnactive()`, but applied its
counterpart `automaticStepActive()` only at the very end of the action,
leaving some `return` statements on the way that could break the flow.
This commit calls `automaticStepActive` just before leaving the listener
and moves `automaticStepUnactive` just before the first DOM
modification. It's both more logical and avoids returns pitfalls.
Note: `automaticStepActive()` makes sure modifications made on the DOM
through the browser's developer tools are tracked and can be reversed
with the undo button. Not reactivating it in time means some flows could
be broken (until another method reactivates it).
[Commit 1]: https://github.com/odoo/odoo/commit/423f4bd2a6cc47e69699d2437eaa5acda94bb98d
Related to task-3576046
closesodoo/odoo#146249
X-original-commit: b99cc41e4352d3ff9bffe7b0a5436edbef0ab01b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Current behaviour before commit:
When pressing crop button, crop widget is not getting
opened and 'connection lost' notification is appeared.
This happens because in wysiwyg.js file _rpc function
does not get the proper arguments from loadImageInfo
function.
Desired behaviour after commit:
Now, _rpc function is removed from wysiwyg.js as it
doesn't need anymore and _serviceRpc is passed directly
through the props. As result crop option works.
task-3546160
closesodoo/odoo#138482
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
If the snippet names are too long (e.g., after being translated), they
overflow and cause a horizontal scrollbar to appear on the snippet menu.
Steps to reproduce the issue:
- Set 'Finnish' as the language for the connected user in Odoo.
- Go to Website edit mode.
- Bug: Some snippet names are too long and overlfow their parent
elements.
This commit fixes this issue by adding the CSS rule 'ellipsis' to
snippet names.
task-3584011
closesodoo/odoo#145500
X-original-commit: 0ab64009ce81dc02f87c80f7de409a5dcff214c1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Louis (loco)
