Strings within inline templates are not translatable, so we convert
these templates into standard templates so that they can be.
Task-3761551
closesodoo/odoo#162106
X-original-commit: 5b38d58db1bb7cacd2a5ffa195a3799f2645fdbb
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Mohammed Basioni (basm) <basm@odoo.com>
By default, Bootstrap uses a solid color and dim the element by setting
`$hr-opacity` to `0.25`[1].
Our design comes with a color that is "dimmed by default" since:
```scss
$hr-color ← $border-color ← rgba(currentColor, .25)
```
This commit therefore sets `$hr-opacity: 1 !default`.
At the same time, this also removes the hr background-color that
Bootstrap sets, otherwise it conflicts with the transparent color we are
adding on top of it.
[1]: https://github.com/odoo/odoo/blob/1154556/addons/web/static/lib/bootstrap/scss/_variables.scss#L664closesodoo/odoo#160495
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Steps to reproduce :
1. click on edit website.
2. click on THEME tab from snippet options.
3. scroll down to input fields.
4. the border width has options for small and large size, which serves
no purpose and were displayed empty.
Purpose:
This commit aims to remove the changes made on [1] which added 2
sublevel options for Border Width for Input Field which served no
purpose.
After this commit :
The Border Width option will not have sub options small and large.
[1]: odoo@388e4bb
task-3771146
closesodoo/odoo#161872
X-original-commit: f35123799408614c0bd50fcb79d147d2f69a84f7
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
In Chrome, if a scroll event is not brand new, its `currentTarget` is
lost.
This commit makes sure that the `currentTarget` of the throttled scroll
event sent to `_onScrollWebsiteAnimate` is kept separately to avoid the
issue in case of throttling delay.
task-3449843
closesodoo/odoo#161850
X-original-commit: 277e9f292a031ed835f4135e597c17dab2fd067d
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
This commit adds the database ID to the IAP calls made to generate text.
It permits to prevent abuses of OpenAI calls.
task-3740440
closesodoo/odoo#154615
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Drop an Text - Image block
- Click on the Image
- Click on the link button next to replace
- Try typing a URL
=> Typing a URL is hard because the widget keeps re-rendering
Reason: Since [1], the jQueryUI urlcomplete widget was changed into an
OWL widget. This added a call to `urlChosen` on input, which leads to
the SnippetsMenu re-rendering the options.
This commit fixes that by remove the call to `urlChosen`. Nothing is
lost since the input is already handling its own changes. Instead,
urlChosen is only called when selecting an element from the dropdown.
[1]: https://github.com/odoo/odoo/commit/86a9171ec7790aa09f2b9a50dcb26deb029e8bedclosesodoo/odoo#161045
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Co-authored-by: =?UTF-8?q?Nguy=E1=BB=85n=20=C4=90=E1=BA=A1i=20D=C6=B0=C6=A1ng?= <daiduongnguyen2709@gmail.com>
[This first commit] made it possible to have an error when there was no
comparator for a field with conditional visibility. [This second commit]
prevented an error from occurring in this case. The purpose of this
commit is to prevent the user from getting a conditional visibility
configuration for a form field where there is no comparator.
Steps to reproduce the problem:
- Go to /contactus.
- Edit page.
- Click on the "Your Company" field.
- Select "Visible Only If" for the "Visibility" option.
- Click on "Visible Only If" again.
=> The comparator is not defined.
Another way to have the issue was:
- Drop a form on a page.
- Click on the "Your Company" field.
- Select "Visible Only If" for the "Visibility" option.
- Set visible only if Your Name is equal to "test" as condition.
- Click on Your Name field.
- Change the field type to Radio Buttons.
=> The comparator is not defined.
This commit fixes those two cases.
Technical information:
When we change the field's visibility to conditional (`setVisibility`),
we add a default visibility dependency (`_setVisibilityDependency`). At
this point, the comparator is removed and added in `_renderCustomXML`.
`_renderCustomXML` was only called if the visibility dependency had
changed.
[This first commit]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
[This second commit]: https://github.com/odoo/odoo/commit/808780c89cfba940957f7410f787de31e31bda27
opw-3806409
closesodoo/odoo#161527
X-original-commit: 770cc162d6de82818d8e29bf156bb01f65ca8e2c
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit, when adding a new grid item in a grid by using the
"Add Elements" option, if the page was scrolled such that the top of the
grid was not visible, this new grid item may not always be visible. This
is annoying as the user could add an element and not see where it
appeared and would therefore need to look for it.
This commit fixes this by making the page scroll to the added grid item
if more than half of it is not visible. A test is also added.
Steps to reproduce:
- Drop the "Text-Image" snippet and enough snippets under it to have a
scrollbar.
- Toggle the "Text-Image" snippet to grid mode.
- Scroll the page so the top of the grid is not visible.
- Add a new "Button" with the "Add Elements" option.
=> The button is not visible.
task-3616138
closesodoo/odoo#161159
X-original-commit: 50766b74196b3cdc5ac83d7962873f4fffa4c9f6
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
This commit fixes the 'og:site_name' metadata, which previously
defaulted to the company name (see [1]), causing issues for multi-site
setups. Now, the metadata actually uses the site name.
Steps to reproduce:
- Navigate to any page
- Right-click and select "View Page Source"
- In the <head> section, observe the meta property "og:site_name" set to
"MyCompany".
[1]: https://github.com/odoo/odoo/commit/156955de6b4e6288ac606d29b843081842154eff
opw-3791082
closesodoo/odoo#161123
X-original-commit: 24ea3ca4b12f8dd4103a650436a144e776b81d83
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
To reproduce the issue:
-Drag and drop the rating snippet.
-Change the score from options.
-Notice that spaces between icons disappear.
In the release notes[1] of jQuery 3.5.0, it's stated that security
fixes related to the HTML parser were implemented. Consequently,
self-closing e.g. `<i/>` tags inside function arguments were replaced
with e.g. `<i></i>`. As a result, trailing spaces lost significance,
causing icons to stick together.
Before the commit:
Prior to Odoo 16.2, jQuery 3.3.1 was utilized, which allowed the use
of self-closing tags in the append function. This behavior was as
expected.However, starting from Odoo 16.2, jQuery version 3.6.3 was
adopted.
After the commit:
Instead of using self-closing `<i/>` tags, `<i></i> ` with a trailing
space was used. This trailing space gained significance due to the
prefilter no longer ignoring it. Consequently, icons no longer stick
together after changing the score.
task-3576760
[1] https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/closesodoo/odoo#161076
X-original-commit: b897e836697a288bbd58a8efc340d9f7b2e76e30
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
It should not be common, but through custo or in debug mode, one can
create a menu without an URL since it's not required on the model.
Through regular flows, it won't be possible since our UI won't let you
go through when creating a menu if you don't set a URL.
Followup of https://github.com/odoo/odoo/commit/948235079f002794f9837d3cf91e2d20e3254e20
X-original-commit: f2ac2ab72a190375c8116a11109191c0b7b970dc
Part-of: odoo/odoo#160588
At the moment, duplicating a website is not possible in the sense of
duplicating content, pages, etc. It is still available as an action from
the form view, and it could make sense to start up a new website with a
few common values (social media? etc?)... but many of website fields are
technical fields that should not be copied and many are dubious to copy
and not even visible in the form view. Really, duplicating a website at
the moment is misleading. This commit disables the possibility from the
form view.
In the future, we want to focus on the ability to export / import a full
website, but that's not for now.
opw-3782830
closesodoo/odoo#160587
X-original-commit: 43971a22c56b197306060ac3be7903d36d2c4be9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Related to previous commit: a9a9d2f12740b02c025f992d62c0d4f5feeaab1d
From initial PR: 158843
Improve Regexp to match double slugs /blog/blog-1/post-2 or /blog/1/2
Ignore param order: `?a=<param>&b=<param>` == `?b=<param>&a=<param>`
Remove trailing / from base url when querystring is present
Ignore '/en' url instead of '/en_US' since the default url_code has been
updated meanwhile (269aa59411).
Add a new test to check that urls are cleaned as expected
Remove crawl as admin, since the demo user already have all groups and
so we will check the same urls. The overlap is important for a really
low value.
X-original-commit: f17b210c6ad2364aebc6199153523ea5b767f67f
+ remove support of # part in clean url, not handled server side
+ support path in querystring (forum_origin)
closesodoo/odoo#160409
X-original-commit: 818e7af5650fae464090e7249f776193dc2b3814
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Odoo implements its own lazy-loading mechanism for the biggest JS
bundles that are loaded on the frontend. This mechanism allows the page
to appear to the user very fast, at the downside of having some
interactive elements (such as buttons) have no effect during the lazy
loading. In general, this is not a problem since:
- Standard links and buttons work, only those with custom effects (a
modal, a custom JS behavior, etc) have no effect.
- The full loading should not take long anyway.
- After the pages have been visited, everything should be in cache.
However, in some cases (countries with poor internet connections), the
experience can be confusing. Without lazy loading, they would have a
page that appears as a blank white page for a few seconds. With our
custom lazy loading, they get the website very fast... but some buttons
appear buggy (no effect) for a few seconds.
The long term plan is to review our lazy loading:
- Should it be less delayed than it currently is? (at the time, this was
the minimum delay that made Google give us good page scoring but it
may not be as impacting as before)
- Should some of the lazy-loaded JS should actually not be?
- Should the assets be split differently?
- Could we be able to remove some code that weighs too much?
- ...?
Meanwhile, this commit improves the behavior this way: during lazy
loading, any click on a button is now ignored but a loading effect is
displayed. Once the JS is fully loaded, the click is then re-played on
the previously clicked button, hopefully triggering its effect. In any
case, this cannot be worse than what we have before... except for:
- The reasonable risk we take merging this in stable (we considered
merging in a more recent version but it is needed for some specific
projects and many websites would benefit from this improvement).
- Any custom code that added behavior on buttons to be available during
lazy loading... will just wait for lazy loading with a loading effect
too now. This should be a good compromise as, again, that lazy loading
is cached and should not take too long anyway.
Note that this replaces the previous o_wait_lazy_js class behavior (it
has now no effect).
Overall:
- This should not impact (neither improve nor worsen) most websites that
are currently experienced from good internet connections.
- This should be a big improvement for most websites that are currently
experienced from bad internet connections.
Related to task-3770362
closesodoo/odoo#159680
X-original-commit: 6aeebe47dd552144fabd42ddb190021f1499e38a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a background video and an animation coming from the left or the
right are on a page at the same time, there sometimes is a horizontal
scrollbar that appears for no reason. It can happen at any screen size
but more frequently near 1000px and below. This issue seems to happen on
Chrome only.
It seems to be a race condition between the calls to the `_adjustIframe`
function in the `backgroundVideo` public widget. Indeed, this function
is called when the video is added in the DOM and each time the screen is
resized. When an animation is played, it triggers a resize of the window
when it is over, which therefore calls `_adjustIframe`.
When the animation comes from the right/left of the screen, the animated
element is translated from outside the page; the page width is therefore
bigger but its overflow is prevented. When the video is loaded, the
loading placeholder is removed. Depending on the time it takes to it to
fully load, if the animation ends before it, the iframe is adjusted
before the placeholder removal, leaving the iframe wrongly adjusted when
it is finally removed.
Note that it is hypothetical, as everything refreshes when inspecting
the DOM, making the scrollbar disappear. But this proves that no element
is really overflowing, so it seems to be a value refreshing issue.
This commit adds a call to `_adjustIframe` when the video has loaded, to
make sure its dimensions are recomputed/refreshed, preventing the
scrollbar to appear.
Steps to reproduce:
- Drop a "Text-Image" snippet.
- Set a background video to it.
- Add the "On Appearance" > "Fade" > "From Right" animation to the image
column.
- Save and then resize down the screen to 1000px or below.
- Refresh.
=> When the video is loaded, a horizontal scrollbar may appear. If not,
refresh until it does.
opw-3487117
closesodoo/odoo#159817
X-original-commit: 6035874e61d2bb1cecc339c4006cdcb6b4084b5c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Follow-up of [1]. Commit [2] refactored the way we check if an option
update needs to trigger a page reload: if the option is marked as a
page option (`data-page-options="true"` on the option's main `<div>`),
then it will reload whatever the method used if there is a `reload`
parameter. Note that this `reload` parameter does not make much sense
anymore, it should be reviewed/removed in master.
Problem: [2] made a mistake in its implementation, pushing an array
instead of concatenating it. This worked by chance, as instead of asking
"does this option method requires a reload", it was asking "does this
set of option methods requires a reload"... and in that case, the code
is fallbacking on retrieving common parameters, which `reload` likely
is without custo. This could have been fixed in master only. Given the
very low risk of breaking anything critical updating this code, it was
chosen to prevent a potential crash in custo (which could occur as we
give a wrong parameter type to a main method) and allow overrides to
make `reload` a specific parameter for a specific method without the
need of `data-reload` added in the DOM.
[1]: https://github.com/odoo/odoo/commit/556ae457b02e9c077d09fa9c3f9f1e6c6e26b345
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af#diff-70f7fe38208aa7fe678f18e329d3c11b70065dee723921352b6005774e8bab53R456closesodoo/odoo#159927
X-original-commit: 337fbdc35ee0da2ae9d0a524a8b084c959949c78
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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>
Mohammed Basioni