This commit resolves an issue (arose in [1]) where a select field was
displaying IDs instead of labels.
Steps to reproduce:
- Navigate to edit mode
- Drop a form block.
- Select the form action type "create customer" (CRM app must be
installed).
- Add a field for "country".
- Add another field and set its visibility to depend on the country
value.
Issue:
Users are seeing IDs instead of country labels.
[1]: https://github.com/odoo/odoo/commit/a54f11edb1f81c8dade2a4ef6080b666b94e918d
task-3460326
closesodoo/odoo#156190
X-original-commit: 00c9df80fb89e5f50ada256b648a678fe8e0ce15
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Steps to reproduce:
- In website edit mode, have a header with a search icon
('default header').
- Add a few building blocks, enough so that you can scroll.
- Save the page.
- Scroll down until the header is back to fixed on top.
- Click on the search icon.
- Bug: the search bar appears in header (instead of below it, like at
the beginning).
This issue occurs because when the header is fixed and has a 'transform:
translate' property applied, the search modal, which is positioned
absolutely, takes the dimensions of the header instead of those of the
body.
To resolve this, we relocated the '#o_search_modal' element from the
'#header' to '#o_shared_blocks'.
task-3646513
closesodoo/odoo#155703
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
When QWeb templates became cached and compiled in [1], the list of
default cache key elements did not contain `inherit_branding_auto`
(but it included the old `inherit_branding`).
Because of this the cache was shared between restricted editors and
public users, which could lead to problems such as missing the branding
on edited fields.
Steps to reproduce:
- Use a single browser instance and do not log any user out.
- Start with `website_sale`.
- Make "demo" user a restricted editor and a sales administrator.
- Connect on 127.0.0.1 as "demo" and go to a product website page.
- Go to 127.0.0.2 as a visitor and go to the same product page.
=> The product name field of the visitor page was branded.
If you swap the last two steps, the "demo" user's page lacks the
branding.
[1]: https://github.com/odoo/odoo/commit/7ede9bcb2de9d52994b3a6fcb84edc3f81d60284
task-3482439
closesodoo/odoo#156146
X-original-commit: 821888023db462d522c5d6de84fcab80a81c2713
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the commit [1], a new element called "o_header_hide_on_scroll" was
introduced in some header templates. This element has the feature of
gradually decreasing its height as you start scrolling the page until it
completely disappears. To reduce the height of this element without
leaving its contents fully visible (because they maintain their height),
we added an "overflow: hidden" property on it. However, this "overflow:
hidden" introduced a bug fixed by this commit. Due to this, the
dropdowns within the "o_header_hide_on_scroll" element, like "user menu"
dropdown or "language selection" dropdown, became invisible.
Steps to reproduce the bug:
- Go to Website edit mode.
- Click on the header.
- Choose the "Menu - Sales 2" template from the options.
- Select the "Fixed" Scroll Effect from the options.
- Click on the "User Menu" dropdown in the header.
- Bug: The dropdown menu does not appear. The same issue occurs if you
type something in the search bar; the dropdown with the results does not
appear either.
To fix this, we don't apply "overflow: hidden" on the
"o_header_hide_on_scroll" element when the page hasn't been scrolled
yet. And if the page has been scrolled just a bit and the user clicks on
a dropdown or the search bar, we scroll the page to the top first, and
then display the dropdown menu.
This commit also add a test tour to prevent the bug from reappearing.
[1]: https://github.com/odoo/odoo/commit/143d475c3ab8d755906807bda8edb655c6dd22eb
opw-3698887
closesodoo/odoo#154979
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Commit [1] refactored the tabs snippets options, in doing so, it
introduced a selector which could also target a tabs snippet from within
its own tab. This leads to very weird behaviour on clone.
Commit [2] introduced a new MultipleItems abstract option, and with it,
added a selector which could cause the same issue as above.
This commit fixes that by using replacing the selectors to only select
the panes of the parent Tabs snippet.
Steps to reproduce:
- Create a new web page
- Add a "Tabs" block
- Put some text in each tab in other to identify which text belongs to which tab
- In the first tab, add a new "Tabs" block, so that you will have tabs and sub-tabs
- Put some text in sub tabs in order to identify which text belongs to which sub tab
- try to add a new tab in your main tab block
=> look at the beautiful mess it creates.
[1]: https://github.com/odoo/odoo/commit/7572cc150d5469af92138533a024cffbd57d878e
[2]: https://github.com/odoo/odoo/commit/ebfa28638b47a7be45b96d561bdf144c3487f366
opw-3730155
closesodoo/odoo#156023
X-original-commit: 6c72f256691251108ab7a560b38c070a1bcf21f4
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
-User might not know what they going to type in, this commit add a
placeholder in the input of industry selection to give a hint for user
when in website creation
closesodoo/odoo#155862
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the PR [1] changed the rendering engine of qweb, the default
"selected" value set on selects field on the form snippet were lost once
the page is saved.
This commit builds upon the changes made in [this commit] by reinstating
the default "selected" value.
Steps to replicate:
- Go to Website -> Edit.
- Drop a Form snippet onto the page.
- Click on the 'Company' field.
- In Field > Type, opt for "Selection".
- Choose option 3 from the options list to establish it as the default.
- Save the modifications.
Issue: The expected default value for the selection field is not
retained after saving.
[1]: https://github.com/odoo/odoo/pull/130467
[this commit]: https://github.com/odoo/odoo/commit/b42e9cc686e7d3ccf82cd091a5dc24028fff8a2b
task-3767819
closesodoo/odoo#155838
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: base_import, gamification, hr_skills, mass_mailing, portal,
portal_rating, survey, web, web_editor, website, website_sale,
website_slides
The goal of this commit is to improve the accessibility of the website
pages. This has been made by implementing and correcting ARIA
(Accessible Rich Internet Applications) roles and attributes. More
precisely:
- An `aria-label` attribute has been added on progressbar elements to
avoid a warning of type `ARIA progressbar elements do not have
accessible names`. It has also been added on iframes to avoid a warning
of type `<frame> or <iframe> elements do not have a title`. Furthermore,
`aria-label` has been incorporated on some anchors to avoid a warning of
type `Links do not have a discernible name`. Finally, it has been added
on elements that have the `dialog` role to avoid a warning of type
`Elements with role="dialog" or role="alertdialog" do not have
accessible names` and on elements that have the `listbox` role to avoid
a warning of type `ARIA input fields do not have accessible names`.
- To avoid a warning of type `Some ARIA parent roles must contain
specific child roles to perform their intended accessibility functions`,
`role="menuitem"` has been added on children of menu elements. As
explained in [the menuitem role documentation], "The `menuitem` role
indicates the element is an option in a set of choices contained by a
`menu` or `menubar`". To avoid this warning, `role="presentation"` has
also been added on elements located between `tablist` and `tab` and
between `menu` and `menuitem`. Indeed, as explained in
[the presentation role documentation]; "The `presentation` role removes
an element's implicit ARIA semantics from being exposed to the
accessibility tree". The goal is to inform the assistive technologies
that the default semantics of the element should be ignored. Finally, to
avoid this same warning, the `option` role has been added on elements to
identify selections a user can make in a `listbox`.
- The `aria-label` of some elements has been adapted in order to avoid a
warning of type `Elements with visible text labels do not have matching
accessible names`.
- The value of `aria-disabled` has been corrected to `true` (instead of
`disabled`) (see [the aria-disabled documentation]).
Still to improve the accessibility of the website pages, an alternative
text (`alt`) attribute has been provided for images.
[the menuitem role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/menuitem_role
[the presentation role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role
[the aria-disabled documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled#valuesclosesodoo/odoo#140453
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_hr_recruitment
In order to improve the accessibility of the website pages, an
`aria-label` attribute has been added on some social media anchors to
avoid a warning of type `Links do not have a discernible name`. The
`options.js` file has also been adapted in order to correctly set the
`aria-label` attribute of added social media anchors.
Part-of: odoo/odoo#140453
Co-authored-by: qsm-odoo <qsm@odoo.com>
In order to improve the accessibility of the website pages, an
`aria-controls` attribute has been added on `tab` elements of the
"Accordion" snippet to avoid a warning of type `Elements with an ARIA
[role] that require children to contain a specific [role] are missing
some or all of those required children`. Indeed, as explained in
[the tab role documentation]; "An element with the `tab` role should
contain the `aria-controls` property identifying a corresponding
`tabpanel` (that has a `tabpanel` role) by that element's `id`". The
`_createIDs()` method has been adapted in order to handle the update of
the `aria-controls` attribute at the update of the `tabpanel` id.
[the tab role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tab_role#description
Part-of: odoo/odoo#140453
The goal of this commit is to add a default meta description on website
homepage and "contact us" page in order to improve their SEO and avoid a
warning of type `Document does not have a meta description`. Of course,
it is still meant to be overridden.
Part-of: odoo/odoo#140453
The goal of this commit is to add an `aria-label` attribute on the
"extra item" anchor in order to improve the accessibility of the website
pages and avoid a warning of type `Links do not have a discernible
name`. However, as the logic responsible of the creation of this anchor
is in a non lazy loaded file, the translate function `_t()` (located in
a lazy loaded file) can not be used to translate the value of the
`aria-label` attribute. To solve the problem, this value has been put in
the `data-extra-items-toggle-aria-label` attribute on the header. The
translated value is then extracted and added in the `aria-label`
attribute at the extra items button creation.
Part-of: odoo/odoo#140453
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit resolves the accessibility issue where the search field
located within the header was not navigable (see [1]) via keyboard
tabbing, rendering it inaccessible to users relying on keyboard
navigation.
This fix ensures that users can seamlessly navigate to the search field
in the header using the keyboard, thereby enhancing the overall
accessibility and usability of the website.
[1]: https://github.com/odoo/odoo/commit/ac5866a059c345480e246b558eeae1e94aead822
task-3607481
closesodoo/odoo#153197
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Steps to reproduce the bug:
- In Website edit mode, drag & drop a text-image snippet onto the page.
- Click on the image of the snippet.
- In the image options, select "On Hover" for the "Animation" option.
- Click on the "Undo" button in the top bar of the editor panel.
- Bug: The "Animation" option has not been deactivated, the "Hover
Effect" is still present when hovering over the image.
task-3495241
closesodoo/odoo#134979
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
This commit adds the possibility to preview the various effects
available in the "effect" option for 'on hover' animations when hovering
over the dropdown. The sub-options of these effects are also previewed.
This commit also prevents the user from seeing the different changes
that occur to an image with a shape while changing one of its options
(e.g., changing the shape, previewing hover effects).
task-3495241
Part-of: odoo/odoo#134979
This commit makes improvements as requested in the following pull
request [1] ("allowing the ability to flip/rotate image shapes" and
"adding an 'on hover' option for animations").
It mainly focuses on refining the code for better organization.
[1]: https://github.com/odoo/odoo/pull/119197
task-3495241
Part-of: odoo/odoo#134979
Background videos' dimensions are adapted according to the screen size.
This could lead to the video not showing in RTL languages, because the
computed position was coded for LTR languages.
This commit replaces the `left` and `top` CSS properties with logical
properties to account for language directions.
Steps to reproduce:
1. Add a Cover snippet
2. Add a video to it (use any sample videos from the selector)
3. Save > Check mobile view, video shows fine.
4. Add a Right to Left language to the website (Persian, Arabic...)
5. Switch to the RTL language > Check mobile view
=> video doesn't display properly.
opw-3688660
closesodoo/odoo#155478
X-original-commit: e75ff0792376621f5335a5955ce32a54a1a5c441
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This commit prevents the sitemap from being translated when a website is
available in multiple languages. The sitemap should always be in the
default language of the website.
Steps to reproduce the bug:
- Set up a website in English and French
- Navigate to the French version of the website (/fr)
- Access the sitemap (/sitemap.xml)
=> The sitemap appears in French but should be in English.
Note: There is a cache for the sitemap. It is not regenerated if it has
been generated within the last 12 hours (see `SITEMAP_CACHE_TIME`).
task-3743970
closesodoo/odoo#155472
X-original-commit: 809854c5d10735fb280141f5291bdb84d8d36569
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since PR [1], which redesigned the headers, there are now two navbars:
one for the desktop view and one for the mobile view. This also means
that the different menus are in both navbars at the same time. However,
this causes some issues with the mega menus.
Indeed, since each mega menu is in both navbars, the changes made in one
are also made in the other (since it is a field in the database). This
causes issues when drag and dropping:
- Drag and drop a mega menu element.
- Re-drag it and drop it somewhere else.
=> We notice that the element was cloned and each drag and drop adds a
new clone. Moreover, when clicking on a link inside these elements, a
traceback appears.
This happens because since both mega menus are synced, the drag and drop
clones are also synced and so the dragged element is dropped multiple
times (after each clone).
This commit fixes these synchronization issues by adding the mega menus
only once in the DOM, in the desktop navbar. They are then moved from
one navbar to the other when we open them.
[1]: https://github.com/odoo/odoo/pull/119650
task-3609531
opw-3730165
closesodoo/odoo#146492
Related: odoo/design-themes#756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The changes happening in the header often break the history, because a
lot of them add steps in it while they should not be observed at all.
This results in losing the redo history, having to click multiple times
to undo one specific change or even seeing some intermediate states that
should not be appearing, every time we interact with the header (e.g. by
opening/closing a dropdown or a burger menu, resizing or scrolling the
window).
This commit fixes these history issues by not observing some problematic
changes. Note that this commit only fixes the most "annoying" ones (i.e.
the ones that break things) that prevented the other commits of this PR
to work correctly. A second pass will be needed to remove other useless
mutations (i.e. that do not break things but should not be observed
either). This commit will also need to be backported, as these issues
are also present in earlier versions.
Here are the changes that are not observed anymore:
- When we open/close a "burger" menu (i.e. the "Hamburger menu" or in
mobile view). It was adding a step in the history, so if we opened and
closed it in the middle of a redo, we would lose the remaining "redo".
- When the extra menu is added/adapted. When resizing the window, which
also means toggling the mobile view, if there is not enough space for
all the desktop menus to be visible, they are moved in an extra ("+")
menu (they are moved out when there is enough space). This resulted in
the intermediate state where the menus are not in the extra menu yet to
be visible when undoing at some point, which did not look good.
- When hiding a dropdown by scrolling the page and hiding a hoverable
dropdown by clicking somewhere on the page. When they are hidden this
way, undoing the change that will be done after that would reopen the
dropdown, which could be annoying if the dropdown was a mega menu for
example.
- When showing a hoverable dropdown. This added a step in the history,
and since opening a "clickable" dropdown does not do it, this also
should not be the case for a hoverable one.
task-3609531
opw-3730165
Part-of: odoo/odoo#146492
With the headers redesign in PR [1], the "collapse menus" (e.g. in the
"Hamburger menu" and the mobile menu) are now `Offcanvas` elements
instead of `Collapse` elements (see `data-bs-toggle="offcanvas"` in the
headers XML templates). As such, when they are toggled, it is now
`bs.offcanvas` events that are fired, instead of `bs.collapse`.
However, the code using these elements and handling these events has not
been adapted and is therefore never executed, which causes some issues.
1) First issue:
- In edit mode, drop enough snippets to have a scroll bar.
- Toggle the mobile preview and open the menu or resize the screen so it
is smaller than the `SM` screen breakpoint.
- With the menu still open, go back to the desktop view or resize it up
beyond the `SM` breakpoint.
=> There is no scrollbar anymore so we cannot scroll.
This happens because the selectors and event listeners managing the
collapse menus and the scroll do not target the right elements/events.
- On toggle, the `overflow-hidden` class should be added on the body to
prevent the scroll.
- On hide, this class should be removed to re-allow scrolling.
=> Here the scroll is prevented by chance thanks to commit [2] but it is
not the right flow.
- On resize, when the screen becomes bigger than `SM`, the collapse menu
should be closed and the `overflow-hidden` class removed from the body
(see the `_updateHeaderOnResize` function).
=> Not happening because the collapse menu selector is not the right one
and commit [2] does not take the resizing into account.
2) Second issue:
- Change the menu to "Hamburger menu".
- Set the background to a dark color (so that the text is white).
- Set the "Header Position" option to "Over The Content".
- Open the menu.
=> The menu is still considered as transparent so the text is dark on a
dark background, making it difficult to read.
This issue was originally fixed by commit [3], by adding the `o_top_menu
_collapse_shown` class when the menu is opened. It happens again because
since the event is not the right one anymore, the class is never added.
This commit adapts the menus public widgets code in order to consider
these `Offcanvas` elements/events and restore the needed behaviors.
Note that the `NavbarDropdown` public widget (added in commit [4]) is
now useless. Indeed, it was added in order to prevent the dropdowns to
be hidden when opened inside a burger menu, but this issue does not
happen anymore when following the steps. It has already been removed in
master by commit [5].
The same goes for the `TopMenuCollapse` public widget, which was added
in commit [6] to avoid having a scrollbar when opening a sub-menu after
resizing up the screen with the mobile menu open. It is not even started
because its selector is not valid anymore (the `top_menu_collapse` id
only exists in the "Hamburger menu", where the issue cannot happen), and
the issue is not there anymore when following the steps, which makes the
widget useless. It will be removed in master.
[1]: https://github.com/odoo/odoo/pull/119650
[2]: https://github.com/odoo/odoo/commit/f6d9f80e6e8458bdcf75fca9ff3b7e7e54d2a6ba
[3]: https://github.com/odoo/odoo/commit/e10913daf7025accb3b93808ae12ce4a50db1510
[4]: https://github.com/odoo/odoo/commit/ce9b350403ff7c1004b50b39588891ee652e0a3a
[5]: https://github.com/odoo/odoo/commit/39b79832a0cd3e191077a11a485de78365928feb
[6]: https://github.com/odoo/odoo/commit/b7a4538c51aacca666920bdd9496ee575ab12e7a
task-3609531
Part-of: odoo/odoo#146492
*: test_website_modules
In PR [1], the headers have been redesigned. One of their major changes
is that now, they have two navbars: one for the desktop view and one for
the mobile view.
However, the `o_main_nav` and `top_menu` navbar ids are also duplicated,
meaning that there are multiple elements with the same id in the DOM,
which is not a good practice.
This commit fixes this by replacing the ids by classes in the navbar
templates, since their use does not really require for them to be ids
(e.g. `#o_main_nav` is mainly for styling). For the desktop view, the
ids are still kept (for stability purpose).
Note that the CSS rules and the selectors in the JS files (except for
the tests) now take into account both the ids and the classes (to be
safe).
[1]: https://github.com/odoo/odoo/pull/119650
task-3609531
Part-of: odoo/odoo#146492
Commit [1] introduced some code that relied on a cache we currently have
for processed** images. In case of 404, that cache is not filled... and
relying on it thus crashes.
This commit circles around the issue by taking profit of [2] which now
forces `loadImage` to load a placeholder image in case of a 404. This
makes sure that in case of a 404 during the initial call to `loadImage`,
the rest of the stack works with the loaded placeholder image.
**Note: the current cache is not filled at the `loadImage` level, but
later when processing the fetched image. This should be changed in the
future (a task has been created).
See [3] and [4] which are example of unwanted 404 images due to other
issues, which allowed to discover this bug to fix here.
Steps to reproduce:
- Go on the `website.s_picture_default_image` ir.attachment form view
- Change the URL value to a relative path that does not exist
- Go on a website page and edit
- Drop the "Picture" snippet => Crash
=> After this fix, no crash but you can also edit the image if you were
able to click on it, it would use the placeholder image as source.
[1]: https://github.com/odoo/odoo/commit/567e5b58d544e4e56c3a68d148e862a516d77c4f
[2]: https://github.com/odoo/odoo/commit/0639c5028c69d8e29c8438b741cc4713d875b06d
[3]: https://github.com/odoo/odoo/pull/155015
[4]: https://github.com/odoo/design-themes/pull/767
Related to opw-3693055 and others (see [3] and [4]).
closesodoo/odoo#155275
X-original-commit: fbc6a697c1adf67ee8a90c49b0150d6ca170e081
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit [1] introduced default images changes for the website library.
The problem is that the ir.attachment definitions are in a non-updatable
environment by mistake (apparently since forever)... so they are not
updated after update/upgrade.
This commit moves the definitions to its own updatable file, in 17.0 and
above only (ignoring potential other changes that were made in 15.0/16.0
at the time but apparently led to no issue). But this is not enough:
upgraded users will still have those ir.attachment records marked as non
updatable and will thus not be updated. Meaning that the ir.attachment
record will still reference path to images that do not exist anymore
(since [1]) and thus not display anything in related snippets, or worse:
crash on some non-robust-to-404-images options (This will be made more
robust in another update).
Note that, at the moment, we cannot solve this issue by making the
/web/image route not return a 404 but a placeholder image in that case,
for technical reasons (even though it would be consistent as this is
what is done if you try to reach `/web/image/something_with_a_typo`).
It would also be annoying to solve this problem by adding a migration
script inside the Odoo repo itself:
- It would only work if upgraded users do a -u again (unlikely).
- That would mean an upgrade script rotting in the main repo forever.
Instead, this commit chose to restore the removed images so that
upgraded users will be able to use the outdated paths. In master, an
upgrade script will be made (in the upgrade repo) to properly update all
those attachment records and be able to finally remove those outdated
images. Note that this may also be fixed without upgrade script if
non-updatable records whose XML declaration is moved out a non-updatable
area become updatable (under discussion with the framework team... we
will see when this lands in master).
Steps to reproduce:
- Install a 16.0 with the website module
- Upgrade to 17.0
- Drag a "Blockquote" snippet on a page
=> Crash and the image is missing (in the DOM but invisible and
impossible to edit). Note that the crash itself will also be fixed by
the later update that will be done to make editor options more robust
to 404 images.
[1]: https://github.com/odoo/odoo/commit/a4377bfa85b19be29a430573e0f42fff4da52757
opw-3693055
opw-3723895
opw-3744257
opw-3747348
opw-3749764
...
closesodoo/odoo#155015
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when the mega menu were first introduced, to make their
edition possible, the bootstrap dropdown behavior was neutralized by
removing the `data-[bs-]toggle` attribute.
In [2] when Bootstrap was upgraded to version 5.1.3, the
`dataApiKeydownHandler` event handler that is called when up, down or
escape are pressed raises an error if `data-bs-toggle` cannot be found
on a previous sibling of the dropdown. This makes the approach chosen
in [1] incomplete.
This commit avoids this issue by temporarily adding a class that
is excluded from the event handler selector.
The patch must unfortunately be applied within bootstrap itself because
the event handler is registered right after the method is defined and
we have no way to access the registered event handlers afterwards.
This makes it impossible to patch the called method from outside, nor
its associated selector.
We cannot simply update the selector that was already patched by [3]
because it is also used by other methods.
A test is included which should mitigate the risk of accidentally losing
this patch upon bootstrap upgrades.
Steps to reproduce:
- Create a mega menu.
- Edit the page.
- Open the mega menu.
- Click inside the mega menu content to have a cursor selection.
- Press the arrow up key, the arrow down key or the escape key.
=> An error dialog was displayed.
The same issue happened with a nested menu instead of a mega menu.
[1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
[2]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[3]: https://github.com/odoo/odoo/commit/daca8fe4e3da4a5ad5fabf3730496a3919af8abc
task-3614926
opw-3741670
closesodoo/odoo#155019
X-original-commit: 48f0c4203ceb5e770fed6193bd6382690b1b62fe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
Note: this commit was not needed in previous version.
runbot-57204
closesodoo/odoo#154679
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
Note: this commit was not needed in previous version.
runbot-57204
Part-of: odoo/odoo#154679
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
Note: this commit was not needed in previous version.
runbot-57204
Part-of: odoo/odoo#154679
See parent commit for more details. This commit disables the remaining
problematic step in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.
Of course, a solution will have to be found to re-enable that step.
runbot-57204
X-original-commit: 60b2b182473beaa4e338d8345f8aa4a5984336dd
Part-of: odoo/odoo#154679
The test `test_15_website_link_tools` associated with the 'link_tools'
tour has been problematic for a long time. Many fixes have been made
already, mainly [1] but also [2], etc.
As of today, the test now succeeds 100% of the time in 16.2 and below.
Starting from 16.3, the tests still contains race conditions. As a first
step towards fixing those, we will first disable the problematic steps
so that we can re-enable the test on runbot. First, this commit is about
unifying the 16.3 version of the tour with the previous versions (16.2).
Indeed, while the test currently tests the same things as 16.2, for no
apparent reason (see [3] and others):
- Some phases of the test were reordered during the forward-port that
introduced them.
- A new "Popover should be shown" step was added during some
forward-port (it is actually one that is the cause of a race
condition, see below).
- 16.4 and above: many new steps which save/re-enter edit mode were
added, random clicks were added, trigger were changed, check were
rewritten for no reason, etc... none changed the race condition rate
(if anything, it worsened in 16.4, see below).
- 17.0 above: some useful steps were added and do not seem to impact the
success rate, this commit of course keeps them.
This commit thus:
- Reorders the steps the same way as 16.2.
- Temporarily disables the problematic new step.
- Removes all those useless changes.
Here are some tests made in all those versions (before this commit):
=> 16.2 and below:
- Tested: 100% working
=> 16.3:
- Tested: 162
- Failed: 88
- 57 on "Check popover content is up-to-date"
- 31 on "Popover should be shown"
=> 16.4:
- Tested: 30
- Failed: 28
- 24 on "Check popover content is up-to-date"
- 4 on "Popover should be shown"
=> 17.0:
- Tested: 80
- Failed: 80
- 69 on "Check popover content is up-to-date"
- 10 on "Popover should be shown"
- 1 on "Check that links's href was updated"
=> 17.1:
- Tested: 83
- Failed: 83
- 64 on "Check popover content is up-to-date"
- 17 on "Popover should be shown"
- 2 on "Check that links's href was updated"
=> master:
- Tested: 37
- Failed: 37
- 26 on "Check popover content is up-to-date"
- 11 on "Popover should be shown"
Note that this commit actually seems to reduce the race conditions...
which is of course not a solution on its own. The next commit will
disable the problematic steps to have the test pass 100% of the time,
until a real solution is found.
=> Tests with this commit:
- Tested: 11
- Failed: 4
- 4 on "Check popover content is up-to-date"
[1]: https://github.com/odoo/odoo/commit/da9afc46e32111afbe0f4bdae6d539795239290a
[2]: https://github.com/odoo/odoo/commit/06f9a21c60b4bf7d375bdaba3fd4c8bc89d16b54
[3]: https://github.com/odoo/odoo/commit/9fc283b514d420fdfd66123845d9ec3563572692
runbot-57204
X-original-commit: 155bfd45b0678d69ed34d4e832df5a331a91a551
Part-of: odoo/odoo#154679
Since commit [1], there is no outline when focusing a hoverable dropdown
by using the Tab key. This happens because of a CSS rule that was added
so no outline would appear when hovering the dropdown menus with the
mouse. However, it should still be displayed when using the keyboard,
for accessibility reasons.
This commit fixes that by always allowing the focus on the hoverable
dropdowns, except when they are hovered. If a focus was present on an
element in the document when hovering, its focus is kept (to have the
same behavior as in previous versions).
Steps to reproduce:
- Add a submenu and a mega menu with the menu editor.
- In edit mode, set the dropdowns as hoverable (set the "Sub Menus"
option to "On Hover") and save.
- Use the Tab key to navigate through the menus.
=> The simple menus have an outline but this is not the case for the
dropdowns.
[1]: https://github.com/odoo/odoo/commit/5846a05fe7bf587d3bfb3ace3e863cb4abd52132
task-3709755
closesodoo/odoo#154505
X-original-commit: a8b3e589cd7e6c9ecfd33ba4ae9883e7ade2e599
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Before this commit, `.bg-view` was set to `.o_notification`. This was
creating an issue in the front-end where `.bg-view` doesn't exist,
making the background of the notification transparent and ultimately
causing readability issues. Issue introduced in [1].
This commit changes the way we apply the background from a utility
class approach to a SCSS approach. That way, we can easily override
in `website.scss` with the `$body-color` of the website.
task-3716367
[1] 4e1f0b8ea522accae4860937c2fb3815281e8483
closesodoo/odoo#154081
X-original-commit: f8f8d2905db633cfaaa93b6cd163f4ab55dc4c8f
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce:
- Go to Website > Add menu items in a way that activates “auto-hide” (to
set the overflowing menu items in a “+” dropdown) if the viewport was
resized.
- Go to “edit” mode (adding the sidebar reduces the current window
width) > The “auto-hide” menu adaptation is disabled, and overflowing
menu items are still visible.
On [15.0 - 16.4]:
The original commit fixed the behavior described above by preventing the
unbreakable mechanism from detecting header changes and canceling the
auto-hide updates (see: [X-original-commit]).
In addition to the main fix, some other changes were also added to allow
correct editing of extra menu items [1]:
- The `_adapt()` debounce was replaced by a throttle that applies the
first menu adaptation immediately.
- We remember the state of the extra menu dropdown (open or not) if it
is there, which will be restored after the menu adaptation.
- When clicking inside an extra menu item, The extra menu is closed. We
prevent this default behaviour in "edit" mode.
Starting from 17.0:
The code from [2] fixed the same editor's rollback issue by using a
`withoutRollback()` to ensure that the `_adapt()` is called without
triggering any rollback.
This commit will only forward-port the adaptations from [1] since the
rollback issue was fixed using the new `withoutRollback()` tool.
[2]: https://github.com/odoo/odoo/commit/cbed990924887eb529056d89a042a92ba27b825b
Related to opw-3484742
closesodoo/odoo#153566
X-original-commit: 4713f95f18d7326b553464c0be6fdcd68b330292
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Add an "Image Gallery" on the website.
- Add a new image on the snippet.
-> Problem: the thumbnail of the first image of the carousel has been
replaced by the new added image.
To solve the problem, the triggering of the `image_changed` event has
been removed on extra image added. It was introduced by [1] to trigger
the re-rendering of the thumbnail when adding a new image on the
carousel but was actually useless. Indeed, the mechanism was the same as
now; when a new image was added on the carousel, the
`website.gallery.slideshow` that already handles the thumbnails was
re-rendered. An important thing to note is that the system was also
never intercepting this `image_changed` event as it was triggered on an
element that was not in the DOM (as it was removed at the
`_replaceContent()` call in the `slideshow()` method). However, since
[2], the images rendered by the `website.gallery.slideshow` are replaced
by the images (or the wrapped anchored images) returned by
`_getImgHolderEls`. Therefore, `$newImageToSelect` is part of the DOM
and the `image_changed` event is intercepted by the gallery option. As
the active carousel item is always the first one of the carousel after a
`website.gallery.slideshow` re-rendering, the system changed the
thumbnail of the first item with the new added image.
[1]: https://github.com/odoo/odoo/commit/85990768592cbdefbb178b5ffa38c1e29b9eeb87
[2]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481
task-3736301
closesodoo/odoo#153717
X-original-commit: 3c4239212e7bedc3cb49f34d9eb0a23c3de0cbd6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
In b69917e[1] the cron implementation was changed to unlink old visitors in
batches of 1000 records. This was meant to deal with memory/timeout
errors when dealing with large amounts of records.
However it still searches for records with no limit, which in high
record count scenarios and based on instance resources may still
generate memory/timeout errors.
Technically it could be considered "fine" for the cron to timeout since
every batch is committed, so previously unlinked records are not rolled
back and the cron should eventually delete them all.
However there are some edge cases where memory/time out errors would not
be fine, like the cron failing during the first batch, which means no
unlink operations would be committed to the database.
Errors that are "fine" also generate noise and leave administrators
wondering which errors they should ignore and which they should not. It
also alarms non-technical customers since after all, they are seeing
a reported error.
Therefore the search limit and batch size have been added as arguments
to the cron. This is completely opt-in since they have the previous
values as their defaults. This makes it easy to customize and tune the
performance of the job accordingly if required.
[1] https://github.com/odoo/odoo/commit/b69917ec0e508f8354d831525c5c48ee79b5967a
X-original-commit: e8a4b1f6a239753f66aa827e8e0d67ca4270dba3
Part-of: odoo/odoo#153707
Since the introduction of the Embed Code snippet with [1], in case some
content was created dynamically through a `<script>` tag, it would be
duplicated upon editing the snippet again after it had been displayed a
1st time. This is because each time you open the snippet's ace editor,
the current state of the snippet (including dynamically created
elements) is saved in the view.
This commit removes the `<script>`s inside embed code snippets from the
view in edit mode, and then saves them on the server upon save.
We also take the opportunity to add a message in edit mode if the
snippet doesn't display anything (e.g. if it only contains a script tag,
or an empty element), so that it is easily focusable to edit its
content.
Finally, we add a message upon editing an embed code snippet to inform
the user that they should not use it unless they know what they're doing
as well as tell them they may inject code in the `<head>` or `<body>`
elements through the Theme panel.
Note: this fix is only valid for code injected inside the embed code
snippet. For code injected outside of the snippet, we have no way of
controlling / sanitizing the DOM after the fact.
Steps to reproduce:
1. Drag and drop an Embed Code Snippet
2. Copy the following code:
```
<script>
document.addEventListener('DOMContentLoaded', function () {
const alertEl = document.createElement('div');
alertEl.classList.add('alert', 'alert-primary');
alertEl.textContent = "Hello";
document.getElementById('some-stuff').appendChild(alertEl);
});
</script>
<div id="some-stuff"></div>
```
3. Save and exit the editor. The injected div should appear.
4. Go back to the editor, click to edit the snippet and either save or
discard.
5. Exit the editor
=> The div is duplicated.
[1]: https://github.com/odoo/odoo/commit/2cc481d1a62202ade4c1ca8f846c962f9f2cc34d
opw-3513760
closesodoo/odoo#152502
X-original-commit: e6fe14dc90af6782693fd5e9dca6f18ecfe7c89a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In order to not add steps in the history when changing the slides of a
carousel, commit [1] added listeners that would deactivate the observer
when sliding and reactivate it when the slide is over, in the `slider`
public widget. These listeners are then removed at destroy.
However, the way they are removed breaks some of the carousel behaviors:
- Drop a "Carousel" snippet.
- Change any "Carousel" option (so not a "Slide" one). For example, set
the "Height" to 50% or add a conditional visibility.
- Slide the carousel (with any arrow).
=> The slide number did not update correctly.
- Remove a slide with the "-" button.
=> The slide was not removed.
It happens because, when this widget is destroyed, it removes all the
`.carousel` listeners, which means that it also removes the listeners
added at the `Carousel` options start. And since the widget is destroyed
and restarted every time an option is changed, but the "Carousel"
options are started only once at the beginning, the removed listeners
are never added back (until the next start of the options).
This commit adds an id to the events managing the sliding history, to
make them more specific, in order to only remove these ones when the
widget is destroyed.
[1]: https://github.com/odoo/odoo/commit/14bc1a9bd1ebdec3b73e268450267320b79d01cd
opw-3675019
closesodoo/odoo#153578
X-original-commit: 041935aff660ae5df1220e3d844d2a2cbcf4ee5c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Google has removed the feature that allowed sitemap submissions. Now,
it's standard practice for Google to crawl the /sitemap.xml. This commit
permits to show a notification message when the user clicks on the
button to submit a sitemap.
task-3323849
closesodoo/odoo#152700
X-original-commit: fb842f682bb8b2600d861a5e0bb92503857bd2de
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This shouldn't change anything regarding SEO, but is worth a try.
It will also impact the link suggestion when creating a link in the
editor, but having pages listed first also have sense there, or at least
it won't be worst.
The idea for the SEO part is that if the sitemap order (if too long)
would have some impact as crawlers might have a limited crawling budget
for your website and it will only crawl the first pages it finds.
Are those "first pages" impacted by the sitemap order? It's almost sure
it's not, as Google definitely knows how to crawl on its own, and is
even probably ignoring the sitemap most of the time.
Also, pages:
- Are probably always important content since you created manually a page to
write something, while (some) controllers might just be content you
care less about. Pages are probably always important while we can't
say that for controllers.
- Should be fewer in number than controllers most of the time
- Have a lastmod set, as opposed to controllers
- May be created at any time, meaning a new crawler visit is needed,
while controllers are almost never added in production, installing a
new module is something very rare. Exception is about record's
controllers which are "created" at any time like pages (eg a new
product controller page)
For all those reasons, this commit reverse the pages vs controllers
order in the sitemap.
This is coming from our prod where some pages are yet not indexed while
they have been published months ago.
closesodoo/odoo#152350
Signed-off-by: Jérémy Kersten <jke@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
Steps to reproduce the bug:
- Enter edit mode.
- Click on the "Theme" tab in the options panel.
- Click on "Add a Google Font" in the "Font Family" select.
- Paste the address of a font page in the input.
- Disable the "Serve font from Google servers" toggle.
- Save the dialog.
- After the reload, click on the "Theme" tab.
- Open the "Font Family" select.
- Click on the "Remove" button for the recently added font.
- Confirm your choice to close the dialog.
- After the reload, click on the "Theme" tab.
- Open the "Font Family" select.
- Bug: the font has not been removed.
This bug appeared with commit [1]. With the transition to the Owl
render engine, the 'true' value passed as a parameter in the
'delete_google_font_btn' template, defining whether a font is local,
wasn't being set as the attribute value in the template.
In this Owl context, 'true' indicates the attribute's presence, not its
value. To address this, we replaced the boolean 'true' with the string
'"true"' to ensure the parameter value is correctly passed to the
template.
[1]: https://github.com/odoo/odoo/commit/f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b
task-3714768
closesodoo/odoo#152715
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Add an "Images Wall" snippet on the website.
- Add a link on the first image.
- Add a new image on the wall.
-> Problem: the first image does not have a link anymore.
When adding an image or reordering the images on a wall, the system
re-renders the snippet (see `nomode()`, `masonry()`, `grid()`) by adding
each images on the wall structure. The problem is that the system only
takes the images into account and not a possible image wrapped into an
anchor. This is now fixed as the system renders the images or the
wrapped anchored images returned by `_getImgHolderEls`.
The process is a bit different when adding an image or reordering the
images of an "Image Gallery" snippet. In this case, the system
re-renders the `website.gallery.slideshow` template. The problem here is
double: First, the template does not take a possible wrapped anchored
image into account. Second, there are only few image attributes that are
rendered by the template.
This leads to a new problem:
- Add an "Image Gallery" snippet on the website.
- Add a "Blur" filter on the first image.
- Click on "move to next" to move the first image at the second
position.
-> Problem: the image option does not show the filter and it is now
impossible to change some image options such as "Filter", "Shape" and
"Quality".
To solve those two problems**, the images rendered by the
`website.gallery.slideshow` template are replaced by the images (or the
wrapped anchored images) returned by `_getImgHolderEls`. By doing so,
the rendered images have the correct attributes (so the options can be
correctly displayed and modified) and they are still correctly anchored.
This commit also adapts the `snippet_images_wall` test. An extra trigger
had to be added on the `Select footer` step to ensure that the last
image of the wall has been inserted before clicking on the footer.
Without it, the tour fails as, if the moved image is in the first
position, the tour only waits for this image to be inserted in the wall
and then clicks on the footer. When the wall is completely built, the
focus is automatically done on the moved image and the step
`selectSignImageStep` fails to execute as its `extra_trigger` condition
(`.o_we_customize_panel:not(:has(.snippet-option-gallery_img))`) is not
met.
**: In this 16.4 forward-port, the second problem is not entirely fixed.
The task-3717041 will handle it.
opw-3535829
opw-3573135
closesodoo/odoo#152365
X-original-commit: e73a1a96dcf8786c01205ae0a97b10e38ab9afeb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue:
Possible to reproduce in 17.0: when adding a new field to the website
form of the "Extra Info" page in the eCommerce, a traceback is raised
(`OwlError: Missing template: "website.form_field_json"`) when the user
selects "Delivery Point Address" (`sale.order.access_point_address`).
Explanation:
JSON fields (which exist since [1]) are not supported as selectable
types in website forms, and they should not be because customers would
not be able to properly fill them out.
Fix:
Filter out all JSON fields from the list of authorized fields in website
forms; they will not appear in the list of selectable types anymore.
[1]: https://github.com/odoo/odoo/commit/7eeba9d205d2dace571b5d0895ddba6290a512db
opw-3596713
closesodoo/odoo#152545
X-original-commit: 28c3eb5878ad6f3d40a096803f3ba4aef5ef7937
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Serge Bayet (seba)