For performance reasons, when fuzzy search was introduces it was
decided to limit the number of records used for finding fuzzy terms to
1000. Because of this, when a database contains more than 1000
products matching words that start with the same letter, further
products are not examined. This can lead to searches not finding an
existing exact match.
This commit introduces a fallback mechanism so that, if we are in a
situation where the maximum number of examined records was fetched, we
also explicitly check for a possible exact match across all records.
Steps to reproduce:
- Do not install the pg_trgm extension.
- Have more than 1000 products containing searchable words (name,
description...) starting with the same letter.
- Add one more such product (so that it is not in the 1000 first ones).
- Search for that last product by correctly typing the word.
=> Exact match was not returned.
task-2870947
closesodoo/odoo#97657
X-original-commit: 6d24ea28b236155d542e3d2be3da379b9f4e9ce6
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, it was possible to make the JS crash due to maximum
call stack reached due to some recursion between 2 field visibility.
It was then preventing the page to even be accessed as it is the 000.js
(public file) which is failing.
The only way to fix that is then to go through the backend.
Step to reproduce:
- Enter edit mode and drag & drop a form snippet on the page
- Select a field, let's call it field_a
- Set its visibility option in the right panel to "Visible only if" and
select another field as value, let's call it field_b
- Now select field_b and do the same operation and set field_a as value
- Save
After save, the 000.js file will be executed and the traceback will
occur, preventing the page to work at all.
Note that the illustrated example is about direct and obvious circular
dependency, but it could also be about indirect circular dependency like
field_a depends of field_b, field_b depends of field_c and field_c
depends of field_a.
opw-2889860
closesodoo/odoo#97652
X-original-commit: 90ecfab61f0c71850c1f3bc3ab2644883d18f9a5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This introduces a new API for the Powerbox, which allows to order its
commands and categories. The order is based on the priority assigned to
the category or command. If two items have the same priority, they are
ordered alphabetically.
To order categories, pass said categories in the Powerbox's params, each
with its own priority. If a command declares itself as part of a
category that was not itself declared, said category will be added
automatically, with the lowest priority.
task-2901697
Part-of: odoo/odoo#96287
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 editor shortcuts would not work.
Example: "alt+1", or "alt+2" switch tab of the editor.
This commit registers the editor as the active element, so that keyboard
shortcuts registered on that element are given priority at the hotkey
service level. The "escape" shortcut to go fullscreen is adapted with
the global option to be independent from the active element.
This commit also adds the "alt+p" keyboard shortcut on the publish
systray item.
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#96401
Before this commit, the website context was configured with the params
of the client action, at all times. This was leading to weird
behaviours:
- Go to the website client action
- Install the "Blogs" module from the new content systray item
- Navigate on a blog post from the client action
- Click on the "Settings" systray item (last one from the right)
- Click on the "Website Preview" breadcrumb item
=> The "New Content" modal is displayed, again, when it should not.
Another flow, on enterprise:
- Start the client action with /@/?enable_editor=1
- Click on the top left icon to go back to the home screen
- Click on the top left icon to go back to the website
=> The editor is launched when it should not.
To prevent that, the action jsId key is registered at the website
service level. If the action is restored, the jsId will be the same, and
the params used to configure the context will be ignored.
Related to 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>
Prior to this commit, if an user chose to fetch 16 elements, the snippet
would bug out and display 16 elements per row.
Steps to reproduce:
- Install website_sale
- Drop a product snippet
- Select 16 fetched elements
- Layout is broken
Some legacy code introduced in [1] could result in an infinite loading
animation locking the editor out. This commit removes the code as a
fix made at [2] makes it unneeded.
Steps to reproduce:
- Install website_sale
- Enable debug mode
- Drop a "Dynamic Snippet Carousel"
- Click on the Dynamic Snippet for edit
- Sometimes the editor hangs and the page needs to be refreshed
[1]: https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5
[2]: https://github.com/odoo/odoo/commit/ac8d83cc124a6175a263e11795fda35eebe69324
Related to task-2677203
closesodoo/odoo#97502
X-original-commit: 5ef31db8599d5dbe7ed07c88ac1c703bd7287345
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit when the header scroll effect was happening, the
related DOM updates were recorded in the editor's history.
This commit deactivates the history during the updates of the header.
Steps to reproduce:
- Drop a "Text" block in the page.
- Drop 4 "Banner" blocks below the "Text" block to make the page
scrollable.
- Save.
- Edit page.
- DO NOT SCROLL until the last step.
- Select the Text block.
- Delete the Text block.
- Click undo => Text block reappears as expected.
- Click redo => Text block disappears as expected.
- Click undo.
- Scroll down until header vanishes and reappears.
=> Redo step is lost, undo tries to undo the header animation.
task-2930568
closesodoo/odoo#97488
X-original-commit: c710f73f84ce798b8363b7f8904f96b9eacd56dc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Just a nice to have. It will prevent those errors to be replicated when
copy pasted and will help reading the files in the IDE.
closesodoo/odoo#97282
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
As a stable fix, to not touch XML templates and break existing
translations, the ⌙ character was automatically replaced by └ which
makes more sense for the usecase and should work properly in all
browsers. The ⌙ character is actually rendered mirrored on Windows 11
Chrome (and others) as the font used for those unicode characters is
left to the browser. We could force a font of our own but it's probably
not worth it.
A better solution with a SVG or CSS solution has to be done in master.
That would unify the look of the symbol across all browsers and
also prevent special characters to be placed in translations.
With this forward-port commit, we'll start first by using └ via a CSS
rule. Three new classes have been created: o_we_sublevel_1,
o_we_sublevel_2 and o_we_sublevel_3. Adding any of them on a widget
automatically adds the └ character. Then choosing 1, 2 or 3 controls
the indentation, which was previously controlled by placing the  
HTML entity directly inside strings.
This commit also takes the opportunity to fix some of those level
indentations (sometimes 2 was used instead of 1 or 1 was used instead of
2, etc) and also review some related labels.
closesodoo/odoo#97361
X-original-commit: e5d45643598671077ade7e41f0dbfe2b502665b8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website, website_sale
Before this commit when a search bar was within a navigation bar, its
autocompletion popover was using the text color according to the
navbar's background color determined by the theme. For dark themes, this
made the autocompletion appear almost as white on white.
This commit uses the defaults before applying a specific preset color
so that the dropdown menu style within the navbar uses the original
color.
It also resets the `text-muted` style used in "No results" message.
Also removing the `website_sale.productsSearchBar.autocomplete` template
which was not referenced anymore.
Steps to reproduce:
- Select a dark palette (e.g. one that makes the navigation bars black).
- Drop a "Products Search" block.
- Reset its background color.
- Pick a color combination with a dark background.
=> The autocompletion's "No results" message is shown without contrast.
task-2855511
X-original-commit: f9bf40cb53cf487c8736c1f565c2f0d3834acd5e
Part-of: odoo/odoo#97148
This test is quite long as it is testing all the website form behaviors
in edit mode.
It is sometime failing due to the tour taking longer than 60 seconds.
runbot-4257
closesodoo/odoo#97336
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
*: website
Setting transformations on images is handled by the jQuery transfo
plugin. This plugin, however, also manipulates animations related css
properties allowing the plugin to work on animated images.
After closing the transformation tools these properties stay in the DOM,
preventing the animation options to work properly. Animations are not
played when previewing or selecting a choice from the dropdown list.
Instead they remain stuck in their initial keyframe.
To avoid complications from the interaction between both options, this
commit hides either option when the other is activated. Additionally,
css properties added by the transform option are cleaned, avoiding
potential interactions after the transform option is reset again.
opw-2765529
closesodoo/odoo#97137
X-original-commit: 3ac59a7f841b528a32c14a2111e7a1a7e11c830a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
After [1] moved the website edition in the backend, we feel that the
code required to make the additional debug icon in the footer of the
frontend still work is not worth it.
Before this commit, on a website page, it was not working: clicking on
it from the WebsitePreview client action would only remove the debug
mode of the frontend, and the backend would keep it.
The user can now leave the debug mode from the debug menu systray item
and we consider that leaving debug mode as a visitor (from the
frontend) is not a feature worth keeping.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#95499
Related: odoo/upgrade#3721
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds an 'Add To cart' snippet to the 'Web Editor'.
The snippet works as follow:
1. You choose the `product template` that you wish your users to buy.
2. If the product has more than 1 `variant`, a widget will offer you to either
let the visitor choose - this will open a modal for him to choose the variant
by himself - or select a variant yourself.
3. if `visitor choice` is not selected, a `buy_now` or `add_to_cart` action can
be configured; this will determine the behaviour of the button after the user
clicks it.
task-2824359
closesodoo/odoo#91882
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Co-authored-by: Morgane <morm@odoo.com>
Step to reproduce:
- Enter edit mode
- Drag & drop Cover snippet
- Select height 100% in the right panel
- It will now show the "Scroll btn" option (toggle), enable it
- Now click on footer (to focus out of the Cover snippet options)
- Click on the scroll btn, it will disappear
There were 2 portions of code now in charge of handling that button
removal when a different height is chosen, since [1] was introduced. It
actually made the original portion of code obsolete. This commit removes
it as it was the cause of the bug described above.
[1]: https://github.com/odoo/odoo/commit/85ae7fe56e93fcc18b3842e6c116bcb6968988e3
opw-2920287
closesodoo/odoo#96719
X-original-commit: f777abf697adcadcf717976edd88a3b4bae0ad79
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website, website_mass_mailing, website_payment
When an unsafe snippet is dropped into a sanitized HTML model field, its
unsafe content gets removed on save.
We need a way to mark snippets as being (in)compatible with
sanitization. It cannot be automatic, as, for example, the snippet
introduced at [1] contains an iframe but is compatible with
sanitization.
In 13.0, we will temporarily set up an automatic mechanism that marks
existing snippets containing forms as being incompatible with
sanitization.
In 14.0 a distinction between full sanitization and form-tolerant
sanitization introduced at [2] is added with this forward-ported commit.
This commit prevents unsafe snippets from being dropped into sanitized
HTML model fields.
The "Form Builder", "Product Search" and "Product Search Input" blocks
are now prevented from being dropped or moved into form-sanitized HTML
fields.
To do this, this commit introduces a new `t-forbid-sanitize` attribute
on the `t-snippet` tag. It can have the value `true` to prevent it from
being dropped into any sanitize fields, or `form` to specifically limit
to form-sanitized fields.
Steps to reproduce (in 13.0):
- Go to a product page
- Drop a "Product Search" snippet into the product-specific section of
the
product
- Save
=> The form was removed.
[1]: https://github.com/odoo/odoo/commit/c2e9bd0e60014b6a42931cf300e0f89f8cf7c225
[2]: https://github.com/odoo/odoo/commit/388c222c6c4bb7e2fe3e67009b248359ae0fd3db
task-2829961
closesodoo/odoo#96812
X-original-commit: 9eaba23781766730b06e936dbd9c5d0c28c909c6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Cause:
The test fails because there is some demo data that added additional
website(s) and when trying to retrieve the current website without
domain, it might retrieve the wrong one.
Solution:
Unlink unused website(s).
opw-2899680
closesodoo/odoo#96810
X-original-commit: 45dfbae7301effe0d96163d67218a7854c3bde6f
Signed-off-by: Romain Derie (rde) <rde@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>
When navigating backward to step 2, the website purpose is reset in
order for the navigation to not automatically advance to step 3.
Because of this, when navigating to further steps with the browser's
forward button, that field remains empty. This ultimately produces
an error when the configurator state is extracted to generate the
website.
After this commit the former selected purpose is kept when no purpose
is selected anymore. It is then used when collecting the configurator
details if there is no selected purpose.
task-2789075
closesodoo/odoo#96640
X-original-commit: d874958aa44c0bd96ab7b84f7066c9b8d28642d6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit [1] moved the editor in the backend introducing changes to the
way some options interact with the website. This unfortunately broke
the header position option, the header background option and the footer
visibility option.
The header position option would loop indefinitely, the header
background color option would not display the correct preview colors and
the footer position would trigger a traceback.
This commit fix those bugs:
- The header position option had a callback that was never called, it is
now called.
- The copy of styles introduced by [2] is now less implicit. Only styles
that are defined in web_editor/common/utils:
[EDITOR_COLOR_CSS_VARIABLES] are copied on the snippet menu, and only
those variables will be used as background colors for the preview
elements. (Allowing for every other colors like black and white to be
used with classes).
- The footer visibility option had a broken line of code that was copied
from past code. It is now fixed and working.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
task-2687506
closesodoo/odoo#94949
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>
Before this commit, the "Edit Menu" was displayed for the restricted
editors, even if they didn't have the right to access the website pages.
This was leading to a warning in the "click_all" test with the demo
user, and didn't make sense for the real user (who was prompted an
"access denied" modal).
Now, this menu is displayed only for the website designers.
Additionally to that, the website root instance would load the wysiwyg
assets if it is created inside an iframe which has the "load-wysiwyg"
data-attribute. But the test was not correctly written (as
data-load-wysiwyg was the string 'false'). This would lead to a warning
in the console when a user with no website rights was accessing the
website client action, introduced in [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#96520
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>
*hr_timesheet,point_of_sale,website
This commit moves the settings form view implementation from base
to web, and converts it to owl.
The setting's search has been improved to take into account more
elements. Before, it was possible to only search on the field's
labels. Now, we can also search on the field's description, and
the titles of setting's group.
Part-of: odoo/odoo#78221
Co-authored-by: Samuel Degueldre <sad@odoo.com>
When both a specific inheriting view and a non-specific base view are
written simultaneously, the specific inheriting base view must be
updated even though its id will change during the COW of the base view.
This commit sorts the list of written views in order to first handle the
website-specific ones then the base ones which might change some of the
ids of the already updated view.
Steps to reproduce in 14.0+ (no scenario found in 13.0):
- Create a new website.
- Configure the language selector layout to "Inline".
- Configure the language selector layout to "None".
=> Error notification was displayed and change was not applied.
task-2885882
closesodoo/odoo#96248
X-original-commit: 317eea48186c948009399daedf70dd407f6a9ca8
Signed-off-by: Romain Derie (rde) <rde@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>
Before this commit, if installing a new module from the "new content"
modal would fail, the "Building your website" gif was not removed.
This commit removes it when the installation fails.
task-2687506
closesodoo/odoo#95955
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, following those steps:
- Go to /hello.css
- Create the page/file
- View in page manager
- Click on its row
-> You're redirected to the file, with infinite loading
This commit fixes this behaviour by unblocking the iframe:
- on the OdooFrameContentLoaded event for frontend pages
- on the load event for other pages
To do that, the BlockIframe component is changed to handle process ids.
Before this commit, the BlockIframe component would count the calls to
block or unblock the iframe (and store it in an iframeLocks variable),
so that multiple processes can block the iframe independently from each
other.
As an exemple, for two processes A and B, the iframe should remain
blocked during those two processes, and released at the end:
(A) blockIframe => (B) blockIframe => (B) unblockIframe => (A)
unblockIframe.
But that iframeLocks variable was fragile: a process that blocks the
iframe should unblock it once, otherwise it would mess up the locks
count. It was not appropriate for a process that could be ended with two
events, for example loading the iframe. The first of the 'load' or
'OdooFrameContentLoaded' events should unblock it.
To change that, a process can block the iframe with a processId. The
first unblock call with the same processId will unblock the iframe, the
other ones will be ignored.
task-2687506
Part-of: odoo/odoo#95955
Before this commit, clicking on a different variant of a product from
the WebsitePreview client action introduced in [1] would not update the
browser's url.
This commit adds an event listener to update the browser url on hash
changes, as load events are currently handled.
The product variant buttons are directly changing the hash instead of
replacing the state of the history.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#95955
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 [1] when Bootstrap 5 was introduced, the position of the
connectors between steps of the "Steps" block is wrongly computed.
The left offset of the connectors between steps is computed as 50% of
the column width + half the size of the content it connects to.
In Bootstrap 4 the columns are positioned as relative.
In Bootstrap 5 the columns are positioned as static.
Because of this "50% of the column width" became "50% of the row width"
in Bootstrap 5.
This commit makes the specific columns of this snippet positioned as
relative so that the offset calculation get back to its former result.
Steps to reproduce:
- Drop a "Steps" block.
=> Connectors are wrongly positioned, even spanning outside the page.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-2729177
closesodoo/odoo#96071
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when clicking on a link with the standard header as
anchor (e.g. Enable "scroll to top button" option to the footer in edit
mode). The scroll animation stopped before reaching the top.
This happened because we stop the scroll animation when the scrollTop no
longer changes. This is the case during the standard header transition
animation. It is only at the end of the transition that we can know that
there has been a change of scrollTop. So this commit makes sure to wait
for the end of the transition to check the scrollTop position.
This commit also adds a "z-index" on the footer "scroll-to-top" button
to place it on top of the elements around it. Before that, the entire
button area was not clickable because it was partly covered by the
elements around it.
task-2773973
closesodoo/odoo#96067
X-original-commit: 201298c66d86c27c1ee05489ccf5c70da88b7e14
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>
This commit makes some adaptation in the scss of the website visitors
kanban view with respect to the introduction of the owl kanban view.
closesodoo/odoo#96003
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Since 4f984568e1, the css theme is not
correctly applied to the website theme selector.
The order in which the css rules were applied without the
'.o_legacy_kanban_view' selector removed a margin from the
kanban_record element.
closesodoo/odoo#95936
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Install multiple langages, each time translating the website. In a
private browsing session access /contactus, show the page source, the
multiple alternate URL (`<link rel="alternative">` in the `<head>`) are
all pointing the canonical URL instead of the alternative.
closesodoo/odoo#95683
X-original-commit: 3d4b4d3dcff864613a9e7038137e21674425ed08
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
With this commit, users can no longer have headers that have the sidebar
template and the over the content option at the same time.
Steps to reproduce the problem:
- Edit a website
- Edit the navbar
- Set Header Position to Over the Content
- Change the navbar template to Sidebar
The navbar is not displayed properly and there is a margin on the left
that should not be there.
task-2877421
closesodoo/odoo#95463
X-original-commit: 618fd49642310c7b97ef3b9e6c01f8f691c7b12f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the switchTheme option was redirecting the window to
the theme_install_kanban_action url.
After [1] was merged, the editor is instantiated inside the webclient
and the action can now be opened directly from there, without a reload.
For that, the request_save event data can include an 'action' parameter,
which the WysiwygAdapter will use after leaving debug mode to trigger
the action with the action service.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#81485
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Younn Olivier