Since commit [1], the "tempusdominus" date(time) picker has been
replaced by the OWL date(time) picker. A traceback appears when loading
a website form containing a field dependent on a date(time) field.
This traceback occurs because when checking the value of an empty
date(time) field (which happens when the user hasn't yet filled out the
form), we parse the field value into a Date(Time).
Before the changes in commit [1], we parsed this differently, which
didn't crash but returned "NaN" with an empty date(time) field.
In this commit, we now check whether a date(time) is valid and if not,
we now assign it "NaN" to maintain exactly the same behaviour as before
the commit [1]. Any value other than "NaN" would not work with the date
comparison system and would break certain conditions.
This commit also adds steps to the "website_form_editor" test tour so
that it fails without this commit.
[1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
task-3790809
closesodoo/odoo#158288
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Since commit [1], the "tempusdominus" date(time) picker has been
replaced by the OWL date(time) picker. This change resulted in a
modification of the HTML structure for date(time) input fields.
Consequently, a bug emerged in the visibility options for fields reliant
on a date(time) field. Specifically, the time condition selector failed
to display the time conditions because they are rendered based on the
HTML structure of the fields.
Since the code was not adjusted to fit the new structure, this
functionality stopped functioning.
[1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
task-3790809
Part-of: odoo/odoo#158288
When using the "ConditionalVisibility/DeviceVisibility" option for
blocks that are inside a popup, you can end up with an empty popup.
This was has been a limitation of those options for a while, but there
is a real use case for hiding a popup under certain circumstances.
Adapting the options to work on popup was complex enough that it does
not seem suitable for a stable version.
But a simple solution that tries to break as little as possible existing
code could be a huge benefit.
This commit makes it so that if the all children of the .oe_structure
are currently being hidden by ConditionalVisibility selectors or by
DeviceVisibility classes, the popup will not be shown to the visitor.
It will still show if content is being hidden by other means, either
with customizations, or if the content is dynamically generated (like in
the case of a Dynamic Snippet).
This change is done starting saas-16.3 as this is the version the OPW
was opened with, and since this is still a significant change, it will
limit the impacted versions.
opw-3734501
task-3128349
closesodoo/odoo#158303
X-original-commit: 3f5e3c4d49d4c0f67b548d22846e27c5ff8c73f1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
*: web_editor, website
Commit [1] introduced new image settings for the product page.
When those settings were introduced, the editor was reloaded after the
RPC to properly reflect when the settings were changed. While this was
done, a data-reload was also added in the XML template of the options.
This was not necessary as the data-reload only works for some methods
which are not used in the image settings. Therefore, the data-reload
did nothing.
However, with commit [2], the settings were moved and combined with
page options. So the image settings automatically inherited the page
options behavior, which is to save and reload the page when a method
with data-reload is called. This caused the editor to ask for a reload
twice.
This could cause the page to reload before the RPC was finished:
- Add a 10 seconds sleep at the start of /shop/config/website controller
- Go to products page
- Enter edit mode
- Change the number of products per row
=> Nothing happens
Indeed, the page is reloaded immediately, before the 10 seconds rpc is
actually done.
This is also needed by the conversion of the SnippetsMenu to OWL:
It seems like the race condition introduces a traceback.
This commit fixes the issue by ignoring any save request from an option
that will reload anyway. It also awaits the RPC to finish before
reloading the page.
[1]: https://github.com/odoo/odoo/commit/54c6d36cfbea31fe60b888bbb903b0c6f22216b3
[2]: https://github.com/odoo/odoo/commit/b274cf2427951761e59eb357fb796b54be375507#diff-754f6c793d6a168d006d2a9da108142b889036031ac1a2e62060c225d060f858closesodoo/odoo#158468
X-original-commit: 556ae457b02e9c077d09fa9c3f9f1e6c6e26b345
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Go to website in "Edit" mode (on a blog post page).
- Select one of the default images in the blog content.
- Click on the "Animation" option and select "On Hover" > Traceback!
Starting from [1], the "On hover" image animation was implemented to be
able to pick an animation that triggers when hovering an image.
This feature is setting a default "Square" shape (required for the
hover effects to work) on the target. Which means that an error can
always occur if the "On Hover" animation option is available while the
targeted image is not linked to an attachment and can't support image
shapes (which is the case here).
The goal of this commit is to fix this issue by only allowing the
"On Hover" animations when it's possible to apply shapes to the image.
[1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
opw-3795599
closesodoo/odoo#158433
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit introduces an update to the Font Awesome library,
specifically replacing the X/Twitter icon with its new design. It also
involves adjustments to a few images and SVG files to incorporate the
updated X/Twitter logo.
Technical note: It updates an existing file, originally modified for the
addition of the TikTok icon, which was not available in Font Awesome 4.
task-3463530
closesodoo/odoo#158586
X-original-commit: 34cba04a452f2da21f3418d6fc48a484da8ecd27
Related: odoo/enterprise#59147
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Those are optional, commit [1] mimicked the python code in JS but with a
mistake: "required" instead of "optional".
Steps to reproduce:
- Enable cookies setting on website
- Drag & drop a snippet
- Modify that snippet conditional visibility to "Utm Campaign: Sale"
- Visit in incognito /?utm_campaign=Sale, you don't see the snippet,
which is good
- Now click on "Only Essentials" in the cookies banner
- The snippet will be shown, because when accepting the essentials
cookies, the utm ones were set, since they were marked as required.
[1]: https://github.com/odoo/odoo/commit/90ada07ecfc308ad181748d3e809810bb90f3eecclosesodoo/odoo#158720
X-original-commit: 63b0606d728be949cc6cfcb0dbdf17114ec1c711
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Before this commit, the header was considered as mobile at the `SM`
screen breakpoint, while it is already displayed as in mobile view at
`MD`. This made some of the header behaviors inconsistent and caused
some issues:
1) A menu open at `MD` is not closed when resizing the screen:
- Resize the screen at `MD` and open the menu.
- Resize the screen above `LG`.
- Resize back at `MD`.
=> The menu was not closed. It is when we start resizing at `SM`, which
is inconsistent as they are both displayed like in mobile view.
2) Because of the first issue, we cannot scroll the page anymore after
opening the menu at `MD`:
- In edit mode, drop enough snippets to have a scrollbar and then save.
- Resize the screen at `MD` and open the menu.
- Resize the screen above `LG`.
=> There is no scrollbar anymore and we cannot scroll.
This happens since PR [1], which redesigned the headers and changed the
"hambuger" menus so they open on the side (= offcanvas), and commit [2]
that prevented the `#wrapwrap` to scroll when these menus are open, to
prevent a bug on Safari. The issue happens because since the menu does
not close when resized, the class preventing the `#wrapwrap` to scroll
is never removed.
3) The menus are hoverable at `MD` but not at `SM`:
- Add sub-menus and mega menus with the menu editor.
- In edit mode, set the menus as hoverable (set the "Sub Menus" option
to "On Hover") and save.
- Hover the menus:
- above `LG` (= desktop view) => they open.
- under `SM` (= mobile view) => they do not open because we need to
click to open them on mobile view.
- between `SM` and `LG` => they open even though it is displayed like
in mobile view, so the behaviors are inconsistent.
4) Because of the third issue, there is sometimes a traceback when
hovering mega menus if the screen is at `MD`:
- Resize the screen at `MD`.
- Refresh.
- Open the menu and hover a mega menu dropdown.
=> There is a traceback sometimes.
Since commit [3], in order to avoid mega menu synchronization issues
between the desktop and mobile headers, the mega menus are not
duplicated anymore and they are moved from one navbar to the other when
opening them, so when hovering them if the menus are hoverable. A race
condition can happen in that case because the `hoverableDropdown` widget
tries to open the mega menu before the menu has been moved in its
dropdown, which causes a traceback. This seems to happen only when the
widgets start with the screen at `MD`, therefore, preventing the menus
to open on hover under `LG` prevents this race condition.
This commit considers the header as mobile under the `LG` screen
breakpoint, to fix these issues and to uniformize the behaviors of the
mobile header.
[1]: https://github.com/odoo/odoo/pull/119650
[2]: https://github.com/odoo/odoo/commit/f6d9f80e6e8458bdcf75fca9ff3b7e7e54d2a6ba
[3]: https://github.com/odoo/odoo/commit/389856bcd94d459d72f46c2a517afb3f6d976e38
task-3801970
closesodoo/odoo#158571
X-original-commit: 4d3c86cb33c12f0e7bbc7812452feb33ddfa8321
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Commit [1] made it possible to stay in the backend while refreshing the
page with F5 or CTRL+R when viewing a Website Preview. Pressing it too
fast when the page is still loading and the iframe isn't loaded yet
triggers a traceback.
This commit falls back to the default refresh in such cases.
[1]: https://github.com/odoo/odoo/commit/e69c6eaed4e82e08d6bbf807cf4698f6327a9cdd
task-3795143
closesodoo/odoo#158314
X-original-commit: c81dfa7dda95a8d63b4abba9ce67d7f3e48af935
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Since [1] when the social share widget was introduced, a hashtag is
generated from the name of the website that is found inside the page
title.
This fails when the page title is replaced through the SEO feature.
This commit prevents the failure but not extracting the website name if
it is missing from the title.
Note that the `registry.socialShare` fixed here is only used by the
forum post page in the whole codebase. It is different from the social
snippet. The social snippet is doing the same code (kind of duplicate),
but it does not care about removing the | right part. It means that if
you drag & drop the "Share" snippet in a forum post page (like in the
footer) and click on it, it will work since it does not try to split on
the title's pipe.
In master, we will evaluate if we should remove this
`registry.socialShare` and use the `Share` snippet instead.
Steps to reproduce:
- Install website_forum.
- Go to a forum post.
- Set SEO title to a value without `|` (pipe).
- Share to X.
=> An error popup was shown.
[1]: https://github.com/odoo/odoo/commit/1c91e27c8c8cb7492d26f03e27c4991b53a1675d
opw-3799914
closesodoo/odoo#158478
X-original-commit: f89f4a8f1ad0ee3fb62ba246ea17988955dbdc4b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: crm, digest, hr_expense, im_livechat, mrp, purchase, sale_management,
website
The images in the digest email are updated to have the look of the new
"Milk" Ui. We want to keep names unique, as they target different
versions. That way we can keep a v15 oriented gif for people using tips
in v15 for example.
The mobile phone image is hosted on odoo.com.
task-3338467
X-original-commit: odoo/odoo@3711d2b61b
Part-of: odoo/odoo#158351
Steps to reproduce:
- Enter in edit mode.
- Select the 'Header' menu.
- Switch the default template to 'Rounded box menu'.
- Select again the 'Header' menu and on the 'Navbar' details, update the
format value (i.e: 10px) and save.
-> Problem: some buttons are not affected by the change of the format
value.
The problem is that since [1], those buttons have the `rounded-circle`
class so their font size is not the custom one (but it is the value of
`$font-size-base` instead). To solve the problem, the css rule has been
adapted in order to force the font size of the buttons inside the header
to the custom value if it exists.
[1]: https://github.com/odoo/odoo/commit/e3e9c492e0d1e009a0c459a1dc591e122b4b65d3
opw-3810794
closesodoo/odoo#158135
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] when the "Padding (Y, X)" option was added, form elements are
recognized as columns because they match the `.row > div` selector of
that new option.
This commit excludes those form elements from this option's selector.
Steps to reproduce:
- Drop a website form.
- Click on field's input.
=> An empty "Column" editor appeared in the side panel, and an error
occurred when trying to delete it.
[1]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712
task-3748574
closesodoo/odoo#157572
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Starting from The "unbreakable menu fix" on `16.0` (see: [1]), the state
of the website extra menu was stored before every "resize" adaptation,
so it can be possible to reopen it if it was already opened.
On `17.0`, the same behaviour was fixed using the `odooEditor` >
`withoutRollback()` mechanism (see: [2]), and a step was added to the
`edit_menus` test (`clickOnExtraMenuItem`) to open the extra menu after
the "edit mode resize" [3].
The forward port of [1], on `17.0` was adapted to keep the main fix from
[2], and removed the tour step since the extra menu will be
automatically opened if it was already open before the "resize".
Now, if we have a menu with no overflowing items before the resize, and
after switching to "edit" mode an extra menu was added, this menu will
be closed by default which makes the test fail without the step in [3].
The goal of this commit is to fix this behaviour by simply restoring the
`clickOnExtraMenuItem` step with a simple tweak: We don't click if the
extra menu is already opened to prevent closing it again.
Remark: the test failed on `17.0` but the commit is targeting `16.0` to
prevent any test failure linked to the "extra menu auto open" feature.
[1]: https://github.com/odoo/odoo/commit/2598cc9ef7fe89a0ce5e375bca6f6a781f6ffdf7
[2]: https://github.com/odoo/odoo/commit/cbed990924887eb529056d89a042a92ba27b825b
Related to opw-3484742
Related to task-3439226
closesodoo/odoo#157290
X-original-commit: 42bcc3ef284ca355e2323641176573b53e7d2e28
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Steps to reproduce [17.0+]:
- Create a website form of any type in which you have:
- One "Name" or other text field.
- One field with the "Date" type.
- One field "Email" with the visibility condition: "Only visible if"
a field of type "Date" "Is set".
- When you complete the "Date" field, the "Email" one should show but it
does not > It shows if you also add at least two characters to the text
field.
Starting from [1], an OWL date picker component was introduced mainly to
replace the use of `TempusDominus` and `DateRangePicker` libraries.
After this change, an adaptation (from [2]) was done to completely
replace every usage of `TempusDominus` with the new OWL component
(including the form date[time]picker fields).
One of the lost features from `TempusDominus` was the trigger of an
"input" event on date [time] change, which also triggers the form field
visibility check.
The goal of this commit is to fix this behaviour by simply updating
fields visibility on every component value change.
[1]: https://github.com/odoo/odoo/commit/b5794e89e1ad29e2a86c7ddaf241e3fc24654b5f
[2]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
opw-3778129
closesodoo/odoo#157328
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Go to website > Switch the navbar to "Hover" mode (see: `Submenus` >
`On Hover`).
- Create a submenu and drag it under a navbar menu item > The submenu
will always disappear before being reached after the hover.
Since Bootstrap does not provide a built-in way to use the "hover" as a
dropdown trigger, a custom implementation was used to handle the "show
on hover" scenario (see: `hoverableDropdown`). This code also relies on
the submenus being correctly positioned on hover.
Starting from [1], the public `menuDirection` widget was completely
removed (used to align website navbar submenus in an optimal way) and
was replaced by a patch that allows Bootstrap to position dropdowns
dynamically inside a navbar (using Popper).
A side effect of this patch is the use of BS default offset config to
set the positions, leading to a small gap that automatically hides the
submenus when hovered.
The goal of this commit is to prevent this issue by simply forcing
the offset to 0 when the dropdowns are inside a "hover mode" navbar.
[1]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914
opw-3766516
closesodoo/odoo#157804
X-original-commit: d52936f7bd396f370a2a09a699ab1e0c655eb020
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Current behavior:
When the cookie bar is activated, the optional cookies are deactivated
by default, unless you click on I agree.
This causes issues regarding UTMs:
- You can have blocks to show only if an UTM cookies has been set
- UTM should be added on sale order for instance when reaching the
website through a link with an UTM and then buying something
Steps to reproduce (utm on quotation):
1. Install ecommerce
2. Go to Settings/Website
3. Activate Cookies Bar
4. Open a private tab
5. Go to /shop?utm_campaign=Sale
6. Click on I agree on the cookie bar
7. Buy a product
8. Go back to Sales App in backend
9. Find the last public user quotation
10. Go to other info tab
11. The medium field is empty
Steps to reproduce (utm based visibility):
1. Drag & drop a snippet on a page (let's say the /page)
2. Set that snippet visibility to "Visible only if utm campaign is
"Sale"
3. Repeat step 2 3 4 from above
4. Open /page?utm_campaign=Sale
5. You will see that the block is not shown despite accepting the
cookies and having the correct utm set.
Note: we don't want that clicking on I agree reload the page, it would
solve everything but would have poor usability.
Note that with the default cookies bar, you could still naviguate to
another page, and accept the cookies later, in which case the UTM would
never be set since they would not be in the URL anymore.
It's an acceptable limitation, if that's a real issue to someone, they
have to set the popup layout to a blocking one, not the small non
intrusive one.
Fix:
When closing the cookie bar, forcing the info in the URL to be stored in
the cookies if the key is a UTM.
opw-3681927
closesodoo/odoo#157711
X-original-commit: 8c31c2b08ed84ccdb97af628d9db7f6c67c6d830
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Antoine (ande) <ande@odoo.com>
Since this commit [1], the two searchbar snippets are broken.
The search bar input seems invisible because it shares the same color as
the default snippet background and has no border. This style matches the
search inputs used in apps (like the "/shop" search bar), which isn't
affected by the "Input fields" settings in the "Theme" tab.
To resolve this issue, this commit introduces a new option to choose
between the "light" style (similar to "/shop" search bars) and the
"default input style" for the 2 "Search" snippets.
The "default input style" is automatically applied when the "Search"
snippet (excluding saved snippets) is dropped to address the issue
caused by the light-on-light color scheme.
Steps to reproduce the issue:
- While in Website edit mode, drag and drop a "Search" snippet onto the
page.
- Bug: The input appears invisible due to the lack of a border and a
background color identical to the snippet's section color.
[1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20
task-3662985
closesodoo/odoo#154435
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Steps to reproduce:
- Click on the footer and enable footer "Slide Hover" option
- In the theme tab, add a theme bg image
- Drag & drop a "Text - Image" snippet (or any snippet without a bg
color set, or any snippet with a bg color set and just remove it)
- The snippets and page layout in genral will receive a forced color
instead of using the bg image set.
This is because with the slide hover option, the bg has to be moved from
the `#wrapwrap` to the `main`. Indeed, it's the main which is scrolling
hover the footer, not the `#wrapwrap`. Without doing that, the elements
hover the footer would have a transparent background and would not hide
the footer.
But the bg image was not considered when doing it, only the bg color.
opw-3704746
closesodoo/odoo#157638
X-original-commit: 68c8a7f48ac955a8e9e4f1fc8cb1c76af54116b3
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1], image options like "Filter" are kept when a user changes the
position of an image in an "Image Gallery" snippet. [1] also adapted the
`snippet_image_gallery` tour (moved in `snippet_image_gallery_reorder`
from version 16) to test this behavior. To do so, the test adds a filter
on an image in an "Image Gallery" snippet, checks that the filter is
displayed on the editor panel, moves the image, clicks on it and finally
checks that the filter is still displayed on the editor panel. The
problem is that the steps that check if the filter is displayed on the
editor panel are the same before and after the move of the image which
means that the second check is true also before the move of the image.
This situation is a typical case where an undeterministic error could
happen. Indeed, we do not know if the second check tests an old value or
an updated one.
To solve the problem, the test has been adapted; after the move of the
image, the test clicks somewhere else (on the footer in this case), and
then back on the moved image to finally check that the filter is still
displayed on the editor panel. The goal of the click on the footer is to
be sure to have a loaded version of the editor panel. By doing so, we
remove the risk of an undeterministic error situation where a condition
is already true before an action is done.
Note: this problem has been discovered because the test
`snippet_image_gallery_reorder` succeeds on version 16.3 without the fix
of [1]. Now, the adapted test fails on version 16.3 without the fix of
[1].
[1]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481
task-3717041
closesodoo/odoo#157207
X-original-commit: e7a17fd27abed655258856a83668552c2930170c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
The goal of this commit is to only use one global `resizeObserver` to
adapt the text highlights on resize.
task-3285817
closesodoo/odoo#142968
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The goal of this commit is to improve the current text highlight code
by adding the following updates:
- The editor's code (`_handleTextOptions()`) will only set text
highlight classes and activate the snippet. Highlight DOM adaptations
(multi-line detection, setting SVGs...) are done by the public widget.
- The `o_text_highlight_item_dirty` class is no longer used to adapt
non-detected highlight items (the highlight mutation observer was
tweaked to detect and adapt the new highlight items added to the DOM
after editors commands. E.g. after the `oEnter()`).
task-3285817
Part-of: odoo/odoo#142968
A `z-index: -1` is used on highlight SVG to make sure they appear behind
the text they highlight. However, it should still appear above
the background of the column/snippet behind that text. To make sure of
that, a new stacking context was created, using `z-index: 1`. While this
works... it also changes the z-index value, making it possible for
highlighted text to appear above other elements for no apparent reason.
This is replaced by a more appropriate `isolation: isolate;`.
task-3285817
Part-of: odoo/odoo#142968
Co-authored-by: qsm-odoo <qsm@odoo.com>
The goal of this commit is to update the `selectStyle` options to handle
the default CSS `"currentColor"` value.
task-3285817
Part-of: odoo/odoo#142968
This commit addresses the erratic behavior of the mobile menu when
clicking on menu items linked to anchors instead of navigating to
different pages. The issue occurs in mobile view and can be reproduced
by following these steps:
1. Create a page longer than the height of the screen with 3 blocks.
2. Add 3 links to target different sections on the page.
3. Create 3 menu items linked to the newly created anchors (/#...).
4. Save to apply the modifications.
5. Switch to mobile view.
6. Open the hamburger menu.
7. Click on the first menu item, then the second, then the third,
and again on the first one.
Upon reproducing these steps, the scrolling event would pass through
all the anchors. This occurs since [1]. This commit introduces fixes to
ensure proper navigation when clicking on menu items in mobile view,
resolving the described issue.
[1]: https://github.com/odoo/odoo/commit/cb1ad42130b52334992aba2f10bb91798b23a7a6
opw-3652930
closesodoo/odoo#150810
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Go to an event "Introduction" page
- Enter edit mode
- Click on the pre-existing "Introduction" title (note that it cannot
be removed because of the way the page is built, we might want to
improve that in master)
- Save it as a new custom snippet
- Go to your homepage
- Drop that new custom snippet that was saved
=> It cannot be removed, the rest of the content is kinda broken as
wells, etc etc.
This is because the original branding was saved with the snippet.
Indeed the event pages are made in such a way those pre-defined titles
are snippets but which are "editable root elements", i.e. elements
whose ancestors cannot be edited since themselves or their neighbors
contain dynamic elements.
opw-3633326
closesodoo/odoo#157191
X-original-commit: 356b8ce1070243ce69b5ba75d4988fcee6bc6190
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a slideshow opens, the keyboard events don't work right off the
bat. You first need to click on one of the arrows before being able to
interact with the keyboard, which defeats the purpose.
Steps to reproduce:
- Drop an Images Wall snippet and save.
- Click on an image: the slideshow appears.
=> Pressing left, right or escape doesn't work.
- Switch to the next image.
=> Pressing left, right or escape now works.
closesodoo/odoo#157126
X-original-commit: 32c6f7e7688eb3b05d569e1895e8fc102f71baf4
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Steps to reproduce [17.0]:
- Go to website (in "Edit" mode) > Click on the "Contact Us" button.
- Duplicate the CTA button ("Button options" > "Duplicate icon").
- There is no way to only remove the duplicated button, and the "Header"
> "Show/Hide Button" option will disable the whole CTA container.
After the website headers redesign in [1], a new feature was added to
allow users to select the elements they want to display in the header
(social links, call to action...). The CTA section was also marked as
'oe_unremovable' which disabled the option to remove it in the editor.
When a CTA button is duplicted, the clone will also be unremovable which
makes it impossible to remove.
The goal of this commit is to prevent the duplication of unremovable
buttons. It's always possible to add buttons by drag & dropping "Button"
snippets which are also removable.
Remark: Also after [1], two header navbars were added in the DOM (for
the desktop view and mobile). Which means that the CTA field is also
duplicated and every change on the CTA buttons in Desktop will be
reflected in the mobile version.
[1]: https://github.com/odoo/odoo/pull/119650
opw-3706902
closesodoo/odoo#156164
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Type an insdustry ... is not kind of something lean for user, this
commit change industry placeholder into a more cleaner version
closesodoo/odoo#156456
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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>
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 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>
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>
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>
Benjamin Vray