*: test_website, website_blog, website_crm, website_hr_recruitment,
website_mass_mailing, website_sale, website_sale_wishlist,
website_slides
This commit creates a new util which clicks on edit and waits for the
edit mode to be started. This way, we make sure that the edit mode is
enabled before testing the next step of the test. This avoids race
conditions during tests.
This commit replaces all the uses of the old util with the new one, it
also removes the steps that are waiting for the edit mode to start.
Finally, from [this other commit], we can start a tour in edit mode. For
these tests (which have `edition: true`), it is useless to check if the
edit mode has started at the beginning of the test because this check is
already done by default. This commit removes unnecessary / duplicated
steps.
[this other commit]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35#diff-c7720501ec33f5f92c907d8bb41de50edd832a4564317073e801a6915796a6bdR278
task-3203820
closesodoo/odoo#120481
X-original-commit: https://github.com/odoo/odoo/commit/9fd5d25f59578abc9c608578a7d2e2953880b582
Related: odoo/design-themes#656
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Click on "Remove all" to remove all the images of the IG snippet.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).
When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.
When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.
To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.
task-3147271
closesodoo/odoo#116352
X-original-commit: 1c99ab2bc04f65999098f70d062d24ed1ac4a9c3
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
Since [this commit], when dropping several "table of content" blocks on
the same page, it was impossible to save. This commit solves this
problem.
Steps to reproduce the resolved bug:
- In edit mode, drop two TOC blocks
- Click on Save
=> the UI is blocked
[this commit]: https://github.com/odoo/odoo/commit/06b03ba5ef8375b1236f6ecb52ac468124e910ba
Related to opw-3047375
Related to opw-3035502
task-2948895
X-original-commit: a6de596017cdbd0da10b4050da132d46dc82a491
Part-of: odoo/odoo#107732
Since the bootstrap 5 merge at [1], when you click on an image in the
Image Wall block, the modal no longer opens. This commit restores that
and adds a test to make sure this problem does not happen again.
Steps to reproduce:
- Drop the "Image wall" block in a page
- Save
- Click on an image
-> The modal does not open
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-2937538
closesodoo/odoo#97053
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the tours default_shape_gets_palette_colors and
edit_link_popover were not using the tour utils function
registerEditionTour, that starts a tour on the iframe, in edit mode,
with a timeout on the first step.
Because this timeout was not there, loading the iframe and the snippets
menu could take longer than the default timeout and the test would fail
inconsistently.
task-2687506
closesodoo/odoo#96164
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website, website_blog, website_crm, website_event, website_forum,
website_hr_recruitment, website_mass_mailing, website_sale,
website_sale_loyalty, website_slides
This commit adds the current website displayed view xmlid outside of the
iframe, on its container, so that the tours registered with
registerThemeHomepageTour can continue to prepend their triggers with
the view xml id.
Introduce registerEditionTour: this function will allow tour maker to
more easily register a tour that needs to start in the iframe's backend
and go in edit mode.
See merge commit for more information.
task-2687506
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
Before this commit, a traceback occured when trying to remove a popup
snippet, only if content inside was clicked on before (base case but
that last part was not covered by our main test which drags and drops +
removes all snippets).
The problem is complex and annoying to solve in stable. The cause is the
combination of [1] and [2]. Indeed, with [2] we solved the snippet
activation flow to ensure the onFocus and onBlur methods are called when
needed... but that new correct implementation relies on the fact that
the number of snippet editor instances does not change for the whole
async operation of activating a snippet. That should naturally be the
case but is not because of [1]: when we remove a snippet we first
trigger a snippet activation then destroy the snippet (and its editor
instance)... but the snippet activation is not awaited at the moment.
Thus making the snippet editor instance be destroyed *during* the
snippet activation flow. Of course a better solution than this commit
must be found but this fixes the traceback with a very minimal change
for the 15.0 stable version while waiting for that miraculous solution.
[1]: https://github.com/odoo/odoo/commit/ae219ec06baf0280c76ae09b1453cc1481eece30
[2]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e
task-2735663
closesodoo/odoo#83378
X-original-commit: da7c1b5757a7780897c5736ddecc014a7fb50bdb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit introduces a new social_media snippet that allows social
networks to be displayed. This snippet shares the same options as the
share snippet, but also provides a list to edit the URLs of the social
networks in the company data (social_facebook, ...). This list also
allows to manage links to custom social networks (which are not stored
in the DB).
Headers and footers now use this new social_media snippet instead of the
share snippet and in the settings, the urls to the DB social networks
are editable/visible only in developer mode.
task-2687447
closesodoo/odoo#80217
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Guillaume (gdi) <gdi@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
A mega-tour was introduced with [1] to test every single snippet.
This tour, despite being very useful as it tests the core behavior of the
website builder, is creating a lot of race conditions.
This commit won't fix anything but will actually reduce the tour length,
hopefully also reducing the amount of race condition while those are fixed.
Indeed, some snippets were tested multiple times, as a snippet might include
another snippet in its DOM, the xpath query would return multiple times the
same snippet.
Duplicates: s_card (5), s_banner (2), s_donation_button (2),
s_dynamic_snippet_products (2), s_newsletter_subscribe_form (3),
s_searchbar_input (2), s_text_block (3), s_hr (2).
[1]: https://github.com/odoo/odoo/commit/460d5ecb926c13a79ba363f8f86442433d91bf6f
task-2726529
X-original-commit: 6f6ace0f0b09f6ad8b497f89e331e43a18e00471
Part-of: odoo/odoo#82214
Purpose
=======
The fields are not used, don't work correctly and there is a specific
report to generate the product prices according to the pricelist and
the ordered quantities
The countdown snippet has an end action that can be configured to show a
message when the countdown reaches zero. A button in the editor toggles
a preview of this message. However, a bug currently makes the preview
disappear whenever the snippet's widget is restarted... which occurs by
simply hovering some other options.
To solve the problem, the preview visibility is now controlled by a
separate css class s_countdown_enable_preview overriding d-none. This
way, the preview visibility no longer interacts with the widget's logic
and is no longer affected by the widget restarting.
task-2638366
X-original-commit: c37354d457f5b868673b4f974e401f4c635062d2
Part-of: odoo/odoo#81557
Co-authored-by: qsm-odoo <qsm@odoo.com>
`s_map` snippet is calling maps.google.com which might be the reason this tour
experience some race condition when trying to drag and drop the
`s_newsletter_subscribe_form` (which happen after the `s_map` snippet was
dropped).
When the race condition happen, we can see on the screenshot that the snippet
was drag & dropped into the footer instead of the `s_text_image` inside the
`#wrap` as it should be (see comment on first step of the test).
The reason the snippet is not dropped where it should be is because the `s_map`
was not removed as it should have been (seeing the screenshot), so the page was
scrolled and the footer became the first available and visible `o_editable`.
The `s_map` snippet is probably still in the DOM (despite a step is in charge
of removing it) because it is recreated after the google maps server reply,
which sometimes is probably taking an unexpected long time.
Anyway, external services should never be called during tests, removing the
snippet from the tour is an "easy" first step to try to fix the race
condition.
closesodoo/odoo#79120
X-original-commit: 37c9ae2c3b228e5abbe5bdb84df2c381d9f2fcb3
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
It creates race condition, as it contact external ressource, in this case
facebook.com.
Tests should never call external services anyway, it always lead to race
condition.
closesodoo/odoo#74704
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Image gallery snippet when dropped is throwing a traceback.
This lead to the editor not usable anymore, as any JS error will prevent any
further action (no JS will work anymore).
This introduce a test that will drag and drop every snippet in a page and click
on it to load its settings in the right panel.
Note that it will remove the snippet before drag & dropping the next one, as
having too many snippet will impact the perf, even killing the browser entirely
if there is a lot.
task-2604383
closesodoo/odoo#74135
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Previously, when toggling on background shapes, they always had the
default colours. In [1] we made it so that when you toggle on a shape on
a section, it would automatically reuse the colors of the surrounding
shapes if any.
Unfortunately, when the "implicit" colors were also the default colors,
they were still marked on the shape, and it got an explicit background
image that would no longer react to changes in the palette.
This was caused by the fact that the call to _getDefaultColors returns
an empty object when the section doesn't already have a shape-container,
this was not a problem before since we were not passing in any colors
when creating the initial shape previously, the the aforementioned
change made it so that we did.
This commit fixes the issue by creating the shape-container before
calling the method that will set the colors on the shape, this way
getDefaultColors works as expected, and the colors are not marked on the
section when they are the default ones, restoring the ability of the
shape colors to adapt to the palette
[1]: https://github.com/odoo/odoo/commit/875aca63f7dab287c61485ebe999b3b8dd89d91c
task-2500607
closesodoo/odoo#70054
X-original-commit: 63acc2b0d1957dedd40af2033722f9ea4ef2e597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Tom De Caluwé <tdc@odoo.com>
Previously, when removing all the content of a snippet, that snippet
would get automatically deleted. This was not the case for parallax
snippets because we previously intended the user to drop the parallax
snippet, empty it, and drop other content inside of it.
Recently, we added the parallax option on all snippets, rendering the
previous workflow obsolete. There is now no longer any reason to keep
empty parallax snippets. This commit fixes that.
task-2446008
closesodoo/odoo#65551
X-original-commit: 61f410b57f1c28bd6464b86d1582c22b7fd846d5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Guillaume (gdi)