Before this commit, the pager was on the left or centered.
Now, it is always centered regardless of the website pages (portal or
not).
closesodoo/odoo#97967
Related: odoo/enterprise#30343
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
- Make the animation smoother and less prompt to bad UX:
1. The animation duration of the closing part is now slower. Somehow
it looked like the closing animation was faster than the opening.
2. The animation delay of the closing part is now bigger. It will
prevent some weird UX issues when the cursor is moving out of
the window by mistake (eg moving a bit too far in the bookmarks
bar or the Ubuntu left panel for instance). In those case, despite
the user wanting to open and click inside the navbar, it would
directly close it.
- Make the edit button only visible for editors
- Make the go to backend button only visible for internal users (not
portal anymore)
- Restore a behavior that was lost during the frontend > backend task
[1]: clicking on the app switcher in community should show the list of
apps so you can directly access where you want to go in the backend.
It improves the usability in community where you otherwise have to
click twice every time as the first click always brings you to the
discuss module from where you have to click again on the app switcher
to select the app you wanted to land on.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#97745
Related: odoo/enterprise#30218
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose is to ease finding server actions code and views. We just rename
some files and move some code, nothing should change functionally.
Task-2613245 (Server actions cleaning and mail update)
Part-of: odoo/odoo#75906
Since [1] when Bootstrap 5 was introduced, the images of search results
are not aligned anymore. This is because the detail part of the result
has been set to `flex-grow-1`.
This commit restores the former flex parameterisation through a new
class. The fix is applied both on the autocomplete results template and
the hybrid results element template (used to render `/website/search`).
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-2951028
closesodoo/odoo#97944
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The goal of this commit is to fix "New Page Dialog" margin issue
related to the use of '.form-group' CSS (dropped on BS5) and replace
it with a simple row gutter.
closesodoo/odoo#97919
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit [1] moved the edition of website from the frontend to the backend
and in doing so, introduced an iframe from which the website is edited.
This broke some behaviours as the event binding for jQuery widgets (such
as the carousel) is no longer done from the same jQuery as the editor.
So bootstrap events triggered inside the iframe do not reach options
that are listening using the top window's jQuery (simple $()).
This commit adds the $bsTarget property to the SnippetOption class.
It wraps $target[0] using the iframe's jQuery instance.
This allows for options to listen to bootstrap events.
(using $bsTarget.on)
Options that were doing that previously are adapted by this commit.
(Carousel, Popup, Accordion (collapse))
Note: Popup was already adapted locally (by [2]), this commit only
changes its use of an $iframeTarget property to the $bsTarget one.
This commit also fixes "Add item" on accordion snippet to properly
assign a unique ID to the new tab.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-2687506
Part-of: odoo/odoo#94564
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
Steps to reproduce:
- Go on website
- Click on edit
- Add a snippet
- Click on discard
- Close the popup using the 'X' at the top of the popup
- Buttons are still disabled
Commit [1] adapted the website dialogs to the OWL Api but also
introduced this bug.
This commit fixes that behaviour and re-enables the buttons
if the popup is closed.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
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
Since [1] when the search bar was refactored, a search facility was
added on website pages and the rendering of those search results did
not correctly handle the HTML escaping.
This is related to the fact that the `ir_ui_view`'s `arch_db` field is
stored with this double escaping on text nodes, which is done by
`wysiwyg.js` through the `_getEscapedElement` method since [2].
This commit unescapes the last layer of `&` before extracting the
page's text for generating the search results.
Steps to reproduce:
- Add some "&", "<" or ">" characters in a page.
- Use the search snippet to lookup for the page.
=> The results in both autocomplete and the results pages display the
content with an extra unwanted escaping (&...)
[1]: https://github.com/odoo/odoo/commit/9f9c4bb7e40233e633f97c60fb00ae191e9077af
[2]: https://github.com/odoo/odoo/commit/f5acea7f9ce232773ec3adf1828a3d18bbedee1e
opw-2908645
closesodoo/odoo#97748
X-original-commit: 2b95dcdb0d8b49bac8ee38a8d062112468124012
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
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
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>
Romain Estievenart