Prior to this commit, the language of the snippet menu would be the same
as the snippet content. This would cause issues if the user's language
was not the same as the website they were editing.
This commit fixes that by displaying the snippet menu in the user's
selected language but getting snippet content in the website's language.
This commit also fixes SEO data not being saved according to the
website's displayed language. Prior, it was saved according to the
user's current display language.
This commit also introduces a test for a fix made at [1] that
targets a previous version of odoo.
[1]: https://github.com/odoo/odoo/commit/db5d1eae2086ff338d8211af70c2f88240393c36
task-2687506
closesodoo/odoo#102799
X-original-commit: 55a978aa86967581956f855a1c5db33b7425bd15
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] keeps the snippet cache alive through different
instance of the website snippet menu.
This allows for the user to switch pages, even apps, while
keeping the snippets in cache, decreasing the startup time of the
snippet menu.
However, the cache is not invalidated when switching website or
installing a new theme.
This commit adds a `invalidateSnippetCache` property to the
websiteService. If this property is set to `true`, the cache will be
invalidated next time the menus loads its snippet.
This property is currently set to `true` when changing website and
switching theme.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-2687506
X-original-commit: bb503962a36f3798c50049f2844e7b288b632955
Part-of: odoo/odoo#102799
While working in the current state of the website configuration, the
overlay computation was not working anymore in case the scrollbar is
moved out of the wrapwrap. Indeed, in that case, the position was wrong
by the amount of the page scrolling.
While we could include that scrolling value in the equation, this commit
chooses to restore the way it worked before the "website-in-backend"
merge at [1]: making the overlay be naturally positioned according to
the page scrolling wherever the scrollbar is. To do that, the overlay
had to be moved inside the content (the website iframe) which has the
disadvantage of risking the overlay design being broken by a theme. This
solution was chosen as it simplifies the code, and potentially allows
for performance improvements in the future: not forcing a position
recompute after each scroll (the animation should already be smoother /
more performant this way). This will actually be needed for another fix
/ improvement: the background image overlay has to be in the iframe too.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#102785
X-original-commit: 872bb20b3ac08cf82613e15e6634a2e7593ccf7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The tour contains this part:
1. Change the font-size
2. Click on save
3. Check that edit mode was left
4. Check the font-size is ok
The problem is that step 1 induces a series of RPC and processing
(rebuilding assets, reloading them in the client, etc) but those are
not awaited before going into step 2 which also induces a RPC (the save)
which is only done once the other RPC are finished.
While we will try to optimize the duration of those RPC in the future.
Meanwhile we could simply increase to the timeout of step 3 but it seems
better to change the tour to divide the multiple things to await:
1. Change the font-size
2. Check the font-size is ok
3. Click on save
4. Check that edit mode was left
5. Check the font-size is still ok
runbot-4706
closesodoo/odoo#102609
X-original-commit: c2bc6c2f8446e98c8a4089daf048e67457be277f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since [1], as part of the new translation system made with [2], saving
multiple elements in a website page was only saving the first one. E.g.
- Enter edit mode of your homepage
- Add something in the main area of the page
- Add something in the footer
- Save
=> Only the main area is saved, not the footer.
This was actually the same in translate mode... only translation of the
first edited area could be saved.
At least, with the bug fixed version of [1] comes the small advantage
of not saving multiple times the same field (except for view parts).
E.g.: an event's dates are displayed multiple times in different formats
-> in 15.0, 3 RPC were made by date changed, now only one is made.
[1]: https://github.com/odoo/odoo/commit/1b473cf0db4d85c2b523ac87fbab533bce5f3e21
[2]: https://github.com/odoo/odoo/commit/4e82c45abdb0b420edead2bd1d0ba9ff4bb4a224closesodoo/odoo#100762
X-original-commit: c834d151afed0ca633ffb6bcba2f45b544689e74
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: test_website, website_blog, website_crm, website_event,
website_forum, website_hr_recruitment, website_mass_mailing,
website_sale, website_sale_wishlist, website_slides
- Make sure that all website tours reaching the website preview before
their first step use the related website util to register their tour.
- Rename the website util to register a tour starting on the website
preview from `registerEditionTour` to `registerWebsitePreviewTour`.
Having a method using "Edition" in its name and having a boolean
parameter named `edition` was a bit... strange.
- For both non edit mode and edit mode as a first step, ensure the util
sets a high timeout for the first step. Indeed loading both the
backend and the frontend (in the iframe) and potentially starting the
edit mode can take a long time in automatic tests. We'll try and
decrease the need for this high timeout of course.
- Review the implementation of those utils to be more consistent and
also fix one or two mistakes in them.
closesodoo/odoo#100024
Related: odoo/design-themes#588
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_event, website_links
This commit fixes the navbar on the enterprise mobile mode. With the
enterprise modules, in mobile mode, the navbar menus are removed and
displayed in an an additional systray item, the BurgerMenu.
This behavior was not adapted to the website systray and contextual
custom menus, introduced in [1].
For the website systray, some elements are hidden in mobile:
- the "edit" and "translate" buttons,
- the mobile preview,
- the "+ new" new content button,
The logic for displaying the contextual custom menus is moved from the
navbar patch to a service, so that we can define a patch for the
BurgerMenu that uses that logic and has the same behavior as the
navbar.
For now, the "Menu Editor" and the "HTML/CSS Editor" menus are hidden in
mobile.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#99605
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit will adapt ThemePreview views to OWL.
Those views use custom components to achieve the desired layout and
functionality.
Part-of: odoo/odoo#99150
Co-authored-by: Younn Olivier <yol@odoo.com>
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
It was decided with [1] to keep the text selection, if there was one,
when changing a snippet's option.
It was not working for the layout_column option:
- Drop a text snippet,
- Click on the first paragraph (the text is selected),
- Change the number of columns,
=> The text selection is lost.
To add some columns on snippets like the s_text_block which has no rows
and columns, the layout_column option will first wrap its content into a
set of row and column, which will remove the selection.
To fix that, the selection is restored after wrapping the snippet's
content.
The same thing is done when removing all columns from a snippet (and
unwrapping its content).
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[1]: https://github.com/odoo/odoo/commit/e8112e2865ca449c4df9cd6147e9e24c4c6dcd41
task-2687506
Part-of: odoo/odoo#98352
Since [1] the link tools got created when the destroyed sub-elements of
the link were clicked on. This causes a problem when the element is a
media because upon destroy the tools reset the link to an incorrect
state.
After this commit the link tools is not touched anymore if the element
that was clicked on is a media.
Also, it reflects the changes done in the popup into the media link
options, and the ones done in the option into the popup.
Steps to reproduce:
- Add an image-text snippet in the page
- Click on the image
- Set up a link
- DO NOT click on the image again
- Click on the left of the image (to click on the snippet itself)
- Click on the image again
=> The image was removed instead and a text link remained
[1]: https://github.com/odoo/odoo/commit/d69d26a2dd8830aca8c5922d3548e5ff59c688fc
task-2765857
X-original-commit: 11ee7d5520c3a14a381b3f5b973114670f1e2edb
Part-of: odoo/odoo#98845
Before this commit, after:
- Drop a popup,
- Click on the undo button,
=> The invisible elements panel was still displayed, with the popup
entry.
To fix that, the panel visibility is updated on the
'historyUndo'/'historyRedo' events alongside refreshing the snippets
editors.
task-2687506
closesodoo/odoo#98807
X-original-commit: 76704f47db46ac7e71a894f620d8061a3eb594a7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website_sale
That tour keeps failing. A fix attempt was made with [1] but wasn't
enough.
The tour was actually useless as since [2] google analytics dashboard
was not part of the website dashboard anymore (due to google not
allowing GA4 dashboard to be embed).
The tour, which was initially made to ensure that google analytics was
correctly shown even if not yet connected to was then not useful
anymore.
The opportunity is also taken to rename the misleading ID of related
records still mentioning Google.
[1]: https://github.com/odoo/odoo/commit/1a191357e3ac0c4542b2fc7c3a2aee18dc54699d
[2]: https://github.com/odoo/odoo/commit/985e49bdb5e22fa197ba267aa41d7a8ba7e50550
runbot-4498
runbot-4499
runbot-4466
closesodoo/odoo#98090
Related: odoo/upgrade#3774
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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>
Commit [1] changed the way styles are handled. Now that the edition of
website is done in an iframe, the styles are computed inside the iframe
instead of the top window / global document element.
But for computing the gray colors, a base style defined
by `web_editor/color_palette.scss` is needed. This style is not part of
the frontend assets, so using the iframe to fetch it creates bogus gray,
which results in the feature not working.
Steps to reproduce:
- Go on the website editor
- Select the THEME tab
- At the bottom expand the gray color picker
- Use the settings
- The preview is not updated while sliding.
- The colors are not updated in the page.
This commit fixes the bug by fetching the base style from the top
window (where backend assets are present).
[1]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
task-2687506
Part-of: odoo/odoo#94564
Commit [1] moved the website builder in the backend and in doing so
transferred event handling to the wysiwyg_adapter from the edit button
widget. Unfortunately, during that process, handling of event for
cloned snippets was forgotten.
This commit restores that and adds a test.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#94564
The tour .test_03_backend_dashboard was failing inconsistently with a
"failed to fetch" error (which happens when fetching the frontend
assets, from the iframe).
The test is adapted to start directly in the backend, which seems to
prevent that error from happening.
It is also adapted to [1] which was merged during the investigation of
that error.
[1]: https://github.com/odoo/odoo/commit/985e49bdb5e22fa197ba267aa41d7a8ba7e50550
runbot-4418
runbot-4003
Part-of: odoo/odoo#95890
The redirect field in website does not work properly in the new views.
With this commit, we just reimplement it to make it work with the new
code.
closesodoo/odoo#96865
Related: odoo/enterprise#30178
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, clicking on the "anchor" icon from a snippet editor
would copy the client action's url (introduced in [1]).
This commit changes the snippet's path computation to use the target's
ownerDocument location instead of the global one.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#96401
Before this commit, the Page Layout > Background option's widget of the
Theme section of the SnippetsMenu was not updated correctly after using
the option.
The #wrapwrap was queried in the global document when it should be
queried in the target's ownerDocument.
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#96401
Before [1] was merged, for this flow:
- Drop a snippet in the page
- Click on some paragraph
- Click on a snippet option's widget
=> The text selection was lost on Chrome, but kept on Firefox.
With [1] instantiating the SnippetsMenu on a different document than the
snippets one, it was possible to keep the text selection (the snippets
document selection) when clicking on the snippets options (on the global
document).
Some code was added to preserve the Chrome behaviour and lose the text
selection. This code is reverted to keep the Firefox behaviour.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#96401
This commit gets rid of the iframefallback in test mode. It is not
helpful there and slows down the tests as it involves some HTTP
requests.
Its purpose is only for the end users to have a smoother UX during page
transition. It is irrelevant in tests. Note that it means the tests
wouldn't break if that iframe fallback was to be breaking something in
real use cases.
task-2687506
closesodoo/odoo#96229
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] the back button did not navigate within the steps of the
website configurator anymore.
After this commit the window location change that happens within the
browser is copied back into the state - thus causing a redraw of the
correct configurator step.
Steps to reproduce:
- Create a new website
- Go to second step
- Press browser's Back button
=> Did not navigate to previous configurator step.
[1]: https://github.com/odoo/odoo/commit/56cc3dfab156f21c7ef97b3c407f1480b094fe93
task-2789075
closesodoo/odoo#96766
X-original-commit: d32f8a9d64f0487e1e61ec7cee7cffde21b8ddb2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since this commit [1], when you select the Header position option and
set it to "Over The Content", the change is not saved if you did not
edit something else in the page too.
Indeed, now that the "save" works correctly (and that it no longer saves
the page every time). It does not detect the change made by this option
which is to add a class on the '#wrapwrap' element. (The editor looks
for changes inside the wrapwrap but not on it).
This commit checks if any page option is dirty on save on top of
checking if the content of the page has been modified.
Additionally, this commit fixes a bug that would occur on Firefox based
browsers where the hidden input used to display the status of these
options would be auto-completed by the browser in some conditions.
(https://bugzilla.mozilla.org/show_bug.cgi?id=520561).
This could result in an incorrect state being displayed.
To reproduce:
- Change the option, click on cancel, start the editor
- the incorrect state is displayed
A test is also added by this commit to verify that all the page options
works correctly.
[1]: https://github.com/odoo/odoo/commit/bab673488e185ddd7792aedecc3870663290fed3
task-2871426
X-original-commit: ea7a69b344d970cc2b31555f4cd8fd7c5e2fc6d2
Part-of: odoo/odoo#94949
==== Short version ====
Google is deprecating Universal Analytics in July 2023 and Google
Sign-In in March 2023. Google Analytics Embed API is based on Sign-In,
meaning it won't work anymore. It actually already doesn't work anymore
for accounts created somewhere after mid-2020 apparently.
There is no plan for now for Google to allow Analytics 4 dashboard to be
embed in external website.
We therefore can't do anything to keep the Google Analytics dashboard in
Odoo.
In previous stable version, it was kept but is displaying a warning
about it (as until mid 2023 old accounts can still embed it).
All this is about the embed dashboard, not the tracking in itself for
which Odoo is already adapted in Odoo 15.0 for Analytics 4.
==== Detailed version (following short version, read it first) ====
- Universal Analytics EOL July 2023, see [1].
- It will be replaced by Analytics 4 for which Odoo is already ready and
actually using it since version 15.0 with [2].
- Google Sign-In EOL March 2023, see [3]. Analytics Embed API was based
on it, it won't work anymore.
- There is no plan (for now) for Google to allow Analytics 4 to be able
to be embed in external websites. They seem to just have dropped the
"feature".
This was confirmed by Google here [4] and indirectly here [5] in the
DOC:
`Note: This API does not support Google Analytics 4 (GA4) properties`
- While the EOL is planed for 2023, the dashboard integration is already
not working anymore for new accounts.
- Old projects/keys/accounts can still embed their analytics dashboard.
The threshold seems to be somewhere mid-2020, according to [6].
It seems to be accurate as my own key from 2018 still works, while my
keys from 2021 do not.
==== Fix ====
- In stable, warn user about it in their Odoo Analytics dashboard (this
PR) and also add a warning about that on the doc.
- In master, simply drop the whole google analytics dashboard
integration and remove the doc about it, see [7].
==== Useful links ====
[1]: https://support.google.com/analytics/answer/11583528?hl=en
[2]: https://github.com/odoo/odoo/commit/78bc86cbeccfc5df16218aee2b0d7c501e5c05b5
[3]: https://developers.googleblog.com/2022/03/gis-jsweb-authz-migration.html
[4]: https://issuetracker.google.com/issues/233738709?pli=1
[5]: https://developers.google.com/analytics/devguides/reporting/embed/v1
[6]: https://support.google.com/analytics/answer/11583832
[7]: https://www.odoo.com/documentation/15.0/applications/websites/website/optimize/google_analytics_dashboard.html
Finally, note that it means that from July 2023 to Octobre 2023, while
Odoo 14.0 is still supported, Google Analytics won't work anymore in
that version as it will still be designed for Universal Analytics and
not Analytics 4.
opw-2710910
opw-2855405
opw-2881515
opw-2892370
task-2790245
task-2820890
closesodoo/odoo#96280
X-original-commit: d065595f77790fb5ab9480f6de5b88549352324b
Related: odoo/enterprise#29666
Related: odoo/upgrade#3698
Related: odoo/documentation#2499
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@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>
This commit aims at making the website dialog as well as the edit_menus
tour more stable.
Commit [1] introduced a new dialog API for website.
The component WebsiteDialog handles click asynchronously.
Prior to this commit, the tour could sometimes detect and click on modal
triggers before the actions that the previous trigger was triggering
could complete. This could lead to a modal closing too early either
because a click would done on the wrong modal or the input was completed
before the validation method was called (since the click handlers are
asynchronous).
Here are a few examples of possible failure in the tour :
- The tour clicks on "Add Menu Item", which should open a new modal
- The tour then clicks on OK to make sure the modal does not close.
- The click on OK is done before the New Menu Item modal is open and
therefore is triggered on the previous modal
- The modal is closed too early
- The tour clicks on OK while the URL field is empty
- Before the validation method is processed the tour inserts a value in
the input field.
- The validation method doesn't block the OK method which results in the
dialog being closed
- The tour expects the dialog to be open and crashes
- The tour clicks on OK while the URL field is empty
- Before the validation method is processed the tour inserts a value in
the input field
- The tour clicks on OK again
- 2 entries are created instead of one.
The last one doesn't crash the tour but is still incorrect.
This commit disables the buttons when they're clicked for the first time
until the handler is processed.
This commit also make the triggers in the tour more specific so that the
tour always clicks on the right modals.
[1]: https://github.com/odoo/odoo/commit/28a78fb4e4e4465aa99fb94f7cac3a21b2188502
runbot-4122
closesodoo/odoo#95839
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since frontend to backend commit [1], links having `enable_editor=1` to
enable edit mode were not working anymore in certain cases.
Case 1 [OK]*:
From frontend, click on `enable_editor=1` link without `/@/` in it.
Case 2 [OK]:
From frontend, click on `enable_editor=1` link with `/@/` in it.
Case 3 [KO]*:
From backend, click on `enable_editor=1` link without `/@/` in it.
Case 4 [KO]:
From backend, click on `enable_editor=1` link with `/@/` in it.
This commit fixes case 4 and adds a test for all cases, while leaving
case 3 commented as it will be fixed later with a larger fix related to
URL change listener.
* Note that we will probably change the behavior for case 1 and 3: if
the version with /@/ + enable_editor=1 enters edit mode properly in
both frontend and backend contexts (case 2 and 4), it's probably not
worth having code to support case 1 and 3.
The issue for case 4 was that it was trying to load the whole Odoo app
inside of website preview iframe instead of making the parent window
load that URL.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#96054
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website_modules
This commit restores the display of the website loader (the "Building
your website" GIF) during the installation of a module from the new
content modal, or after completing the configurator flow.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
Before this commit, switching languages from the language dropdown while
in edit/translate mode was broken.
Now, the click event on this dropdown is listened alongside links with
external redirection from the WebsitePreview client action, so that the
client action leaves the edit mode while frontend is redirected to the
right language.
For that, a new leaveEditMode method is added to the website service,
which removes the edition classes and unmounts the Editor component.
This will further be reviewed in future commits.
Also, adding a new language from the language switcher dropdown directly
opens the wizard in a dialog on top of the WebsitePreview client action.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
Issue introduced by commit b0a2a41
The template's "flags" value was not in the t-nocache values to use when
rendering languages.
X-original-commit: 7827d2dbc1fbef3cc0dc898baa0af30ed1f23fca
Part-of: odoo/odoo#95222
Introduced with [1] the goal of this tour was to check some lazy loading
stuff regarding the edit mode.
It was then "wrongly" adapted with [2] where the tour actually still
started in the frontend and then clicked on a the new UI button (top
left floating icon of the frontend > backend task) to indirectly enter
edit mode.
While it was working, that's not what the test was aiming to test. The
test should remain as it was, testing the edit mode. While the edit btn
is now in the backend and not the frontend, the tour should just start
there.
Note that this commit is required as the behavior the tour was now
relying on is removed by the previous commit: the Edit button is not
entering edit mode anymore.
Instead of adding a new step to click on the Edit btn, let's just start
the tour as before on the step where you can click on Edit.
It will make the test less dependent of other behavior. This is
especially true since that frontend "Edit" button will most likely
change again or be removed (and introduced back?). We don't want the
tour to rely on this.
If those new UI button need to be tested, it should be in another test.
[1]: https://github.com/odoo/odoo/commit/6f4c60fe1bb6e460ec6da00c59a9825271893729
[2]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35closesodoo/odoo#95002
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes an inconsistent behaviour in tours using the website's
"Edit Menu" dialogs.
When adding a mega menu, two dialogs are displayed:
- The main "Edit Menu" dialog, from which you can open
- The "Menu" dialog with the mega menu label input
When these two dialogs were opened, and closed successively (click on
"Ok" to confirm the menu label, then click on "Save" to save the new
website menu), the tour was sometimes triggering the primary button of
the wrong dialog.
Two issues were leading to this inconsistent behaviour:
1/ Sometimes, the tour would click twice on the same primary button,
and would not wait for the current dialog to close.
To prevent that, extra_triggers are added to the steps to check that the
first click was correctly taken into account (and so, that the upper
dialog, that was the active dialog, was closed).
2/ Other times, the tour would click on the wrong dialog primary button
(it would click on the inactive dialog's button that would save the menu
without validating the label first).
This was coming from the web_tour.TourManager inaccurate
$modal_displayed property, which was defined and used in two different
javascript threads of execution. It could reference modals that were
not the actual modals from the DOM, when used in _check_for_tooltip.
To prevent that, that property is set inside the method it is used in.
It could be defined as a const and not a property, but this way the
commit history is left untouched.
runbot-4000
runbot-4001
runbot-4004
runbot-4005
closesodoo/odoo#94924
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] moved the edition of the website in the backend and
introduced an iframe as the editable. In doing so, some tour
actions became unstable.
The issue is that previously, when an action reloaded the page, the tour
service would reload as well. This is no longer the case and the tour
service stays active when the page is reloaded (e.g. when saving a
page). This can lead to a tour clicking on an item before it is ready to
be clicked.
Specifically in this case, the tour saved and clicked on edit as the
next step.
Clicking on edit before the page is properly reloaded leads to the click
being ignored.
This commit uses the util function `clickOnSave` which ensures we're out
of edit mode and the page is reloaded before doing anything else.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
runbot-4074
closesodoo/odoo#94932
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The drag and drop mega test is quite simple: the python gets the list of
all the snippets (by rendering a view + etree), then it just starts a JS
tour by passing all those snippets in the tour URL.
From there, the JS tour is in charged of building its own steps based on
the list of snippets it received from the python.
The MOST important part is to be 100% sure that the built steps are as
expected: ~5 steps / snippets: ~220 steps with website only and ~280
steps with all modules.
If we don't have that check, the tour could suddenly not test anything
because the step list would be empty, but the test wouldn't fail.
Thus, we don't want to programmatically try to compute that step amount
but want it to remain an hardcoded number, which is lowered in this
commit as if we have 220 (it could be 200, 150..) steps, it means that
the steps were built as expected.
Note that since the test is run on post_install, 280 was fine since all
modules were installed.
But the nightly build is also testing this test with only the website
module, ultimately failing.
Note that this check was actually not working at all since [1] as there
was a typo on `length`.
[1]: https://github.com/odoo/odoo/commit/61b19dafd1fb79120f701b94038bbe859aa2e271closesodoo/odoo#94614
X-original-commit: 23c6b49ba43e6146143bf83bdfd7ce93934961ea
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
By starting the get_switchable_related_views request when the
WysiwygAdapter is started, and awaiting it only when we need to know,
we can improve the initial loading time of the editor.
See merge commit for more information.
task-2687506
When clicking on save while having a popup open, in some conditions,
a traceback can appear due to a race condtion.
This is caused by an event listener which updates the visibility status
of said popup in the editor panel. When saving the popup is closed,
and the cleanForSave starts, but while the popup is closing an event
is triggered which recreates editors (_onSnippetOptionVisibilityUpdate).
This commit aims at mitigating the appearance of this race condition
by listening to the .hide event instead of the .hidden, which means
the event is fired right away instead of 400ms later.
See merge commit for more information.
task-2687506
This commit mocks the website service for all the QUnit tests.
As the website module now defines a patch on the WebClient and NavBar
components, adding the website service, this service needs to be mocked
for all the tests. This is done by patching the QUnit.testStart hook.
Also, after the addition of the new media dialog, this component is
mocked at the field html unit test.
See merge commit for more information.
task-2687506
*: 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>
The test was introduced in [1] with a typo on the first step (which is
only there to ensure the test does contain steps).
Note: with the 15.1 forward-port, the "number of steps" check had to be
adapted because snippets were removed at [2]. This reveals however two
issues:
- Snippets which use the generic "Dynamic Snippet" as base are not
tested by the test.
- [2] removed the s_speaker_bio snippet by mistake
Both those problems will be fixed in other PR alongside improving the
way the "number of steps" check works.
[1]: https://github.com/odoo/odoo/commit/460d5ecb926c13a79ba363f8f86442433d91bf6f
[2]: https://github.com/odoo/odoo/commit/b5c87d86cad1aa2b44f805da0b2d6635aeb85b96closesodoo/odoo#94359
X-original-commit: 8e6a6ab532637ef9ef8d87ca4062e26b2852825a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website, test_website
Since [1], a race condition seems to have become more dominant. It is
actually due to a tour not properly awaiting the editor to be loaded
before using it.
This commit fixes all occurrences of such 'trigger' selectors, even in
tours were it could actually be not a problem. That will prevent devs to
copy paste the problematic trigger.
[1]: https://github.com/odoo/odoo/commit/57793ff912ac5aab8f3d3e014992965d06290bf0closesodoo/odoo#94000
X-original-commit: 38f3a94263b9cf48e9f5a8de553b8602310bcddd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Somehow the already translated term `Save` in french was translated
again from `Sauvegarder` to `Sauver`.
We already faced that issue when forward porting the tour as that
translation was not the same between versions, see [1].
The tour should be adapted to create a new fake language and some
translations for it (the ones being checked in the tour) to make it more
robust and not impacted by the real translation from transifex.
It would also makes the test faster as it wouldn't have to load a real
language which has a lot of translations.
As this is blocking and preventing any r+ in saas-15.3 a day before the
saas-15.4 freeze/release, this quick fix is introduced in the meantime.
[1]: https://github.com/odoo/odoo/pull/84528#issuecomment-1041323974closesodoo/odoo#92938
X-original-commit: 594ac2c9651f27cc1623fcd5b916cb191241651b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Arthur Detroux (ard)