[This first commit] made it possible to have an error when there was no
comparator for a field with conditional visibility. [This second commit]
prevented an error from occurring in this case. The purpose of this
commit is to prevent the user from getting a conditional visibility
configuration for a form field where there is no comparator.
Steps to reproduce the problem:
- Go to /contactus.
- Edit page.
- Click on the "Your Company" field.
- Select "Visible Only If" for the "Visibility" option.
- Click on "Visible Only If" again.
=> The comparator is not defined.
Another way to have the issue was:
- Drop a form on a page.
- Click on the "Your Company" field.
- Select "Visible Only If" for the "Visibility" option.
- Set visible only if Your Name is equal to "test" as condition.
- Click on Your Name field.
- Change the field type to Radio Buttons.
=> The comparator is not defined.
This commit fixes those two cases.
Technical information:
When we change the field's visibility to conditional (`setVisibility`),
we add a default visibility dependency (`_setVisibilityDependency`). At
this point, the comparator is removed and added in `_renderCustomXML`.
`_renderCustomXML` was only called if the visibility dependency had
changed.
[This first commit]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
[This second commit]: https://github.com/odoo/odoo/commit/808780c89cfba940957f7410f787de31e31bda27
opw-3806409
closesodoo/odoo#161527
X-original-commit: 770cc162d6de82818d8e29bf156bb01f65ca8e2c
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit, when adding a new grid item in a grid by using the
"Add Elements" option, if the page was scrolled such that the top of the
grid was not visible, this new grid item may not always be visible. This
is annoying as the user could add an element and not see where it
appeared and would therefore need to look for it.
This commit fixes this by making the page scroll to the added grid item
if more than half of it is not visible. A test is also added.
Steps to reproduce:
- Drop the "Text-Image" snippet and enough snippets under it to have a
scrollbar.
- Toggle the "Text-Image" snippet to grid mode.
- Scroll the page so the top of the grid is not visible.
- Add a new "Button" with the "Add Elements" option.
=> The button is not visible.
task-3616138
closesodoo/odoo#161159
X-original-commit: 50766b74196b3cdc5ac83d7962873f4fffa4c9f6
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Since commit [1], the "tempusdominus" date(time) picker has been
replaced by the OWL date(time) picker. A traceback appears when loading
a website form containing a field dependent on a date(time) field.
This traceback occurs because when checking the value of an empty
date(time) field (which happens when the user hasn't yet filled out the
form), we parse the field value into a Date(Time).
Before the changes in commit [1], we parsed this differently, which
didn't crash but returned "NaN" with an empty date(time) field.
In this commit, we now check whether a date(time) is valid and if not,
we now assign it "NaN" to maintain exactly the same behaviour as before
the commit [1]. Any value other than "NaN" would not work with the date
comparison system and would break certain conditions.
This commit also adds steps to the "website_form_editor" test tour so
that it fails without this commit.
[1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
task-3790809
closesodoo/odoo#158288
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Starting from The "unbreakable menu fix" on `16.0` (see: [1]), the state
of the website extra menu was stored before every "resize" adaptation,
so it can be possible to reopen it if it was already opened.
On `17.0`, the same behaviour was fixed using the `odooEditor` >
`withoutRollback()` mechanism (see: [2]), and a step was added to the
`edit_menus` test (`clickOnExtraMenuItem`) to open the extra menu after
the "edit mode resize" [3].
The forward port of [1], on `17.0` was adapted to keep the main fix from
[2], and removed the tour step since the extra menu will be
automatically opened if it was already open before the "resize".
Now, if we have a menu with no overflowing items before the resize, and
after switching to "edit" mode an extra menu was added, this menu will
be closed by default which makes the test fail without the step in [3].
The goal of this commit is to fix this behaviour by simply restoring the
`clickOnExtraMenuItem` step with a simple tweak: We don't click if the
extra menu is already opened to prevent closing it again.
Remark: the test failed on `17.0` but the commit is targeting `16.0` to
prevent any test failure linked to the "extra menu auto open" feature.
[1]: https://github.com/odoo/odoo/commit/2598cc9ef7fe89a0ce5e375bca6f6a781f6ffdf7
[2]: https://github.com/odoo/odoo/commit/cbed990924887eb529056d89a042a92ba27b825b
Related to opw-3484742
Related to task-3439226
closesodoo/odoo#157290
X-original-commit: 42bcc3ef284ca355e2323641176573b53e7d2e28
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Steps to reproduce [17.0+]:
- Create a website form of any type in which you have:
- One "Name" or other text field.
- One field with the "Date" type.
- One field "Email" with the visibility condition: "Only visible if"
a field of type "Date" "Is set".
- When you complete the "Date" field, the "Email" one should show but it
does not > It shows if you also add at least two characters to the text
field.
Starting from [1], an OWL date picker component was introduced mainly to
replace the use of `TempusDominus` and `DateRangePicker` libraries.
After this change, an adaptation (from [2]) was done to completely
replace every usage of `TempusDominus` with the new OWL component
(including the form date[time]picker fields).
One of the lost features from `TempusDominus` was the trigger of an
"input" event on date [time] change, which also triggers the form field
visibility check.
The goal of this commit is to fix this behaviour by simply updating
fields visibility on every component value change.
[1]: https://github.com/odoo/odoo/commit/b5794e89e1ad29e2a86c7ddaf241e3fc24654b5f
[2]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
opw-3778129
closesodoo/odoo#157328
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1], image options like "Filter" are kept when a user changes the
position of an image in an "Image Gallery" snippet. [1] also adapted the
`snippet_image_gallery` tour (moved in `snippet_image_gallery_reorder`
from version 16) to test this behavior. To do so, the test adds a filter
on an image in an "Image Gallery" snippet, checks that the filter is
displayed on the editor panel, moves the image, clicks on it and finally
checks that the filter is still displayed on the editor panel. The
problem is that the steps that check if the filter is displayed on the
editor panel are the same before and after the move of the image which
means that the second check is true also before the move of the image.
This situation is a typical case where an undeterministic error could
happen. Indeed, we do not know if the second check tests an old value or
an updated one.
To solve the problem, the test has been adapted; after the move of the
image, the test clicks somewhere else (on the footer in this case), and
then back on the moved image to finally check that the filter is still
displayed on the editor panel. The goal of the click on the footer is to
be sure to have a loaded version of the editor panel. By doing so, we
remove the risk of an undeterministic error situation where a condition
is already true before an action is done.
Note: this problem has been discovered because the test
`snippet_image_gallery_reorder` succeeds on version 16.3 without the fix
of [1]. Now, the adapted test fails on version 16.3 without the fix of
[1].
[1]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481
task-3717041
closesodoo/odoo#157207
X-original-commit: e7a17fd27abed655258856a83668552c2930170c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Steps to reproduce the bug:
- Go to an event "Introduction" page
- Enter edit mode
- Click on the pre-existing "Introduction" title (note that it cannot
be removed because of the way the page is built, we might want to
improve that in master)
- Save it as a new custom snippet
- Go to your homepage
- Drop that new custom snippet that was saved
=> It cannot be removed, the rest of the content is kinda broken as
wells, etc etc.
This is because the original branding was saved with the snippet.
Indeed the event pages are made in such a way those pre-defined titles
are snippets but which are "editable root elements", i.e. elements
whose ancestors cannot be edited since themselves or their neighbors
contain dynamic elements.
opw-3633326
closesodoo/odoo#157191
X-original-commit: 356b8ce1070243ce69b5ba75d4988fcee6bc6190
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since the commit [1], a new element called "o_header_hide_on_scroll" was
introduced in some header templates. This element has the feature of
gradually decreasing its height as you start scrolling the page until it
completely disappears. To reduce the height of this element without
leaving its contents fully visible (because they maintain their height),
we added an "overflow: hidden" property on it. However, this "overflow:
hidden" introduced a bug fixed by this commit. Due to this, the
dropdowns within the "o_header_hide_on_scroll" element, like "user menu"
dropdown or "language selection" dropdown, became invisible.
Steps to reproduce the bug:
- Go to Website edit mode.
- Click on the header.
- Choose the "Menu - Sales 2" template from the options.
- Select the "Fixed" Scroll Effect from the options.
- Click on the "User Menu" dropdown in the header.
- Bug: The dropdown menu does not appear. The same issue occurs if you
type something in the search bar; the dropdown with the results does not
appear either.
To fix this, we don't apply "overflow: hidden" on the
"o_header_hide_on_scroll" element when the page hasn't been scrolled
yet. And if the page has been scrolled just a bit and the user clicks on
a dropdown or the search bar, we scroll the page to the top first, and
then display the dropdown menu.
This commit also add a test tour to prevent the bug from reappearing.
[1]: https://github.com/odoo/odoo/commit/143d475c3ab8d755906807bda8edb655c6dd22eb
opw-3698887
closesodoo/odoo#154979
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
*: test_website_modules
In PR [1], the headers have been redesigned. One of their major changes
is that now, they have two navbars: one for the desktop view and one for
the mobile view.
However, the `o_main_nav` and `top_menu` navbar ids are also duplicated,
meaning that there are multiple elements with the same id in the DOM,
which is not a good practice.
This commit fixes this by replacing the ids by classes in the navbar
templates, since their use does not really require for them to be ids
(e.g. `#o_main_nav` is mainly for styling). For the desktop view, the
ids are still kept (for stability purpose).
Note that the CSS rules and the selectors in the JS files (except for
the tests) now take into account both the ids and the classes (to be
safe).
[1]: https://github.com/odoo/odoo/pull/119650
task-3609531
Part-of: odoo/odoo#146492
Commit [1] introduced some code that relied on a cache we currently have
for processed** images. In case of 404, that cache is not filled... and
relying on it thus crashes.
This commit circles around the issue by taking profit of [2] which now
forces `loadImage` to load a placeholder image in case of a 404. This
makes sure that in case of a 404 during the initial call to `loadImage`,
the rest of the stack works with the loaded placeholder image.
**Note: the current cache is not filled at the `loadImage` level, but
later when processing the fetched image. This should be changed in the
future (a task has been created).
See [3] and [4] which are example of unwanted 404 images due to other
issues, which allowed to discover this bug to fix here.
Steps to reproduce:
- Go on the `website.s_picture_default_image` ir.attachment form view
- Change the URL value to a relative path that does not exist
- Go on a website page and edit
- Drop the "Picture" snippet => Crash
=> After this fix, no crash but you can also edit the image if you were
able to click on it, it would use the placeholder image as source.
[1]: https://github.com/odoo/odoo/commit/567e5b58d544e4e56c3a68d148e862a516d77c4f
[2]: https://github.com/odoo/odoo/commit/0639c5028c69d8e29c8438b741cc4713d875b06d
[3]: https://github.com/odoo/odoo/pull/155015
[4]: https://github.com/odoo/design-themes/pull/767
Related to opw-3693055 and others (see [3] and [4]).
closesodoo/odoo#155275
X-original-commit: fbc6a697c1adf67ee8a90c49b0150d6ca170e081
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when the mega menu were first introduced, to make their
edition possible, the bootstrap dropdown behavior was neutralized by
removing the `data-[bs-]toggle` attribute.
In [2] when Bootstrap was upgraded to version 5.1.3, the
`dataApiKeydownHandler` event handler that is called when up, down or
escape are pressed raises an error if `data-bs-toggle` cannot be found
on a previous sibling of the dropdown. This makes the approach chosen
in [1] incomplete.
This commit avoids this issue by temporarily adding a class that
is excluded from the event handler selector.
The patch must unfortunately be applied within bootstrap itself because
the event handler is registered right after the method is defined and
we have no way to access the registered event handlers afterwards.
This makes it impossible to patch the called method from outside, nor
its associated selector.
We cannot simply update the selector that was already patched by [3]
because it is also used by other methods.
A test is included which should mitigate the risk of accidentally losing
this patch upon bootstrap upgrades.
Steps to reproduce:
- Create a mega menu.
- Edit the page.
- Open the mega menu.
- Click inside the mega menu content to have a cursor selection.
- Press the arrow up key, the arrow down key or the escape key.
=> An error dialog was displayed.
The same issue happened with a nested menu instead of a mega menu.
[1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
[2]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[3]: https://github.com/odoo/odoo/commit/daca8fe4e3da4a5ad5fabf3730496a3919af8abc
task-3614926
opw-3741670
closesodoo/odoo#155019
X-original-commit: 48f0c4203ceb5e770fed6193bd6382690b1b62fe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
Note: this commit was not needed in previous version.
runbot-57204
closesodoo/odoo#154679
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
Note: this commit was not needed in previous version.
runbot-57204
Part-of: odoo/odoo#154679
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
Note: this commit was not needed in previous version.
runbot-57204
Part-of: odoo/odoo#154679
See parent commit for more details. This commit disables the remaining
problematic step in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
runbot-57204
X-original-commit: 60b2b182473beaa4e338d8345f8aa4a5984336dd
Part-of: odoo/odoo#154679
The test `test_15_website_link_tools` associated with the 'link_tools'
tour has been problematic for a long time. Many fixes have been made
already, mainly [1] but also [2], etc.
As of today, the test now succeeds 100% of the time in 16.2 and below.
Starting from 16.3, the tests still contains race conditions. As a first
step towards fixing those, we will first disable the problematic steps
so that we can re-enable the test on runbot. First, this commit is about
unifying the 16.3 version of the tour with the previous versions (16.2).
Indeed, while the test currently tests the same things as 16.2, for no
apparent reason (see [3] and others):
- Some phases of the test were reordered during the forward-port that
introduced them.
- A new "Popover should be shown" step was added during some
forward-port (it is actually one that is the cause of a race
condition, see below).
- 16.4 and above: many new steps which save/re-enter edit mode were
added, random clicks were added, trigger were changed, check were
rewritten for no reason, etc... none changed the race condition rate
(if anything, it worsened in 16.4, see below).
- 17.0 above: some useful steps were added and do not seem to impact the
success rate, this commit of course keeps them.
This commit thus:
- Reorders the steps the same way as 16.2.
- Temporarily disables the problematic new step.
- Removes all those useless changes.
Here are some tests made in all those versions (before this commit):
=> 16.2 and below:
- Tested: 100% working
=> 16.3:
- Tested: 162
- Failed: 88
- 57 on "Check popover content is up-to-date"
- 31 on "Popover should be shown"
=> 16.4:
- Tested: 30
- Failed: 28
- 24 on "Check popover content is up-to-date"
- 4 on "Popover should be shown"
=> 17.0:
- Tested: 80
- Failed: 80
- 69 on "Check popover content is up-to-date"
- 10 on "Popover should be shown"
- 1 on "Check that links's href was updated"
=> 17.1:
- Tested: 83
- Failed: 83
- 64 on "Check popover content is up-to-date"
- 17 on "Popover should be shown"
- 2 on "Check that links's href was updated"
=> master:
- Tested: 37
- Failed: 37
- 26 on "Check popover content is up-to-date"
- 11 on "Popover should be shown"
Note that this commit actually seems to reduce the race conditions...
which is of course not a solution on its own. The next commit will
disable the problematic steps to have the test pass 100% of the time,
until a real solution is found.
=> Tests with this commit:
- Tested: 11
- Failed: 4
- 4 on "Check popover content is up-to-date"
[1]: https://github.com/odoo/odoo/commit/da9afc46e32111afbe0f4bdae6d539795239290a
[2]: https://github.com/odoo/odoo/commit/06f9a21c60b4bf7d375bdaba3fd4c8bc89d16b54
[3]: https://github.com/odoo/odoo/commit/9fc283b514d420fdfd66123845d9ec3563572692
runbot-57204
X-original-commit: 155bfd45b0678d69ed34d4e832df5a331a91a551
Part-of: odoo/odoo#154679
Steps to reproduce:
- Go to Website > Add menu items in a way that activates “auto-hide” (to
set the overflowing menu items in a “+” dropdown) if the viewport was
resized.
- Go to “edit” mode (adding the sidebar reduces the current window
width) > The “auto-hide” menu adaptation is disabled, and overflowing
menu items are still visible.
On [15.0 - 16.4]:
The original commit fixed the behavior described above by preventing the
unbreakable mechanism from detecting header changes and canceling the
auto-hide updates (see: [X-original-commit]).
In addition to the main fix, some other changes were also added to allow
correct editing of extra menu items [1]:
- The `_adapt()` debounce was replaced by a throttle that applies the
first menu adaptation immediately.
- We remember the state of the extra menu dropdown (open or not) if it
is there, which will be restored after the menu adaptation.
- When clicking inside an extra menu item, The extra menu is closed. We
prevent this default behaviour in "edit" mode.
Starting from 17.0:
The code from [2] fixed the same editor's rollback issue by using a
`withoutRollback()` to ensure that the `_adapt()` is called without
triggering any rollback.
This commit will only forward-port the adaptations from [1] since the
rollback issue was fixed using the new `withoutRollback()` tool.
[2]: https://github.com/odoo/odoo/commit/cbed990924887eb529056d89a042a92ba27b825b
Related to opw-3484742
closesodoo/odoo#153566
X-original-commit: 4713f95f18d7326b553464c0be6fdcd68b330292
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Add an "Image Gallery" on the website.
- Add a new image on the snippet.
-> Problem: the thumbnail of the first image of the carousel has been
replaced by the new added image.
To solve the problem, the triggering of the `image_changed` event has
been removed on extra image added. It was introduced by [1] to trigger
the re-rendering of the thumbnail when adding a new image on the
carousel but was actually useless. Indeed, the mechanism was the same as
now; when a new image was added on the carousel, the
`website.gallery.slideshow` that already handles the thumbnails was
re-rendered. An important thing to note is that the system was also
never intercepting this `image_changed` event as it was triggered on an
element that was not in the DOM (as it was removed at the
`_replaceContent()` call in the `slideshow()` method). However, since
[2], the images rendered by the `website.gallery.slideshow` are replaced
by the images (or the wrapped anchored images) returned by
`_getImgHolderEls`. Therefore, `$newImageToSelect` is part of the DOM
and the `image_changed` event is intercepted by the gallery option. As
the active carousel item is always the first one of the carousel after a
`website.gallery.slideshow` re-rendering, the system changed the
thumbnail of the first item with the new added image.
[1]: https://github.com/odoo/odoo/commit/85990768592cbdefbb178b5ffa38c1e29b9eeb87
[2]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481
task-3736301
closesodoo/odoo#153717
X-original-commit: 3c4239212e7bedc3cb49f34d9eb0a23c3de0cbd6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@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>
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>
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>
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>
*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>
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>
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
*: 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>
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:
- 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>
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>
In the past, it was possible to drop elements in non-editable areas.
Commit [1] fixed the issue but then commit [2] added a solution to be
able to edit a media element that is in a `o_not_editable` environment.
Unfortunately, the solution makes it possible to drop elements next to
the `o_editable_media` elements ignoring the editable context (ignoring
the first fix).
Steps to reproduce the issue:
- Enter website edit mode
- Drop a Team block in a page
- Click on the Team block
=> The user is able to drop a "Text highlight" block next to the team
member pictures.
This commit
- reverts the commit [1] because in the meantime, the commit [3] fixed
the issue.
- fixes the Team block issue.
- fixes the filterFunc for the drop-in.
- adds a test to ensure the issue doesn't come back.
[1]: https://github.com/odoo/odoo/commit/67924648676b37898aedd86bc32868299aee542c
[2]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[3]: https://github.com/odoo/odoo/commit/ae7452f18dbd6ed56dbf883ae8495382b336aa78
opw-3536227
closesodoo/odoo#144806
X-original-commit: 9b4c2498b8fa2bc0aca604b6256e6c805b9b4c10
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
When using the "Social Media" snippet, there are two situations leading
to a traceback. Here are the steps:
1) First issue
- In edit mode, drop the "Social Media" snippet.
- Add a new social network.
- Replace the icon by a real image (so not by an other icon).
- Set the URL of the new social network to a "relevant" one (e.g.
google, facebook).
=> traceback
2) Second issue
- Drop "Social Media" and change the list in order to have the first
social network with a real image as icon: either replace the first icon
with an image, or add a custom one with an image an move it to the top.
- Add a new social network.
=> traceback
Both issues happen because only icons set as `<i>` elements are taken
into account when modifying a social network (`querySelector('i')`) and
this element may not exist if the icon had another tag (like an image or
a span or even a video (as the media dialog allows to upload them)). As
there is no check ensuring that the element exists before changing the
different social media classes, there is a traceback when the `<i>` is
not found.
For the first issue, it happens because when changing the URL, we first
check if it matches with relevant ones or if an icon matching it exists.
If it is the case, we then update the social media classes to set the
matching icon => it can only work if the icon is a `<i>`.
The second issue happens because when adding a new social network, it
actually copies the style of the first one (unless there are none, a new
one is created in that case). If the first one is an image, it fails
when updating the classes because it is not a `<i>`.
This commit fixes these issues by simply adding checks ensuring the icon
element exists before trying to modify it. It also adds tests, ensuring
these use cases work as expected.
opw-3538230
X-original-commit: 0132fa38baee6501f4257dad718359400f1369ad
Part-of: odoo/odoo#144076
Since commit [1] removed `legacyRejectPromiseHandler()`, trying to edit
a link leading to an HTTP error triggers an "Uncaught Promise" error.
This commit makes sure such links do not cause a traceback: the link
popover is just less detailed (no title, favicon).
[1]: https://github.com/odoo/odoo/commit/fcb16a3b1bd373726ffb54f0fbe41fb6d1784769
task-3584686
closesodoo/odoo#141225
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- In website edit mode, drag and drop an 'Image-Text' snippet onto the
page.
- Click on the button in the second column of the snippet.
- Type "/" in the URL input of the link options in the customize panel.
- Open the 'Page Anchor' selector and select the '#top' anchor.
- Bug: The anchor is not added to the link in the URL input.
The bug was introduced by this commit [1]. Indeed, the events in the
'Start' of LinkTools were no longer attached to the main element but
directly to the event target. This means that in this particular case
where the 'we-button' elements are created after the 'Start', the click
event had no effect because no event was properly attached to it.
This commit also includes test steps to prevent this bug from
reoccurring in the future.
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
task-3580414
closesodoo/odoo#141034
X-original-commit: 72eb761545c51c9dc7c6490c0ce0e38650dfa985
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Steps to reproduce the bug:
- Add a form on the website.
- Add two fields on the form ("A" and "B").
- Change the conditional visibility of "B" and put it to "Visible only
if".
- Change the label of "B" and set it to "A".
- Try to change the dependent field.
-> "A" is still on the list of the eligible dependent fields. It should
not be the case as setting this field as a dependent field would create
a circular dependency.
To solve the problem, the file visibility selector is rerendered after
modifying a field label. Because of the `_findCircular()` check at the
rerendering, the problematic field will not be displayed in the list of
of the eligible dependent fields.
task-3291044
closesodoo/odoo#140928
X-original-commit: 788218dff61e65f2213c31ebc660183ef3e73087
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Steps to reproduce the bug:
- Drop a "Form" snippet on the website.
- Change the "Label" of the first field (and put it to "test" for
example).
- Select the last field and change its visibility so that it depends on
the first field.
- Change the "Label" of the selected field and put it to the same than
the first one ("test").
- Save.
-> Traceback "Maximum call stack exceeded" appears.
At the end of the procedure, the last field visibility depends on itself
and a circular visibility dependency is created. To solve the problem,
this commit checks that the renamed field does not bring a circular
dependency while updating the dependencies. If it is the case, the
problematic dependency is deleted.
To resolve this bug, the `visitedFields` set has been introduced. Its
goal is to register the already visited fields to not enter an infinite
check loop. Let's take an example to illustrate this: Imagine there is a
form of type A->B->C->D. In this form, the field "A" depends on "B" that
depends on "C" that depends on "D". Imagine you rename "D" by "B". You
now have A->B->C->B. The system will check that the renamed field does
not create a circular dependency. To do so, it will apply
`_recursiveFindCircular` with "A" as the `targetFieldEl` and "B" as the
`dependentFieldEl`. Because there is a circular dependency between "C"
and "B", the system would enter in an infinite loop. Note that we do not
notify the system if such indirect circular dependency has been found as
it will be detected as a direct circular dependency while the system
will apply `_recursiveFindCircular` with `C` as the `targetFieldEl`.
task-3291044
X-original-commit: 5f0b62fc30867e03e69a824d5e426bf3f74c8ff5
Part-of: odoo/odoo#140928
Guillaume-gdi