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
[This commit] fixed an issue with the menu cache. Unfortunately, during
the forward port, we missed updating the cache key according to what has
been done in [this other commit]. This commit updates the cache key and
improves the test.
Steps to reproduce the bug fixed by this commit:
- Render a website without a record URL in the menu (to the cache)
- Edit the website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This issue does not occur if there is a record like URL in the menu
before the first render.
[This commit]: https://github.com/odoo/odoo/commit/970c173530e5523d0e3242ad84dae6fe5e332d68
[this other commit]:https://github.com/odoo/odoo/commit/595aa248433246959a5fa9288e477091701c6a35
opw-3694651
opw-3750925
opw-3781668
closesodoo/odoo#159464
X-original-commit: 9b5647f2951cdd7bde214f860b5ea95d42d2a501
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
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>
Since [this other commit], the style indicating the active nav item
stopped working if the user added record pages to the navbar. This was
due to the cache system not being invalidated when switching from one
record page to another.
This commit fixes the issue by disabling the cache for the navbar if
there is a record page in the menu.
Other potential solutions were considered but ultimately rejected:
1. Using the record as a t-cache key. However, this would mean that if
you have 60,000 visible forum posts, you would end up with 60,000
different caches.
2. Activate the correct element using JavaScript. This would lead to a
duplicate logic in the JavaScript and the Python code, and it would
introduces a slight lag to add the active class on the correct nav item
(due to the time it takes to load and execute the JavaScript).
The chosen solution is the best compromise, as it maintains the cache
for most cases (website menu without records page links in it), nothing
change with this commit. For problematic cases (record pages in the
website menu), this commit disables the cache, which is a reasonable
trade-off.
Steps to reproduce the bug fixed by this commit:
- Edit a website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This commit fixes the issue (a update of the website module is needed)
and adds a test to prevent regressions.
Notes:
- To see the issue locally, remove the --dev xml or --dev all arguments.
- The same issue was occurring with other record pages (blog posts, ..).
- We will introduce back the groups on menu and benefit from this new
method to also disable the menu cache if one of the menu is linked to
a group. See task-3800830
[this other commit]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
opw-3694651
opw-3750925
opw-3781668
closesodoo/odoo#159006
X-original-commit: 43576cd424b6d0fc7da01142b5e6550e371ad1ff
Related: odoo/enterprise#59321
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Purpose
=======
Lots of tickets (e.g. 3775298) are created because the default menu has been deleted,
leading to the impossibility to install a new module, as the parent_id
for new menus like /shop or /event are directly referencing the
website.main_menu record, or to the impossibility to create a new
website.
Task-3802440
closesodoo/odoo#158879
X-original-commit: adb1dcfd0a150ab4706a09a29ae8921fb94fa463
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The attribute cache is mainly used from the Environment class. The
ormcache attribute using the same name leads to confusion.
Related task:
task-3818968
closesodoo/odoo#155264
Signed-off-by: Rémy Voet (ryv) <ryv@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>
The s_picture snippet's image was not using the img-fluid class; which
means that if you removed the default img-thumbnail, the image could
overflow its container, especially if you replaced it with a custom
image.
The user still had the possibility to apply width: 100% to solve the
issue. This commit solves the issues by just adding the img-fluid class
for future s_picture snippets. Existing ones are not worth worrying
about: setting a 100% fixed width is an easy fix and a good practice
anyway.
task-3266862
closesodoo/odoo#157808
X-original-commit: 79208821fb60abe8f34dc45c2f282cdbf52c0d4b
Related: odoo/design-themes#784
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@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>
[This other commit] introduced a method to serve Google fonts from the
local server. Then it has been back-ported to previous versions with
[this commit].
Unfortunately, the font was not identical when the user chose to load
the font from Google servers versus from the local server. This
discrepancy was due to a missing parameter when downloading the font
file to serve it from the local server. This commit fixes the issue by
adding the missing parameter.
Steps to reproduce the issue fixed by this commit:
- Drop a text block onto a website page.
- Make the text bold.
- Go to the theme tab.
- Change the font to https://fonts.google.com/specimen/Poppins
=> The text style changes depending on whether you checked the "Serve
font from Google servers" option or not.
[This other commit]: https://github.com/odoo/odoo/commit/b06ce21eba6388ce34bbffffadcb489f0e8557dd
[this commit]: https://github.com/odoo/odoo/commit/04ab4e255b7fef1608ee2c70a3a005f3064bc4f3
opw-3775683
closesodoo/odoo#157800
X-original-commit: be2d27e69d7928a46d49a7ef0a3c4b93932a36b8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@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>
__Current behavior before commit:__
When the field `website_id` of a user is set, this user should only be
able to login via this website (cfr. [this method][1]). This means that
he can only login if [`get_current_website`][2] returns the same website
as `website_id`.
The issue is that when login with RPC, `dispatch_rpc` is making a
[`borrow_request`][3] which hides the `request` object from the RPC
layer. This has the consequence that `get_current_website` is not able
to retrieve the website based on the url of the request. Thus preventing
a user to login via RPC even if the domain used corresponds to the
website set in its `website_id` field.
__Description of the fix:__
Add the possibility to retrieve the current website via
`threading.current_thread().url` (which is set [here][4]). This way it
is possible to know the current website even if `borrow_request` has
been used.
__Steps tor reproduce:__
- Install `website`
- Go to Website > Configuration > Websites
- Set the domain of the first website (e.g. `http://localhost:8069/`)
- Go to Marc Demo" res.partner form view
- In Sales & Purchase tab set **Website** to "My Website"
Then run this script in another terminal:
```python
#!/usr/bin/env python3
import json
import urllib.request
url = "http://localhost:8069/jsonrpc"
dbname = "db-16.0"
def rpc_login_user_demo():
"""
Login with demo using JSON-RPC
:return: the user's id or False if login failed
"""
req = urllib.request.Request(url=url, data=json.dumps({
"params": {
"service": "common",
"method": "login",
"args": [dbname, 'demo', 'demo']
},
}).encode(), headers={"Content-Type": "application/json"})
response = json.loads(urllib.request.urlopen(req).read().decode('UTF-8'))
if response.get("error"):
raise Exception(response["error"])
return response['result']
uid = rpc_login_user_demo()
if uid:
print("Login success")
else:
print("Login failed")
```
The login will fail but it should succeed since we sent the request with
the same host than the website domain.
opw-3742591
[1]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/addons/website/models/res_users.py#L40
[2]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/addons/website/models/website.py#L944
[3]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L361
[4]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L2037closesodoo/odoo#157372
X-original-commit: b8bc400909012dd04d383287a1850bfc96dd0c5c
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@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>
This commit prohibits the archival of a company if it is associated with
a website. Otherwise, the website wouldn't be accessible anymore by
public users (and so by all users if they need to login).
Step to reproduce:
- On website 2, change the company from SF to Chicago
- In the website list view (in debug mode), reorder the websites so
website 2 is the first one in the tree view
- Archive the Chicago company (from debug > companies and do it from the
list view)
- Try to access the website/runbot from an incognito tab
- It will show a raw 403 error
Note that the companies can only be archives since Odoo 16, thanks to
this commit: https://github.com/odoo/odoo/commit/7d0996bb151f68647b22719eee5ed4a4c35574bb
opw-3749772
closesodoo/odoo#156988
X-original-commit: d7456bf5376cf53670dbe8eaf1a2281aa254d521
Signed-off-by: Romain Derie (rde) <rde@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>
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>
Benjamin Vray