In this commit, _t import from import { _t } from
"@web/legacy/js/services/core" and from
web/static/src/legacy/js/core/translation.js are replaced by
@web/core/l10n/translation.js.
task-3292454
closesodoo/odoo#130865
Related: odoo/enterprise#45270
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
This commit removes legacy patch/unpatch functions and adapts their use
by using the modern patch. There was also a custom patch function used
in tests which has been replaced too.
closesodoo/odoo#130867
Related: odoo/design-themes#685
Related: odoo/enterprise#45271
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
As steps are encapsuled in an arrow function from
69a5d8e3ce47238 for steps tour definition to avoid
direct Markup(_t()) interpretation, the same is done
for registerWebsitePreviewTour() of
"odoo/addons/website/static/src/js/tours/tour_utils.js"
in this commit.
This is done in anticipation of the use of
_t() (import from @web/core/l10n/translation) with
registerWebsitePreviewTour().
task-3292454
closesodoo/odoo#130248
Related: odoo/design-themes#678
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Add test to verify scrollbar behavior for page and popups with or
without backdrop. The expected behavior is that the page scrollbar
should not be present when a modal with a backdrop is open, and that the
page scrollbar should be displayed if the popup does not have a
backdrop, such as a cookie bar. However, if a modal without a backdrop
itself has a scrollbar, the page scrollbar should not be displayed to
prevent the two scrollbars from overlapping, which prevents scrolling of
the popup on Chrome (when clicking on the scrollbar instead of using the
mouse wheel).
In addition to that, this commit includes a test to confirm the proper
functionality of snippet animations when a cookie bar is displayed on
the page. Moreover, it also verifies that the snippet animations perform
correctly within a popup.
During the forward port of this commit (Master branch), the test failed
due to missing braces around 'throttleForAnimation' in the '000.js' file
of 's_popup'. These were directly added in this commit.
task-2983901
closesodoo/odoo#128914
X-original-commit: 4dd462f20ccb29923e5a053e0ed4c08545f82ae7
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
*: test_website, website
Steps to reproduce the bug:
- Drag and drop a text-image snippet onto the page.
- Add a shape to the image of the snippet by selecting the shape from
the options.
- Click on the "replace" button in the options of the image.
- In the media dialog, navigate to the "icons" tab.
- Choose an icon.
- Inspect the HTML code of the icon in the DOM.
- Bug: The 'data-shape' attribute with a value is still present.
After this commit, when replacing media, the transfer of element
attributes specific to "shape" elements only occurs towards an image and
no longer towards other media (e.g. icons).
We also prevent adding shapes to images that don't support it (e.g. SVG
files). Before this commit, when replacing a .jpeg image that had
a shape with a SVG image, the shape was not removed.
This commit also adds tests to prevent these bugs from reappearing.
task-3420533
closesodoo/odoo#129079
X-original-commit: 023b0b3124a7181fdf486df8c830bb16edd10aa6
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
*: web_tour, website
When no transformation is applied on an image, changing the quality
sometimes increases its storage size.
This commit makes sure that the original image remains used if only the
image quality is modified and if this makes its storage size bigger.
Fixes#61619
task-2835144
closesodoo/odoo#103398
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The goal of this commit is to remove all dependency to legacy in the
wysiwyg because the wysiwyg has to be loaded on a lot of form view
(through the html_field).
To remove the dependencies, all the legacy widget that the wysiwyg
uses had to be converted to owl. In order to finish the PR faster,
only a partial conversion of the widgets is done, changing only the
part of the code that was necessary for it to work instead of
rewriting the whole widget from scratch. Another pass should be done
to convert all those widgets to fully embrace the owl paradigm.
task-3175256
Part-of: odoo/odoo#118966
Before this commit, the o_not_editable class was used as a way to
dynamically set contentEditable on a node. This was little more
than a convulated way to write `node.contentEditable = false`.
Moreover, the o_editable class was not treated the same way and
did not set contentEditable to true.
This commit turns those two classes into markers for contentEditable
values in html. Once those classes are set, the contentEditable
attribute is updated accordingly. It is not updated dynamically
afterwards. For dynamically setting a node as editable or not, use
the contentEditable attribute directly.
Task-2782426
Part-of: odoo/odoo#120690
This commit separates the test that was added together with the "not
move images twice within image wall" fix because it requires additional
fixes for working in 16.0.
task-2990053
closesodoo/odoo#125758
X-original-commit: f4e8ca1eca1193a72a0b1d21cbc4af5093907ca9
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Since this commit [1], when clicking on an image that is not a link and
then clicking on an image that is a link, the first image that is not a
link becomes a link.
This issue occurred because we were triggering
'activate_image_link_tool' in 'toggleLinkTools' before the options for
the selected image were ready. As a result, 'activate_image_link_tool'
was being triggered on the previous image (the one that is not a link),
causing it to become a link.
To fix this, we now only trigger 'activate_image_link_tool' if the URL
input needs to be focused (e.g., when clicking on the "edit link" button
in the image popover).
Steps to reproduce the bug:
- Drag and drop a "Columns" Snippet onto the page.
- Click on the image of the first column.
- Click on the button to create a link in the options of the image.
- Type "/" in the url input.
- Click on the image of the second column.
- Click on the image of the first column.
- Click on the image of the second column.
- Bug: a link is added on the image of the second column.
This commit also modifies the "link_tools" test to avoid this bug
reappears.
[1]: https://github.com/odoo/odoo/commit/11ee7d5520c3a14a381b3f5b973114670f1e2edb
task-3422238
closesodoo/odoo#128806
X-original-commit: fef32aa339177a2ca008ab988cb0ac0a670c110c
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit converts the Website Dashboard to OWL.
The main goal of the Website Dashboard is to display the Plausible
Dashboard inside an iframe. Most of the code from the legacy widget was
actually used by website_sale and not website. Since Website Sale
dashboard is to be re-done in the dashboard app (by task-3222991), a lot
of the logic could be removed and simplified.
task-3164163
closesodoo/odoo#112819
Related: odoo/enterprise#44087
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when the user was clicking on a link to another page
of the website, it was opening in another tab but in frontend mode.
However, in most cases the user actually wanted it to open in backend
mode.
Here is an example of users who started an eCommerce trial. They are
editing their homepage and want to create a product. They open the
"/shop" page using popover but because they are in the frontend, they
don't see the "+NEW" button. This behaviour seems a little odd.
Therefore, this commit aims to open internal links in the edit(backend)
mode instead of the frontend mode.
task-3177126
closesodoo/odoo#128114
X-original-commit: f7dacce18bf44914972da292ff041505289d1e16
Signed-off-by: Divyesh Vyas (divy) <divy@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit introduces a new feature to the popup snippet.
Up until now, the popup could be displayed after a delay or on exit.
This commit enables the popup to be displayed on click.
To make use of this feature, the user will need to:
- Set the "Display" option of the popup to "On Click (via link)".
- Paste the anchor that has been copied to the clipboard into the
URL input of any link.
This commit also adds a test for this new feature.
task-2172312
closesodoo/odoo#76442
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Go to website > drop a snippet with text content.
- Select a text > click on text animation button to activate the option.
- Click on the button to disable text animation > The text animation
cannot be applied again on the text.
Starting from 16.0 (exactly [1]), the `document` > `selectionchange`
event listener was added on `this.$body[0]`, which means the code from
`__onSelectionChange` will never be executed, and as a consequence, the
option will handle the text as if it has already an animation because
of the not correctly updated value in `this.$currentAnimatedText`.
Spotted while working on [2].
[1]: https://github.com/odoo/odoo/commit/3c2febddb67888617dad74af0e9e46ed60d105b7#diff-d2188391a9d83cc97f3220e08d259e82796d94191dcf5e5fdb9b77e57074e6a5
[2]: https://github.com/odoo/odoo/pull/122751
task-3414256
closesodoo/odoo#127812
X-original-commit: 1bf244c77f4bd1f52c0964b75e0ce5582bfa54f7
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
The website frontend apps menu list is not working when the user has a
`Home Action` defined on his user.
The `Home Action` is meant to redirect to the defined action whenever
that user is login in.
But since the backend menu links on the website have most of the time
no `action` defined but just a `menu_id` defined, the `Home Action` will
kick in and take over the redirection, the same way as if the user just
type `/web` without any params.
To solve that, we simply force the `action` of those links (if they
don't already have one).
This will make sure that the redirect is working as it should for users
having a `Home Action` set.
Step to reproduce:
- Set a Home Action for any user, like "Contacts"
- Go to the website frontend, eg on `/`.
- Click on the top left button to show the backend app menus list
- Click on any menu (CRM, Invoicing, Calendar..)
-> Most of those menu will not redirect you were you are supposed to be
but on your Home Action instead.
You can figure which one will be buggy or not by just mouseovering
the link and see if the URL param `action` is set to something or
not.
--- Technical hints ---
There is multiple methods to get the list of menus in Odoo:
- `load_web_menus`: called by the web client rpc, calling `load_menus`.
If a top/app menu has no action defined on it, it sets the first found
action of their children menus to it.
It returns the full (flat) list of menus, not only the top/app ones.
This method is not ormcached but is calling an ormcached method and
just doing some tiny work on the data.
- `load_menus_root`: called only by website backend template to add the
app list on the website (in the frontend) to jump to the backend.
It does not force the action if a menu has no action set on it.
It returns only the top/app menus.
This method is ormcached.
Note that this method seems only used by the website module.
- `load_menus`: returns the full (flat) list of menus without a force
action
This method is ormcached.
Fixes https://github.com/odoo/odoo/issues/119971
task-3378963
closesodoo/odoo#127840
X-original-commit: f28a349aa40b2ea48ef8f2b71e806b965777014f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The unsplash beacon public widget is started before the test assets JS
is loaded. Because of this, the approach in [1] fails sporadically.
If the result from the `/web_unsplash/get_app_id` RPC is obtained
before the test assets JS is loaded, the beacon patch is not applied
in time, and the test fails.
This commit applies the patch within the actual page HTML to avoid this
issue.
[1]: https://github.com/odoo/odoo/commit/a5abc766424f34074be3ae7a97ad7c6e9583f9c5
runbot-22610
closesodoo/odoo#127809
X-original-commit: 3f64135ff136addfad7c4c79e8c19cc33f8b19cf
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since [1] the page manager tour test fails from time to time because it
manages to click on the Delete Page popup's OK button before it is
enabled.
This commit makes sure it only clicks on the button once it is enabled.
This commit also includes the master version cleanup of [1].
[1]: https://github.com/odoo/odoo/commit/a65d8811119f4d1a044be3e140fd0c27ad1cf823
runbot-20823
runbot-23032
closesodoo/odoo#127614
X-original-commit: 668fc8fa6f56b8eda9c81300a818da2559c0d0dd
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, the "click on save" in french step was checking for
the element containing the "Save" french translation term, which is
coming from Transifex.
It sometimes changes, making the tour fail.
It was "Sauver", then "Sauvegarder" and now "Enregistrer".
This was a well known issue as we already made a quick and dirty fix for
that with [1].
It was judged enough as we did not want to spend more time on this fix
as it was expected to not break anytime soon, and we needed a quick fix.
The chance is now taken to adapt the test to not rely anymore on the
.pot file.
We also take the chance to not use an existant translation but a fake
one as it will speed up the test (no need to actually read/parse .po
files are there is none for this lang).
[1]: https://github.com/odoo/odoo/commit/594ac2c9651f27cc1623fcd5b916cb191241651b
runbot-22946
runbot-22945
closesodoo/odoo#127493
X-original-commit: 6d9d4d1b43544ae98cc8037ba01c81b66ab9f0ee
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Form fields can be prefilled since [1] and their visibility
conditionally linked to other fields since [2].
1. This commit ensures prepopulated fields trigger the conditional
visibility mechanism (A), including when said field is first hidden,
then conditionally displayed (B).
2. Until [3], with a chain of visibility conditions, when one of them
was "contains", "does not contain" or a date-related condition, a
traceback was raised (C). This commit corrects the fix from [3] to
prevent this behavior now that the reason has been identified.
3. Tests are also set up to enforce these fixes.
Steps to reproduce (A):
- Drop a form
- Make field A depend on field B being set
- Have field B be autopopulated from user mail
- Save and check the form: A won't be shown despite B being set
- Removing one letter or typing anything in the input B will trigger
the visibility of A.
- Expected result: B should immediately appear.
Steps to reproduce (B):
- Drop a form
- Make field A depend on field B being set
- Have field B be autopopulated and depend on field C being set
- Field C is empty by default
- Save: only field C is shown. Type a letter: field B appears, but not
field A.
- Expected result: both should appear.
Note: this bug only occurs when field A is before field B.
Steps to reproduce (C) (until [3]):
- Drop a form
- Field A depends on B containing "abc"
- Field B depends on C being set
- Save and type something in C: there is a traceback.
task-3335536
[1]: https://github.com/odoo/odoo/commit/54873d2
[2]: https://github.com/odoo/odoo/commit/2dcbfec
[3]: https://github.com/odoo/odoo/commit/2714469closesodoo/odoo#126634
X-original-commit: 074dbb6842de1092af2abe51e6da0433ff38a96e
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit ensures that the unsplash beacon calls home when an unsplash
image appears on a page.
To achieve this it patches the RPC call when the test URL contains the
test name as parameter. The patch cancels the actual beacon call to
avoid polluting data during the test, but marks the image as having had
its beacon message sent. The test then simply checks if this marker
appears on the image.
task-3360109
closesodoo/odoo#126522
X-original-commit: 1b0f25130b461e7b531548363c680200c7363e7f
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: web_editor, website
Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Put a "Blur" filter on the background image.
- Save.
- Change the parallax from "Fixed" to "None".
- Save and edit.
=> The "Filter" option displays "None" but should display "Blur".
When changing the parallax, `setTarget()` is called. The goal of this
function is to transfer the `background-image` from the old target to
the new one. The commit modifies this function by adding the transfer of
the dataset information relative to the background image from the old
target to the new one. It also transfers the `o_modified_image_to_save`
class from the old target to the new one if needed.
Upgrade PR: https://github.com/odoo/upgrade/pull/4767
task-3287330
closesodoo/odoo#123873
X-original-commit: c82d01f7532b5b120bedfbc40bf8f2f07d750ed6
Related: odoo/upgrade#4767
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
*: website
Commit [1] (and [2]) from the "website in backend" refactoring adapted
the colorpalette to read color information on the right document (as
the right document could now be the one of an iframe which is inside the
editor environment). Unfortunately, it did not do that correctly, making
an inconsistent API relying on the fact the colorpalette should receive
an "editable" param... while a jQuery version "$editable" param of the
same thing already existed. Doing so, it forgot to give that important
"editable" param in two cases:
- For editor toolbar colorpickers (text foreground/background edition)
- For colorpickers inside another UserValueWidget (like we-multi).
This commit solves the inconsistency by removing the need of that
"editable" params and relying on the previously existing "$editable". In
the future, this should be refactored anyway.
Steps to see the issue (A):
- Enter edit mode of one of your website page
- Select some text
- Hit the "reset" (trash button) of the text background colorpicker
=> The text becomes black for no apparent reason.
Steps to see the issue (B):
- Enter edit mode of one of your website page
- Choose a new main color for your website via the theme tab
- Select some text
- Open the colorpicker for the foreground color
- Go to the solid tab and input explicitly the main color of the website
=> The color is hardcoded on the selected text instead of using the
text-o-color-1 class.
=> A test has been added to check this usecase. Making a test for (A)
is less robust as it also requires the backend color names not being
the same as the frontend ones to have the bug (otherwise it works by
chance)... and that will be solved by the next commit of this PR
(another test will be added by that commit too) **.
Note:
- After this commit, following (A), a bug remains: the text receives a
strange padding (as a "inherit" background is actually applied).
Another PR will be made to solve that (see task for more info).
- ** After this commit, (A) done in backend HTML fields instead of a
website page leads to the same bug still. This is because of another
problem that the following commit of this PR will solve.
[1]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-3237693
X-original-commit: a30206606423af9e6c8e0313c74fd6200247437e
Part-of: odoo/odoo#125131
Since commit [1], the text selection must be kept if there was one when
using a snippet option. However, it is not the case when toggling the
grid mode for snippets that have None columns (e.g. Text) or have some
content outside of their row element (e.g. Picture). Indeed, when these
contents are wrapped inside a new column and then in the row, the
selection is lost.
This commit, as done in commit [2], restores the selection after the
content wrapping. It also adds a test checking if the selection is well
kept when toggling the grid mode and going back to normal mode.
[1]: https://github.com/odoo/odoo/commit/e8112e2865ca449c4df9cd6147e9e24c4c6dcd41
[2]: https://github.com/odoo/odoo/commit/e4d7fbfca85c869d3a04dc517a8ad522cb533a90
task-3324775
closesodoo/odoo#124513
X-original-commit: bcb0e9b83fcb7e3f8a66131a089b88b39f58a2e4
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
* = project,website
On the small screen, the sub dropdown is a bit weird to positioning, so
we use an accordion instead.
We apply this change also on desktop to avoid split behavior between
small screen and bigger screen and also to avoid duplicating code.
Also, we have made some DOM/CSS change:
* avoid reflow of the search bar menu by adding a min-width on the
columns and a max-width on the input for custom groupbys and favorite
filters
* re-align caret vertically for accordion indicators
* reword favorite edition items and add a tooltip
* all menu items have the class `o_menu_item`
closesodoo/odoo#122635
Note: DOM and some tests were adapted to reflect the change
Task-id: 3276542 (Part of)
Related: odoo/enterprise#41563
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
*website
Steps to reproduce the bug:
- Add a Cover and a Picture snippet on the website.
- Change their visibility to "Conditionally".
- Change the order of the two snippets on the page either with the drag
and drop tool or with the "move up" or "move down" option.
=> Their order on the "Invisible Elements" panel has not been updated.
The problem is fixed by calling `_updateInvisibleDOM()` at the end of
`moveSnippet()` and `_onSnippetDragAndDropStop()`. Note that before this
commit, all the snippets with a conditional visibility were hidden at
the call of `_onSnippetDragAndDropStop()`. This is due to the call of
`cleanForSave()` from `_destroyEditors()`. `_onSnippetDragAndDropStop()`
has been adapted in order to, as for the "move" option, do not change
the visibility of those elements.
task-3203914
closesodoo/odoo#123027
X-original-commit: 3a023cf00812cfbbef7f3b406fbd01b74f07b7c8
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
*web_editor, website
Steps to reproduce the bug:
- Add a Text-Image snippet.
- Change its visibility to "Conditionally".
- Save.
- Edit again.
=> The eye icon indicates that the snippet is not visible but the
snippet is displayed.
Note that [1] introduced a mechanism to solve this problem (the
`cleanForSave()` of the `ConditionalVisibility` option) but the code was
not working correctly since [2].
Let's first remember that when calling `toggleTargetVisibility()`, two
main actions are performed:
- The addition or suppression of the `data-invisible` attribute from the
dataset of an invisible element. This attribute is responsible for the
crossed or not of the eye icon in the "Invisible Elements" panel.
- The call to `onTargetHide()` or `onTargetShow()` that performs among
other things the addition or the suppression of the
`o_conditional_hidden` class on an invisible element. This class is
responsible for the visibility of the element on the page in edit mode.
This being said, here is what happened at the "Save" before this commit:
- `cleanForSave()` of `snippetEditor` is called. If the related element
has the `o_snippet_invisible` class, `toggleTargetVisibility(false)` is
called (meaning that the `o_conditional_hidden` class and the
`data-invisible` attribute are added to the element).
- `cleanForSave()` of the `ConditionalVisibility` option is called and
before [2], the `data-invisible` attribute was removed from the
corresponding element.
- At the `DOMContentLoaded`, the `o_conditional_hidden` class is removed
from all the elements that have a conditional visibility. The visibility
of those elements on the page now depends on the rule set by the user.
The goal of this commit is to restore the mechansim of the remove of the
`data-invisible` attribute from the conditionnal elements at the
`cleanForSave()`.
[1]: https://github.com/odoo/odoo/commit/1c442782f887a8c16bae05a43fae13a310ac05df
[2]: https://github.com/odoo/odoo/commit/de3c29fab2bc5349da8a9418f9d0086d76e6f7de
task-3203914
X-original-commit: b10d6cbf78235acd170716d556578227cccfbc14
Part-of: odoo/odoo#123027
Before [1], chat windows were not shown on the website preview.
Showing them was not intended and those chat windows overlap
with the one of the livechat.
This PR restores the previous behavior by preventing chat
windows to be shown on the website.
[1]: odoo#110188
closesodoo/odoo#123096
X-original-commit: 3e74f5c1f4ea045725edcd945276e524529ffd97
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
Steps to reproduce the bug:
- Drop the "Form" snippet on the website.
- Add a new field.
- Replace the field label by two quotation marks (`""`).
=> Traceback appears.
Since [1], it is possible for the user to create forms whose fields can
have a conditional visibility, meaning that the field is only visible if
another field in the form meets certain conditions. Due to that, there
is a mechanism that verifies if a condition on a field should be updated
when the user modifies the label of a field. To do so, a `querySelector`
is searching for an element that has a `data-visibility-dependency` set
to the previous field name by doing a querySelector of type
`querySelectorAll('.s_website_form_field[data-visibility-dependency="${previousInputName}"]')`.
Because `previousInputName` is set to `"`, it is not considered as a
character and an error is thrown.
To resolve this problem, strings that are stored in `name`, `data-name`
and `data-visibility-dependency` are encoded: All the occurrences of `"`
are replaced by `"`, all the occurrences of `'` are replaced by
`'` and all the occurrences of ``` ` ``` are replaced by `‘`.
[1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce
opw-3246341
closesodoo/odoo#122782
X-original-commit: ccaf4f1e52f10308ef507059316732c02ad6e6e4
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
The goal of this commit is to be able to use the `addCustomField`
function with a `type` argument that is different of `checkbox`,
`radio` or `select`.
opw-3246341
X-original-commit: 34b3770ad1ee9c872acaf4f82ac3c6cf52d5d333
Part-of: odoo/odoo#122782
Steps to reproduce:
- Go to a website page > Add a 'Form' block > Set an input "Placeholder"
value.
- Go to the page (in 'edit_translations' mode) > The translation of the
input "Placeholder" attribute doesn't mark the input as translated and
even after saving the translation, the input is still marked as
"to_translate".
The goal of this commit is to fix this issue by extending the same
behaviour on the translated `<select/>` options (using `.oe_translated`
class) and setting the right translation state on the input from the
linked attribute translation `<span/>`.
task-3323245
closesodoo/odoo#122011
X-original-commit: 946de52ea80e0cf5f1284cea2134c22ffda3aa5f
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit this tour was often failing. It seems to be because
there were some requests still being executed / received after the test
was marked as successful and browser getting killed.
According to the logs, even when the tour is actually not failing, there
is still some unexpected requests going on.
With this commit, saving and waiting the edit mode to be exited will
prevent all those requests issues, as it seems like the requests done
after exiting edit mode are all awaited before marking the test as
successfull.
== Before the fix success case ==
- Tour snippet_editor_panel_options on step: 'The text toolbar should still be visible, and the text still selected. (trigger: #oe_snippets .o_we_customize_panel > #o_we_editor_toolbar_container)'
- GET /website/static/src/img/snippets_options/header_template_default.svg HTTP/1.1" 200 - 0 0.000 0.003
- [Same GET for 10 other header templates]
- test successful
- Session expired
- POST /website/theme_customize_data_get HTTP/1.1" 200 - 3 0.001 0.003
- [2 lines above x10]
- Deleting cookies and clearing local storage
- Navigating to: "about:blank"
- Navigation result: {'frameId': 'A538603CC37A4E9EBA99B8624C1CD34E', 'loaderId': '9187051DD3D9477FA4EDEB1A544D584E'}
- Waiting for frame 'A538603CC37A4E9EBA99B8624C1CD34E' to stop loading
- waiting for threads: [<Thread(odoo.service.http.request.139669352166976, started 139669352166976)>]
== Before the fix error case ==
- Tour snippet_editor_panel_options on step: 'The text toolbar should still be visible, and the text still selected. (trigger: #oe_snippets .o_we_customize_panel > #o_we_editor_toolbar_container)'
- GET /website/static/src/img/snippets_options/header_template_sidebar.svg HTTP/1.1" 200 - 0 0.000 0.004
- [Same GET for 10 other header templates]
- test successful
- GET /web/static/img/smile.svg HTTP/1.1" 200 - 0 0.000 0.001
- GET /web/static/img/spin.svg HTTP/1.1" 200 - 0 0.000 0.001
- Failed to fetch
- Asking for screenshot
- Trying to set result to failed (TypeError: Failed to fetch) but found the future settled (<Future at 0x7f8fa1a25120 state=finished returned bool>)
- Deleting cookies and clearing local storage
- Screenshot in: /data/build/tests/36222061-master-all_no_autotag/screenshots/sc_20230513_220042_739175_TestUi.png
- Navigating to: "about:blank"
- Navigation result: {'frameId': 'E1A779132E972A440E5FE892BBBC9FEC', 'loaderId': '822ACED443DB0C84F57DD4A1FF451D5B'}
- Waiting for frame 'E1A779132E972A440E5FE892BBBC9FEC' to stop loading
- waiting for threads: [<Thread(odoo.service.http.request.140254747010624, started 140254747010624)>]
== After the fix case ==
- Tour snippet_editor_panel_options on step: 'iframe body:not(.editor_enable)'
- GET /web/static/img/spin.svg HTTP/1.1" 200 - 0 0.000 0.003
- POST /website/theme_customize_data_get HTTP/1.1" 200 - 8 0.002 0.035
- [Many other POST/GET requests]
- test successful
- Deleting cookies and clearing local storage
- Navigating to: "about:blank"
- Navigation result: {'frameId': '4B87BC8A50A3FEBD7D508394DD5BDB19', 'loaderId': '7CCB3B6434B52B456A1AA470C3CFA1BF'}
- Waiting for frame '4B87BC8A50A3FEBD7D508394DD5BDB19' to stop loading
- waiting for threads: [<Thread(odoo.service.http.request.139744500471360, started 139744500471360)>]
runbot-15312
closesodoo/odoo#121795
X-original-commit: 936cc061ab20dc1fe4587b24f59dc322d0e7ad9b
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The generation of the assets may make this step fail randomly.
The pregenerate is not enough because this is generating assets for
website2.
This issue will be partially solved in master with this PR [1] by not
generating an asset if a close one is found in the database.
For now just increase the timeout for this test.
[1]: https://github.com/odoo/odoo/pull/121376closesodoo/odoo#121777
X-original-commit: c3209aec9741cda8597525add88b0a932fb7532a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Edition of block links has been broken several times.
This commit adds a test that makes sure it does not happen again by
changing the URL of a card of a mega menu with the Cards template.
task-3300977
closesodoo/odoo#121362
X-original-commit: b4b5816a4acd953eb4dabfd14d2a142934dee357
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
[FIX] *: selectors in tours
[FIX][TMP] account: CogMenu selector in tours
[FIX][TMP] web*: Breadcrumb targetting in tours
Adds a `o_breadcrumb` class to target the whole breadcrumb, no matter
how much elements it contains (collapsed parts, visible path, single
name...).
add classname on last breadcrumb item
[FIX][TMP] project: View buttons selector in tours (moved away from CP)
[FIX][TMP] project: Kanban selectors in tours (quick create)
[FIX][TMP] *: SearchBar selectors in tours (toggle menu)
[FIX][TMP] *: ButtonBox selector in tours
[WIP][IMP] web: add toggleSearchBarMenu in search helpers
adapt and unskip 3 list tests
adapt and unskip calendar tests
unskip web_tour test that actually pass
post rebase fix
allow to lose cell focus after multi edition (given to searchbar) - bug reported, to check later
post rebase fixes
fix
Part-of: odoo/odoo#116641
*: website, website_blog, website_event
This commit adds the TikTok social network to the other social networks
stored in DB. Thus, users of the Website application will be able to
reference their TikTok page on their websites. This commit also updates
the different templates and the social media block to integrate this new
social network.
task-3235451
Part-of: odoo/odoo#116837
*: test_website, website_blog, website_crm, website_hr_recruitment,
website_mass_mailing, website_sale, website_sale_wishlist,
website_slides
This commit creates a new util which clicks on edit and waits for the
edit mode to be started. This way, we make sure that the edit mode is
enabled before testing the next step of the test. This avoids race
conditions during tests.
This commit replaces all the uses of the old util with the new one, it
also removes the steps that are waiting for the edit mode to start.
Finally, from [this other commit], we can start a tour in edit mode. For
these tests (which have `edition: true`), it is useless to check if the
edit mode has started at the beginning of the test because this check is
already done by default. This commit removes unnecessary / duplicated
steps.
[this other commit]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35#diff-c7720501ec33f5f92c907d8bb41de50edd832a4564317073e801a6915796a6bdR278
task-3203820
closesodoo/odoo#120481
X-original-commit: https://github.com/odoo/odoo/commit/9fd5d25f59578abc9c608578a7d2e2953880b582
Related: odoo/design-themes#656
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
The goal of this commit is to fix the race condition introduced by
[this commit]. Here were the problematic steps:
- Open the mega menu.
- When then mega menu is opened, scroll up.
- Open the mega menu after scroll.
Before this commit, what could happened was that the mega menu did not
have enough time to be closed after the scroll. Clicking on it would
then actually close it rather than open it as wanted. This commit adds
a step to ensure that the mega menu is closed before open it.
[this commit]: https://github.com/odoo/odoo/commit/9b1de9e28697edbb6e1fa88665294f983f60e37f
runbot-20660
closesodoo/odoo#119438
X-original-commit: abd0038de73a057eb9c34dc8d316b67d96fac409
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the upgrade to Bootstrap 5 and especially since this [BS5 commit],
there is a gap between the mega menu and the navbar when the user opens
a mega menu. This commit removes that gap.
Steps to reproduce the bug fixed by this commit:
- Have a mega menu on your website.
- Drop a block of a dark color at the top of the page (it helps to see
the problem).
=> When you open the mega menu, you can see a small piece of the block
of dark color between the navbar and the mega menu.
Technical explanation:
This [BS5 commit] introduces a new css rule that adds a
`margin-top: 0.125rem;` on the `.dropdown-menu[data-bs-popper]`. However
when [mega menus were introduced], another css rule prevents having a
gap between the nav and the mega menu (`margin-top: 0;` on
`.o_mega_menu`). This commit makes sure that it will be a `margin-top`
of 0 by making the property more important.
[BS5 commit]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
[mega menus were introduced]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
task-3133137
opw-3226013
X-original-commit: b41c76bd7583756ad059f77f0d3c1151720b0b0b
Part-of: odoo/odoo#118842
This commit allows to reopen submenus and mega menus if one of them was
opened when scrolling on a page of a website.
Steps to reproduce the bug fixed by this commit.
- Have a submenu or a mega menu in the navbar
- Open a dropdown of the navbar
- Scroll down
=> It is no longer possible to open the dropdown.
This commit fixes this issue and adds a test for this flow.
task-3133137
opw-3226013
X-original-commit: 9b1de9e28697edbb6e1fa88665294f983f60e37f
Part-of: odoo/odoo#118842
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
Commit [1] fixed the editor not being able to start when clicking on a
link that triggers a download. This was caused by the
websiteRootInstance being undefined when a page is about to be
unloaded (beforeunload). Unfortunately, this event can be canceled.
This means that the websiteRootInstance had to be undefined when we are
certain that a navigation is going to happen within the iframe. However,
the condition introduced by [1] does not take into account multiple
factors, which lead to the websiteRootInstance being undefined during
edition.
This commit fixes that and introduces a test to make sure this behaviour
is not easily broken again.
Steps to reproduce:
- In edit mode, on the Home page, go in the footer and click on any link
(except "Contact Us") under "Useful Links" or on the house icon in the
Social Media snippet.
- Change the footer height with the Height option.
=> The option is applied correctly (because the link stays on the same
page).
- Click on "Contact Us" or another Social Media icon.
- Try to change the footer height again.
=> The preview works but when we leave it, we see that the option was
not applied.
- Drop a snippet and click on it.
=> Infinite loading.
[1]: https://github.com/odoo/odoo/commit/e47a9900e4a7842774d33a332b325e1f08c3ca45
opw-3196324
task-3212501
closesodoo/odoo#114366
X-original-commit: 15a17656b42442b40f4476efe8c985a9ba28ff93
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Co-authored-by: Soukéina Bojabza <sobo@odoo.com>
Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Click on "Remove all" to remove all the images of the IG snippet.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).
When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.
When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.
To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.
task-3147271
closesodoo/odoo#116352
X-original-commit: 1c99ab2bc04f65999098f70d062d24ed1ac4a9c3
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
Pierre Pulinckx (pipu)