Steps to reproduce the bug:
- Enter edit mode.
- Click on the "Theme" tab in the options panel.
- Click on "Add a Google Font" in the "Font Family" select.
- Paste the address of a font page in the input.
- Disable the "Serve font from Google servers" toggle.
- Save the dialog.
- After the reload, click on the "Theme" tab.
- Open the "Font Family" select.
- Click on the "Remove" button for the recently added font.
- Confirm your choice to close the dialog.
- After the reload, click on the "Theme" tab.
- Open the "Font Family" select.
- Bug: the font has not been removed.
This bug appeared with commit [1]. With the transition to the Owl
render engine, the 'true' value passed as a parameter in the
'delete_google_font_btn' template, defining whether a font is local,
wasn't being set as the attribute value in the template.
In this Owl context, 'true' indicates the attribute's presence, not its
value. To address this, we replaced the boolean 'true' with the string
'"true"' to ensure the parameter value is correctly passed to the
template.
[1]: https://github.com/odoo/odoo/commit/f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b
task-3714768
closesodoo/odoo#152715
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Add an "Images Wall" snippet on the website.
- Add a link on the first image.
- Add a new image on the wall.
-> Problem: the first image does not have a link anymore.
When adding an image or reordering the images on a wall, the system
re-renders the snippet (see `nomode()`, `masonry()`, `grid()`) by adding
each images on the wall structure. The problem is that the system only
takes the images into account and not a possible image wrapped into an
anchor. This is now fixed as the system renders the images or the
wrapped anchored images returned by `_getImgHolderEls`.
The process is a bit different when adding an image or reordering the
images of an "Image Gallery" snippet. In this case, the system
re-renders the `website.gallery.slideshow` template. The problem here is
double: First, the template does not take a possible wrapped anchored
image into account. Second, there are only few image attributes that are
rendered by the template.
This leads to a new problem:
- Add an "Image Gallery" snippet on the website.
- Add a "Blur" filter on the first image.
- Click on "move to next" to move the first image at the second
position.
-> Problem: the image option does not show the filter and it is now
impossible to change some image options such as "Filter", "Shape" and
"Quality".
To solve those two problems**, the images rendered by the
`website.gallery.slideshow` template are replaced by the images (or the
wrapped anchored images) returned by `_getImgHolderEls`. By doing so,
the rendered images have the correct attributes (so the options can be
correctly displayed and modified) and they are still correctly anchored.
This commit also adapts the `snippet_images_wall` test. An extra trigger
had to be added on the `Select footer` step to ensure that the last
image of the wall has been inserted before clicking on the footer.
Without it, the tour fails as, if the moved image is in the first
position, the tour only waits for this image to be inserted in the wall
and then clicks on the footer. When the wall is completely built, the
focus is automatically done on the moved image and the step
`selectSignImageStep` fails to execute as its `extra_trigger` condition
(`.o_we_customize_panel:not(:has(.snippet-option-gallery_img))`) is not
met.
**: In this 16.4 forward-port, the second problem is not entirely fixed.
The task-3717041 will handle it.
opw-3535829
opw-3573135
closesodoo/odoo#152365
X-original-commit: e73a1a96dcf8786c01205ae0a97b10e38ab9afeb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- In Website edit mode.
- Drag and drop a "Cover" snippet into an empty page.
- Sets the "Height" option of this snippet to "100%".
- Drag and drop a "Media List" snippet into the page.
- Drag and drop a "Popup" snippet into the page.
- Save the page.
- Scroll quickly the page to the bottom before the popup appears.
- When the popup is open, resize the window to trigger a "resize" event.
- Close the popup.
- Scroll the page to the top.
- Bug: the height of the "Cover" snippet is a way too high.
This bug occurred because the height of the snippet with the "Height:
100%" option enabled is calculated based on the scrollable element it is
in (since this commit [1]). However, when a popup is opened, the
detected scrollable element was incorrect due to the "overflow: hidden"
rule added to "#wrapwrap" by the "modal-open" class on the <body>.
[1]: https://github.com/odoo/odoo/commit/b371cb42cb67115692464c102813b7ebd54785d9
opw-3643498
closesodoo/odoo#152402
X-original-commit: 35b3f676820f7a19e842b3403a5ebcf956714a70
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Before this commit:
`destroyLinkTools` function sets the selection to entire link. However, in
case where a website snippet had a structure like
```html
<a>
<div>
<i class=fa-xxx></i>
<div>
<h4>Text</h4>
<font>Text</font>
</div>
</div>
</a>
```
selecting the complete link caused problem. The toolbar couldn't be
updated correctly, also one could not change the a tag of a single element
within the link.
After this commit:
`destroyLinkTools` selects the `anchorNode` and the `focusnode` of the
selection instead of entire link.
task-3245819
closesodoo/odoo#151752
X-original-commit: e88ffecc4bdb0480fc1d47af14558f28f72a665d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
*: test_website
Commit [1] modified the custom page search model so it is adding the
current website in the search domain.
But it was not considering the case of models not having a website_id
field.
The only case was the appoitment.type model.
Steps to reproduce:
- Install website_appointment (enterprise)
- Click on Website > Site > Appointments
- Crash
[1]: https://github.com/odoo/odoo/commit/db670f64f4c2190f1655f9077ea62885049a3c84closesodoo/odoo#151686
X-original-commit: 247a5e157f14ce2cd8fbbe8d191abcb3c2e4ec0d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit was written for Odoo 16.4 and then backported.
In Odoo 16, only point 2. described just below is not working.
The 16.4 commit was thus retarget to Odoo 16 as it was also fixing the
second point.
------------------
Before this commit:
The website selected in the website selector of the search view in the
website.page list/kanban view was always set to the first one found in
the DB and was never:
1. the one you visited in the website preview
2. or the one matching the URL of your backend.
But 1. was working fine before commit [1] from the frameworkjs which
introduced a way to "reset" the screen between apps/menu switch.
Despite 1. working before commit [1], it was not ideally coded and
worked "by chance", see below for a few facts and explication.
------------------
Fact 1:
When you have multiple websites and you are on a website, the website
served is the result of 2 possibilities:
1. All websites have a specific domain, then you can only see a given
website on its own domain. Attempting to select another website in
the website switcher will redirect you to that other website domain.
2. You have one or more websites without any domain, then you can see
those ones from any domain by using the website switcher. It will
force the website in session, and despite being on a domain which
should serve a given website (the one which has its domain set that
domain if there is one), it will serve you the one you selected in
the website switcher.
Fact 2:
- It is the `website_preview` which is setting the currentWebsite
property of the `website_service`.
- But the `website_service` can be used on its own, without any
`website_preview` being involved in the process.
- When the website preview is unmounted, the currentWebsite from the
website service is reset to null.
- The website page list component is reading the currentWebsite from the
website service.
- When switching from the website preview to another menu like the
website pages list, the page list component (PageControllerMixin) is
actually initialized/created before the website preview is unmounted.
In the end, the following happen:
1. Go to website preview -> it sets the website service current
website
2. Go to website page list
3. The website page list component reads the current website from the
website service which is set
4. The website preview is unmounted, emptying the current website from
the website service
5. The website page list is shown to the user
6. Any call from the page list component to the current website will
now be "wrong" / not return the same as during its `onWillStart`,
as website preview was unmounted just after that, emptying the
website set in the website service. Luckily, there is none.
Fact 3:
Commit [1] changed the order of the steps listed above, now 4 occurs
before 3, so when the page list component reads the website from the
website service, the unmount of the website preview already kicked in,
emptying that website service website.
This is the source of the bug fixed here: the current website could
never be found anymore.
-----------------
This commit is simply finding the current website_id by asking it to the
server.
It will fix point 1. listed at the very beginning of the commit message,
but will also make point 2. work.
Another solution would have been to find a workaround to the frameworkjs
change (like investigating the `noEmptyTransition` option) to restore
what we had before, but it would have been as "fragile" as before and
wouldn't have fixed other flows as the current fix does.
----------------
Steps to reproduce 1:
- Without any domain set, go to your DB in the website preview of your
website in the backend
- Switch to the website 2 in the navbar website switcher
- You are now viewing website 2 in the website preview
- Click on "Pages" in the "Site" menu to go to the page list view
- The website selected in the search view is the first one, not the
website 2. Also, the page shown are from the website 1, not the
website 2.
- This was working before commit [1] and this commit is fixing that.
But this commit is also fixing/improving flows which never worked:
- Before commit [1] (or in Odoo 16 to be simpler), do the same 4 first
steps as above.
- You will see that the listed pages are the ones from website 2 and
that the selected website is the second one, correct.
- Now just reload the page, it will show website 1, despite the website
2 being forced (if you did reload the page on the preview, it would
still show website 2).
- This is because the website_preview was never involved after the
reload since you reached the list view / website service without going
through the website preview.
- The same can be seen if you go to the Pages list view directly through
CTRL+K, in which case you won't go through the preview.
--------------------
Note that the chance is taken to reorder the wutils export, it was
becoming a real mess and it was not possible to easily read through the
method names to find/guess something.
------------------
[1]: https://github.com/odoo/odoo/commit/9f6ed9f6d1ef7ec1870980498480cae0ffc729d8
Related to task-3676124
opw-3658648
closesodoo/odoo#151269
X-original-commit: 0128beed551395b30f957a5edc1a23a6f3d0ba31
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the problem:
- Add a "Countdown" snippet on the website.
- Save.
- Enter in edit mode again.
-> Problem: the `destroy()` of the `CountdownWidget` public widget comes
from a `widgets_start_request` that is triggered when the
`WysiwygAdapterComponent` has been mounted and patched (see
[useEffect documentation]). The problem is that, as the widgets are only
destroyed at this moment, it is possible that a widget could replace an
element that has been modified during the instantiation of the
`WysiwygAdapterComponent`. For example:
- At the `onWillStart()` hook of the `WysiwygAdapterComponent`, the
`o_editable` is added on some elements.
- A widget could then replace one of these elements.
- The widget is destroyed after the rendering of the
`WysiwygAdapterComponent`.
-> The `o_editable` class is not on the element anymore.
The goal of this commit is to, as before [1], destroy the existing
widgets before instantiating the `wysiwyg`.
This commit also adds a test to ensure that the order of the calls to
the widgets and wysiwyg lifecycle methods is coherent.
Related to runbot-28700
[1]: https://github.com/odoo/odoo/commit/a3e34512bf229d5d55f9e9d9eb0a9f7211a5a826
[useEffect documentation]: https://github.com/odoo/owl/blob/master/doc/reference/hooks.md#useeffectclosesodoo/odoo#151411
X-original-commit: 723c0dfeb7d39ca2522e65cf021664aacfc7099c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, since [1], the "small" class behavior of Bootstrap
was changed to use a fixed value instead of being dependent on the
context (using `em` units).
This was a bad choice, given the fact that the "small" class could
be used in the past with its previous behavior in custo but also in
default Odoo layouts, where it could be use in more legit cases that the
one Odoo currently offers: instead of applying the class to a whole
paragraph, applying it to part of a title.
In that case, since [1], we can have a big title ... with a very small
text next to it, which may be strange. Of course, the proper way to
achieve a big title with a smaller text next to it would be to not use
"small" but another hx font-size, but the legit bootstrap behavior which
is to use their "small" class is thus broken.
This commit keeps the current possibilities (big title with very small
text next to it) but does it by using new custom Odoo classes instead of
changing the Bootstrap "small" one. That way, legit custo in previous
versions (or trying to use default Bootstrap in this version) will be
supported.
Note that this commit will impact existing 17.0 users though: if they
actually configured a big title with small inner text... those will
become big title with slightly smaller inner text (the default Bootstrap
behavior). Worse: a big title whose size was reduced using the font-size
selector and choosing "small" will now become a big title. We think this
is worth the risk (see PR description for more visual details).
However, notice that "legit" use case of the "small" font-size in 17.0
will be kept untouched: e.g. adding a small text on its own or next to
a paragraph: the "smaller" Bootstrap behavior is now computed based on
the ratio of the configured base and small font-sizes.
Note that some additional "bugs" were found investigating this:
- Form descriptions use the "small" class for no reason and should
probably not be possible to customize ("font style"-wise) anyway.
- The use of the "small" *tag* should probably be reviewed in all Odoo
layouts and/or its interaction with the editor be fixed.
[1]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0closesodoo/odoo#149590
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug (starting from saas-16.4 only!):
- Go to the website app
- Enter edit mode
=> Bug: the editor toolbar appears for a few ms, then disappears.
This bug occurs since [1], whose original commit was actually merged in
16.0 with [2]. The reason the bug only appears in saas-16.4 and not 16.0
is because of [3].
Commits [1] and [2] change the elements that are considered "tab-able"
and thus the elements that can be auto-focused by the `useActiveElement`
hook. That hook is actually used when we enter edit mode since [4], as a
way to declare the editor as the active element so that keyboard
shortcuts work (as indicated by the related commit).
What actually happens thanks to the hook is that once we enter edit mode
the "Block" button of the right panel is focused. This is because it is
considered to be the first "tab-able" element (with or without [1]/[2]).
Then keyboard shortcuts work as expected as the right panel is focused.
However, since [3], the `useActiveElement` hook is called "too soon".
Indeed the right panel is not actually inside the "auto-focused" editor
container yet**. The result is that what is now "auto-focused" is the
editor toolbar***. Before [1], the element in the toolbar that was
focused was an invisible one, so no bug appeared. Since [1], we only
auto-focus visible elements... so we now focus a visible element in the
editor toolbar, making it visible during editor instantiation.
This commit fixes the issue independently of [3] (which is why this
targets 16.0: to consolidate the codebases). Actually, the use of the
`useActiveElement` hook added by [4] is useless. It was fixing the
issue at the time, but the real solution was to do what was done since
at [5]. Indeed, the keyboard shortcuts were not working because the
backend navbar was still visible (even if outside of the viewport) so it
was its keyboard shortcuts that took precedence. Since [5], the use of
`useActiveElement` actually has not benefit anymore. The editor is part
of the backend UI, the backend UI is still focused after entering edit
mode, shortcuts targeting the editor panel are thus working naturally.
Removing the use of the `activeElement` hook only has one side effect:
the "Block" button of the right panel is not auto-focused anymore...
which is not needed.
Notes:
- The `useActiveElement` hook also has another purpose: allowing cycling
using tab and shift-tab, it should work naturally as with the backend
UI anyway but mainly: tab and shift-tab do not seem to be working with
the editor UI anyway.
- Another hint that [4] was not right way to go is that this is the only
use of the `useActiveElement` hook in the whole codebase, except for
the framework use for dialogs.
- ** That should maybe be solved on its own, although maybe it is not
important and risky at best.
- *** The editor toolbar should not even be instantiated that way in the
first place since it will be attached to the right panel later... but
that is another issue.
[1]: https://github.com/odoo/odoo/commit/c631bf09b927003edc4c2b85e8790e8e2e8c044a
[2]: https://github.com/odoo/odoo/commit/57452ee59c3e33eaa219d8d7b8d82239fd33b722
[3]: https://github.com/odoo/odoo/commit/76d4f9811b756f0e57b0a33dbba534c900c7fe15
[4]: https://github.com/odoo/odoo/commit/b0108e1876a27e83231e176cdca3e2d67d6a2a9c
[5]: https://github.com/odoo/odoo/commit/cdc8d4c889b316664323afad0d848403960150d5
task-3686730
closesodoo/odoo#151373
X-original-commit: aa168b5583b9b437fcf83c2f7b2d256ec66e4c79
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit does 2 things:
- It prevents saving the parallax bg css properties which does not makes
sense as those properties are related to the current screen scroll
position. Each scroll position has its own css properties.
Saving those did no harm tho, as on start those were recomputed.
- It prevents flagging that parallax bg css properties change as a dirty
change by stopping the observer while changing those properties.
This is not really helping much apart from being right, since when
discarding, to know if something is dirty, it's not considering the
`o_dirty` class but doing some DOM comparison before/after, so:
- In this case, the css options are most likely still not the same,
see below "O_DIRTY EXPLANATIONS" for explanation about that part.
- There is still some stuff that will get in the way and make the
before/after DOM not the same:
- Scrolling a few px will hide the navbar and reveal the other one,
flagging it as a dom diff
- When having a few menu end entering edit mode, some will end up
in the "extra menu area" (grouped inside the "+" menu entry),
which will also be considered as dom diff
Step to reproduce:
- Enter edit mode and drag & drop a parallax snippet
- Update its "Parallax" sub-option from "Fixed" to "Bottom to Top"
- This option change adds some css properties to the `s_parallax_bg`:
top, bottom and transform. Each time you scroll, those are updated.
- Save and then inspect the source code of the page (CTRL-U)
- BUG 1: The `s_parallax_bg` was saved with those css properties set to
the values related to where the scroll was when saved.
- BUG 2: Now enter edit mode again and check that the `#wrap` is
automatically and directly set as `o_dirty`.
--------------------
O_DIRTY EXPLANATIONS:
- The "cancel" is comparing dom before and after edition to know if it
is dirty or not (and thus to know if it has to show that pending
changes modal)
- The "save", to know is something has changed and need to be saved, is
not doing that dom comparison
- Before this commit, the "o_dirty" class would be added when entering
edit mode, as the parallax would recompute its css top/bottom values,
which would differ from the ones saved in DB (because of the right
panel reducing the content size)
- Before this commit, on top of the "o_dirty" class, there would be the
top/bottom style diff too, as explained above
- After this commit, the o_dirty class is not added anymore
- After this commit, the top/bottom style is not saved in DB, but it's
added when the widget is started, meaning that there will also be a
DOM diff (before: no style, after: top/bottom style)
- On cancel, the snippets are not destroyed, meaning the style added on
the start of the parallax is not removed before considering the dom
diff
--------------------
Related PR about mitigating dirty issues: https://github.com/odoo/odoo/pull/144121
Related PR which should solve this kind of issues one day: https://github.com/odoo/odoo/pull/74923
opw-3672851
closesodoo/odoo#150994
X-original-commit: 4f8d8072a87ad0a67fbe5e61c5845d18c0e05d71
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce (17.0+):
- Go to an event website page > go to “Site” > “This Page”.
- The menu item used to edit the page content menu “Edit Event Menu” is
duplicated.
After the event page refactoring in [1], a second template using the
same content menu ID was added to customize the UI for mobile.
And since the “Edit Menu” items generation is based on detecting current
sub menus from the DOM using the same ID (`data-content_menu_id`), we
get a new menu item in the nav bar for every menu template using it.
The goal of this commit is to fix this behavior by simply ignoring the
duplicated menu IDs (The same menu record will be edited anyway).
Remark: the behavior fixed by this commit was detected in 17.0, but we
target 16.0 to prevent any potential issue linked to duplicated menus in
the DOM, also, the duplicated data attribute will be removed in master
(one ID is enough for the content menu to be detected and edited.)
[1]: https://github.com/odoo/odoo/commit/9f2442d09b62fcb3f687ec39928ea0e3ac49557e
task-3645985
closesodoo/odoo#150568
X-original-commit: e8ebb33269cbb8d049ca3e4749c486b6d137e044
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Commit [1] (later refactored by [2]) hid the buttons which allow to
edit the main website menu and custom website menus (as the ones in
event pages), when using Odoo on a mobile device. Reading the code and
related commits, this seemed to have been done for no apparent reason.
After testing 16.0, it appears that menu edition from mobile devices was
actually not working: the re-ordering UI was strangely hidden.
After investigation, it appears that this was solved by chance, thanks
to the unrelated commit [3] in 16.2. That commit indeed removes legacy
CSS which was hiding all jQuery.ui.sortable UI elements by mistake.
In 17.0, this was further improved anyway by not using jQuery.ui anymore
(with [4]) and thus editing website menus from a mobile device works now
perfectly... except that the buttons to open the menus edition dialogs
were still hidden. This commit enables them. It was chosen to do it in
17.0 and not 16.2 as it is more an improvement than a fix in the end.
[1]: https://github.com/odoo/odoo/commit/78c59afd133de8308f4eeb6e1a2a930d870878e7
[2]: https://github.com/odoo/odoo/commit/2dc82504e08cc370b67cdf1d580f26705870a085
[3]: https://github.com/odoo/odoo/commit/ee3e28987eb1ec23b8bacc7c4043d9690aada144
[4]: https://github.com/odoo/odoo/commit/a4b1c268131ed771dd68616a26a9f1ce50a189f0
Related to task-3645985
closesodoo/odoo#150530
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*website
Steps to reproduce:
- Drop a "Text-Image" snippet on the website.
- Click on a column and hide it on desktop.
- Click on the parent snippet and hide it on desktop.
-> The column is not a child of the parent in the invisible entry.
Since [1], invisible snippets are shown hierarchically in order to
better visualize the "parent-children" relation that could exist between
them. To do so, [1] based its logic on the `.o_snippet_invisible` to
find the invisible elements. However, since [2], a distinction has been
made between elements that are hidden only on desktop, only on mobile or
on both depending on some conditions. The goal of this commit is to take
the new `o_snippet_mobile_invisible` and `o_snippet_desktop_invisible`
classes into account at the creation of the invisible entry.
[1]: https://github.com/odoo/odoo/commit/922d3e63b597b1ef7fbbb5ebb4641a3ad8bdf4ed
[2]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3679823
closesodoo/odoo#150512
X-original-commit: c8f247ee5fa178f012b2852cba3d0e9322a2c3a6
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Note: This fw-port commit cherry-picked and squashed commit [2] directly
as it was fixing this original commit before it had the chance to
be forward ported.
Since commit [1], which adapted the website pages list view to OWL, the
records listed on screen are filtered according to the active website
filter. However, the full list of records is still used behind the
scenes for all potential actions.
Steps to reproduce:
1. Go to the pages list view.
2. Select a specific website (if it's not already the case).
=> The total of records in the upper right corner does not match the
number of pages on that specific website.
3. Click on the "Select all" checkbox.
=> All the pages are selected, including those that do not appear on
screen.
This is because the records were just visually hidden with a `t-if`.
[1]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
[2]: https://github.com/odoo/odoo/commit/db670f64f4c2190f1655f9077ea62885049a3c84
Courtesy of @robinlej and @detrouxdev
Related to task-3676124
opw-3554064
opw-3658648
closesodoo/odoo#149547
X-original-commit: 8d78a916dc8c0eca82e8a6a2c6f5541938709930
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Current behavior before PR:
- HTML tags are displayed in the onboarding tour.
Desired behavior after PR is merged:
- Display the HTML tag effects instead of showing it in the onboarding tour.
After the https://github.com/odoo/odoo/pull/107618 web_tour was converted into
Owl, 'markup' was required to show the html tag effect instead of htm tags.
Related Enterprise PR-https://github.com/odoo/enterprise/pull/53893
Task-3457112
closesodoo/odoo#149957
X-original-commit: c26ba2943317e82388bc05adfd64fa729923a86b
Related: odoo/enterprise#54622
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit resolves an issue in the `link_tools` test, specifically
addressing a failure that arises when verifying the synchronization
between the link's href and the content of the `<a>` tag. The failure
was attributed to the oversight of not clicking outside the popup to
close it before interacting with the link.
Note: the race condition that occurs in this test was very rare and was
reduced a lot by [1], its parent commits and their related forward-port.
The last version of this commit here actually does not seem to change
much but the code speaks for itself: this is how it should be written.
Further race conditions need to be fixed in this test again anyway.
This also modifies some steps to make them clearer.
In this forward-ported version, it actually patches what was done at [2]
by adding back the "input" trigger that the original commit added with
commit [3]. It also removes the outdated wait for popup opening that was
fixed the right way with [1] and its parent commits.
Final note: in this forward-ported version, the test systematically
fails on the same step, with or without this commit. Further PR will be
made; but for now, this unify what we have in all versions, hopefully.
[1]: https://github.com/odoo/odoo/commit/9b26aafbc1576b08c409344d22ec179bd32a3bd7
[2]: https://github.com/odoo/odoo/commit/7d26c7b666033a16acfb430b6bf06235dd7d88ea
[3]: https://github.com/odoo/odoo/commit/b2a79ed9960d88d1bdf6465389f4ef720f6bc235
runbot-24929
closesodoo/odoo#149871
X-original-commit: b38b40fde5cc2396b0b8b20332a5b80935eb1814
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit addresses an issue where the text selection would disappear from
editor when clicking on the font size option from the toolbar.
Modifications:
- The issue of text selection disappearing when interacting with the font size
dropdown has been fixed.
- A new toolbar option, `customFontSize`, has been added. This option is
exclusively enabled for editor that have a toolbar in the same document.
The `readonly` attribute has been added to the input field to make it read-only
in our scenario, providing dropdown functionality for font size in the editor.
However, the functionality remains unchanged for the website.
task-3500827
closesodoo/odoo#142808
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
This commit addresses an issue when the logo is in text mode and we
want to click on the `logo` check button under the `Header`/`Elements`
options.
The bug manifested itself in [this commit] during the redesign of the
website template headers. The logo button, initially assumed to have two
states, is, in fact, comprised of three: None, Text, and Logo. To
address this issue, a workaround has been implemented, treating None and
Text as a single state. Consequently, if the current state is Text or
None, toggling will transition to Logo, and conversely, if it is Logo,
the toggle will shift to None.
Steps to reproduce:
- Enter edit mode.
- Click on the header navbar.
- Click on the logo.
- Go to navbar brand options and choose "Text" in the dropdown Logo
selector.
- The website is now saved. click on the button `LOGO` under the
"Header" -> "Elements" option.
- An error occurs: the template is not well-formed or wrong.
[this commit]: https://github.com/odoo/odoo/commit/e5380a8e40be47cddf53aa24ff01e7c6802bbdb7
opw-3624285
closesodoo/odoo#146839
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Commit [1] added the support for images with a link set on them in grid
mode.
As a follow up, this commit does the following:
- Removes the `!important` from the grid image anchor CSS rules, as they
were not really needed.
- Checks if the image has a closest `o_grid_item_image` column instead
of checking the parent in the `GridImage` options. Indeed, this class
already guarantees that the image is well a grid image; we can therefore
simplify the code.
It also removes a comment that was forgotten in commit [2].
[1]: https://github.com/odoo/odoo/commit/085d70cea571ea80c141ac6005e8bd8333bd269f
[2]: https://github.com/odoo/odoo/commit/d8c374e3e6b31bf88aa42952aadf3379936f7600
related to opw-3580128
closesodoo/odoo#149681
X-original-commit: 9244e85ebb9e1605292698fe31ad94da7709ab86
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
bug 1:
- Enter edit mode.
- Drag and drop an "Image Gallery" snippet onto the page.
- Double-click on an image within the snippet.
- In the media dialog, click the "Video" tab.
- Copy-paste a YouTube video URL into the URL input.
- Save the media dialog by clicking on the "Add" button.
- Bug: The video is very small.
bug 2:
- Drag and drop an "Images Wall" snippet onto the page.
- Double-click on an image within the snippet.
- In the media dialog, click the "Video" tab.
- Copy-paste a YouTube video URL into the URL input.
- Save the media dialog by clicking on the "Add" button.
- Bug: the spacing around the video is not correct and the "spacing"
option does not work for the video.
Note that the "image gallery" snippet (also the "image wall" snippet)
was not initially designed to handle anything other than images. When
you click on the "Add" button of the snippet, you can only add images.
However, by following the steps described above, it's possible to work
around this limitation and add a video to the snippet. Since this was
not part of the original plan, several options do not function correctly
with a video.
Instead of preventing the addition of videos, we have chosen to allow it
and focus on fixing the main issues (the small size of the video and the
"spacing" option which does not work with videos). So, if someone
specifically wants to add a video, it's currently possible, though some
features may not work as intended.
task-3597156
closesodoo/odoo#149679
X-original-commit: 73f60e97a1b534b5f8dd3759bd631f9aac095426
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Commit [1] changed the class from .ui-draggable to .o_draggable in the
`snippet_version` test, specifically in the run function that checks
if all snippets have their `[data-snippet]` properly set.
Indeed, `.o_draggable` is set on the parents of draggable elements and
not on the elements which are draggable themselves. This lead to a
`.every` on an empty array which returns `true`, and therefore avoids
the `console.error` but did not properly check the snippets.
This commit changes the selector to all snippets which do not have
a [data-module-id] which should be all snippets that are draggable.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
Related to task-3079246
closesodoo/odoo#148824
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
*: 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
This probably does not change much but it short-circuit a bunch of code
when we click outside of an editable zone and something in the DOM
happens. Allows for easier debugging of mutations. It also avoids the
creation of a jQuery object when the mutation is about changing a
contenteditable attribute, I guess any small perf improvement should be
welcomed.
Related to runbot-18747
X-original-commit: f93a2da57e1424898fbf6e157945e2afa97be89e
Part-of: odoo/odoo#148728
The range widget doesn't work with Serbian language, because language
locale subtag contains `@`.
Steps to reproduce:
1. Activate Serbian Latin language (sr@latin) on your website
2. Go to /shop
3. Switch to Serbian lang
The price ranger slider (which can be disabled) will throw this TB:
"RangeError: Incorrect locale information provided".
The fix is to do as other places in the code: replace this specific
lang code with the expected one.
Ideally, a util method should be used at all those places.
closesodoo/odoo#148593
Forward-port-of: odoo/odoo#148279
Signed-off-by: Romain Derie (rde) <rde@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>
Originally, restricted editors don't have the rights to edit the SEO of
a record.
It was probably a bad idea as they can already edit the record itself
and can change the name / description of the record in the page.
Changing the SEO seems to be very similar.
Also, for our internal needs, we need our HR people (which are
restricted editor with rights on jobs position) to be able to edit the
SEO of their jobs. And we don't want to grant them the full editor
right.
Note:
- We already have a `data-can-optimize-seo` attribute set on the HTML
tag if one is logged in, but this is just about knowing if the record
has SEO-mixin capability, it does not check the rights for a given
record.
- In master, one day, we would like to have the "Edit" button shown only
when something can be edited for restricted editor (to not be able to
enter edit mode to then not be able to edit anything). The same would
be nice here: optimize seo menu could only be shown if you have the
right, but we don't want to do an extra RPC each time for now.
- We keep the info shown in readonly mode so the restricted user can see
it and ask for a change to someone else if needed
Related commits:
- https://github.com/odoo/odoo/commit/94e2eefca28196efc0ac38f155a3b85acbbdeaae
- https://github.com/odoo/odoo/commit/21464edf7ce858c065e113e32d857dfa4ace1788closesodoo/odoo#147981
Signed-off-by: Jérémy Kersten <jke@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>
Since [this other commit], the recipient email option of the form on the
`/contactus` page is not filled correctly with the company email.
By chance, the form signature task fixed the bug but introduced another
one. The previous commit fixed the bug introduced by the form signature
task but reintroduced the inital bug. This commit fixes the initial bug
and adds a test.
By default, the form on the `/contactus` page sends emails to the email
address of the company. Unfortunately, before this commit, when a user
entered edit mode, the Recipient E-mail option always displayed
"info@yourcompany.example.com" even when the company's e-mail address
was different. This commit corrects this by displaying the dynamic value
of `company.email` in the Recipient E-mail option coming from the
data-for.
Steps to reproduce the issue fixed by this commit:
- Go to Settings > General Settings
- Update the company's email address
- Go to /contactus and edit
- Click on the form
=> The recipient email value is still "info@yourcompany.example.com"
instead of the company's email address.
This commit fixes the issue, adds a test to ensure the recipient email
option is correct and adds a utility to parse the data-for data.
Bonus: this commit also fixes the following issue catched by sentry:
- Go to /contactus
- Click on Edit
- In the Form option, remove the content of the 'Recipient Email' field.
- Save
- Fill and submit the form
=> An error is generated in the log.
[this other commit]: https://github.com/odoo/odoo/commit/043e1fdf923d2037dd8da128ab99388f0c92e544
task-3382195
sentry-4633940473
closesodoo/odoo#147933
X-original-commit: 56f6b8dccec5cebc9a93454538b39886d4d3f63c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The email_to field of the contactus form have to be dynamic except if
the user manually set it via the form options. Unfortunately, the
website signature task broke this feature. This commit fixes it and adds
a test to prevent this regression in the future.
Steps to reproduce the bug:
- Go to the contactus page
- Edit the page
- Add a field on the form
- Save the page
- Change the company email address via the settings
=> The contactus form still send the email to the old email address.
Related to task-3382195
X-original-commit: 10b4db60fbd077936b5c9586485fa40c3c890d3f
Part-of: odoo/odoo#147933
Steps to reproduce
==================
Go to Maintenance > Studio > Website > New Form
Click on the website editor
Click on the name field
UncaughtPromiseError > KeyNotFoundError
Cause of the issue
==================
Starting from 17, the FormEditorRegistry is not the legacy one.
If the key is not present in the registry, it will fail, unless we pass
a default value.
In this case, the key `website_form_key` is false.
Solution
========
Pass null as the default value.
opw-3652423
closesodoo/odoo#147840
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Add a "Form" snippet on the website.
- Select the first field.
- Try to toggle the "description" option of the field.
-> Problem: there is no description added on the field.
The problems appeared since [this PR] and comes more precisely from
[this commit]. The problem is that one condition required to fill the
`default_description` parameter is that `field.type === "description"`.
This should not be the case. Indeed, here was the flow before
[this commit]; When the user toggled the description option,
`toggleDescription` assigned `field.description` to `true`. The field
was then rendered trough `renderField()`. During this rendering, the
system called the `website.form_field_description` template through
`website.form_field` independently of the field type. Because
`field.description` was set to `true`, a `div` with the description
"Describe your field here." was added on the rendered field. To solve
the problem, the `field.type === "description"` condition has been
removed as a condition to set the `default_description` parameter. Now,
as it was the case before [this commit], this parameter is filled either
if `field.description` is set, either if the field name is `email_cc` or
`email_to`.
The error probably comes from the fact that the name of the template
used to render the field is `"website.form_field_" + field.type`. As the
name of the template in charge of rendering the description is
`website.form_field_description`, the author probably thought that this
template should only be called when `field.type === "description"`. This
is not the case; the template `website.form_field_description` is always
called when rendering a field (independently of the field type through
the template `website.form_field`) but is only relevant if
`default_description` is set.
Note that this fix fixes also another bug:
- Add a "Form" snippet on the website.
- Add a field which is of type "Cc".
-> Problem: there should be a description of type "Separate email
addresses with a comma." on the field.
This commit also adapts the `website_form_editor_tour` tour to verify
that the description option works as wanted.
[this PR]: https://github.com/odoo/odoo/pull/130467
[this commit]: https://github.com/odoo/odoo/commit/363251986dcd753796b4b037a2da2e118b3e8e35
opw-3630348
opw-3604548
closesodoo/odoo#146115
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
`onDuplicate` was marked as optional while it never was. If you don't
specify it, the call to `this.props.onDuplicate();` will still be
executed and will crash:
`Uncaught Promise > this.props.onDuplicate is not a function`
Randomly spotted while reviewing PR about duplicate button in list view
related to opw-3640878. But it's not related to it.
closesodoo/odoo#147647
X-original-commit: 296feaa9aa16cdb1766ce8d2f5ae8126d74f881b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Each date in the timeline snippet was displayed with the time line going
through them. The line is supposed to be cut around the date. This
occurs since [1] which made it so `<span>` elements are automatically
removed by the editor if they do not have any attributes. Unfortunately,
this snippet relied on such a span, since [2]. This commit solves the
issue by making the snippet better (and the XML structure will further
be improved in the master forward-ported version). Unfortunately, this
is not entirely stable, even though it leads to the exact same result
provided no custom code tweaks the snippet. It will also solve existing
timeline snippets in current databases.
Note: [1] was obviously a mistake to merge in stable, although it might
be kept seeing the delay since it was merged and nothing critical seems
to have happened.
[1]: https://github.com/odoo/odoo/commit/a26e27c85e6a0685b6cf4d2dbab90453899df34c
[2]: https://github.com/odoo/odoo/commit/fbe38fb41dfdb76878748a1149f93700b566d228
task-3657771
closesodoo/odoo#147598
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
A anchor menu in the mobile offcanvas related to an element in the
current page doesn't work in offcanvas:
- The offcanvas doesn't close
- The page doesn't scroll to the clicked location
This is because the menu anchor navigation is hooked to use our own
scrolling behavior instead of the browser one.
Doing so, we preventDefault, which prevent the offcanvas menu to close
itself when clicking on a anchor menu.
This commit simply manually closes the offcanvas and once the closing
animation is complete, starts our own smooth scrolling.
It also targets the desktop offcanvas menu (when hamburger layout is
selected) so it got a smoother UX: it closes then scrolls, instead of
scrolling but not closing.
Another possibility would have been to just close manually the offcanvas
without a preventDefault and without a call to our custom scrolling
method.
Doing so, the browser would naturally scroll to the element while we
close the offcanvas but it would be less elegant as you wouldn't see the
scrolling animation.
Note that the offcanvas was introduced with commit [1].
[1]: https://github.com/odoo/odoo/commit/bc13176de8d66bbdc1c536017b1f046c5fd31a86
opw-3604963
closesodoo/odoo#146907
X-original-commit: db881e66785a866319bd4980a9ae7b6393e55457
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
Steps to reproduce:
Go to the website's home page > Site > Properties > The control panel
buttons in the footer of the "Page Properties" dialog are not aligned
correctly.
The "Page Properties" dialog extends the `FormViewDialog` component and
updates its template using `xpath` to add extra buttons on the right
side of the footer (to "duplicate" & "delete" the current page).
But since [1], a `w-100` class has been added to the default button
container (`.o_cp_buttons`) on form view dialogs to get the same result
as the "More Options" button on `Calendar > Quick Create` dialogs (the
difference here is that the extra button was added inside the default
buttons wrapper, while on page properties, the buttons are added next
to it).
The goal of this commit is to "safely" fix this misalignment issue on
stable by simply removing the `w-100` class for the page properties
dialog. On master, we will adapt the page properties buttons to have
the same structure as on the calendar dialog.
[1]: https://github.com/odoo/odoo/commit/7dd6e5d1a55de99a4212abc6f24490e47d9ce5bb
task-3642712
closesodoo/odoo#146541
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Using the animation option on an image can turn the image src from
relative to absolute.
It then makes our code crash in some cases (multi domain & cors
protected img). The previous commit makes sure to protect this case by
making the code more robust.
This commit is fixing one of the detected root cause (explained in
previous commit).
The fixed code was introduced with commit [1].
Since we can't guarantee our code has no other way to turn relative into
absolute url, neither that we won't introduce new code doing that, the
very small safety net from previous commit has to be keep as defensive
programming.
[1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85closesodoo/odoo#146731
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The image mouseover animation, introduced with [1], can crash through
legit UI flows:
- Visit your website on domain 1 (you will need to access the same
website from another domain later):
1. On local: use http://localhost:8069/ and http://127.0.0.1:8069/
2. On runbot: use master-all and master in URL
3. On odoo.com: use xyz.odoo.com and xyz.com
- Drag & drop "Text - Image" snippet
- Double click on the image to replace it
- Upload any image
- Click on the image and set its "Animation" option to "On Hover"
- Save
- Outside edit mode, mouseover the image to see the animation
- Behind the scene, the img src is changed from /web/image/xyz to a
hardcoded base64 value to show the animation
- Now enter edit mode, the system will actually reset the src to the
original src (to replace the b64) but it will replace it by an
absolute link and not the initial relative link
- Edit the text below the image, BUT DON'T MOUSEOVER THE IMAGE
(otherwise the absolute url would be turned into b64)
- Save, again DON'T MOUSEOVER THE IMAGE
- Now go on your second domain to access the same page
Bug: Mouseover the image, a `Uncaught Promise > Failed to fetch` error
will be raised because of a CORS error.
Indeed, on http://localhost:8069/, simply doing this in your debug tool:
```js
fetch('http://127.0.0.1:8069/website/static/src/img/snippets_demo/s_image_text.jpg')
```
will throw the same error.
Note: we can't just modify the CSP rule(s) to allow that domain because
we have no way to know which domains are safe and really domains from
the same database:
- When you are on xx.odoo.com, there is no way to know that xx.com is
also your domain for the same website. At best it will be set in the
website domain but it's not always the case (often not the case in
mono website)
- When you are on xx.com, we have no way to know that xx.odoo.com is
also your domain for the same website. At best it will be set in the
ICP `web.base_url` but until that ICP is actually frozen, it will
change every time the admin logs in the database.
[1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
Part-of: odoo/odoo#146731
Before this commit, when a user uploaded a webp logo through the website
configurator, the colors of the logo were not detected. This commit adds
the possibility to detect the colors of a webp logo.
task-3609329
closesodoo/odoo#145047
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Before this commit, when a user was uploading a logo for a website via
the website configurator, the logo was added as an attachment but the
potential previous logo was not deleted. This commit fixes this by
deleting the previous logo when a new one is uploaded.
Steps to reproduce the issue:
- Create a new website
- Fill the configurator until you can upload a logo
- Upload a logo, then upload another one
- Finish the configurator
- Edit a page of the website
- Change an image
=> You can see the first logo you uploaded in the list of images.
task-3609329
Part-of: odoo/odoo#145047
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>
Benjamin Vray
