Since the Bootstrap 5 merge, when there were several TOCs on the same
page the scrollSpy only worked for one of them. This commit fixes that.
Steps to reproduce the bug:
- Drop two TOC blocks on the same page
- Save the page
=> The second TOC is not working properly, it does not highlight the
current section.
Related to opw-3047375
Related to opw-3035502
task-2948895
X-original-commit: c182691bbfd6be8cc9aed26162635f5fdb117991
Part-of: odoo/odoo#107732
The table of content (TOC) has two mechanisms that interest us here:
The first one is scrollSpy (from Bootstrap) which allows (among other
things) to bold the menu elements according to the scroll. The second
one is a mutation observer which is implemented to regenerate the menu
when the content of the TOC changes.
This being said, when we edit the TOC and scroll at the same time, there
is a race condition that makes scrollSpy want to add a class to a menu
element while this menu has just been regenerated by the observer. The
error is only visible since the migration from Bootstrap 4 to Bootstrap
5 because to add the class, Bootstrap 4 did it with the jQuery
`addClass()` function which does not cause an error if the element on
which it is called does not exist. Now, Bootstrap 5 does the same thing
in pure JS with `classList.add()` which causes an error if the element
on which it is called is not defined. This commit fixes this error by
disposing the scrollSpy when the menu is regenerated.
Steps to reproduce the error:
- drop a table of content block
- drag a snippet around and go over the drop zones
=> traceback. It can appear directly or after some tries.
opw-3047375
opw-3035502
task-2948895
X-original-commit: a05f782871c61b2d58ca2fd4277cb7aed65a301d
Part-of: odoo/odoo#107732
Since [this commit], when dropping several "table of content" blocks on
the same page, it was impossible to save. This commit solves this
problem.
Steps to reproduce the resolved bug:
- In edit mode, drop two TOC blocks
- Click on Save
=> the UI is blocked
[this commit]: https://github.com/odoo/odoo/commit/06b03ba5ef8375b1236f6ecb52ac468124e910ba
Related to opw-3047375
Related to opw-3035502
task-2948895
X-original-commit: a6de596017cdbd0da10b4050da132d46dc82a491
Part-of: odoo/odoo#107732
When the url redirects to an anchor on a website page, the page must
scroll correctly to the section. This commit allows to do that by taking
into account the size of the navbar. The bug is visible by following
those steps:
- Drop a text - image block on a page
- Drop a picture block under text - image block
- Create a link to target the picture block
- Put link to block picture in the "Learn more" button
- Save
- Right click on the "Learn more" button and open link in a new tab
=> The page is not scrolled correctly to the picture block.
Note that the bug is not present if the header has scroll, disappear or
fade out as scroll effect.
task-2818629
closesodoo/odoo#92777
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Commit [1] improved the "sanitation" of this field for special
character. For instance, when copy pasting the following terms:
| Input | Before | After |
|-----------------|------------------|-----------------|
| fée d'été à 40€ | f-e-d-t-40- | fee-dete-a-40 |
| Nội dung có Dấu | n-i-dung-c-d-u | noi-dung-co-dau |
But it actually came with a bad behavior which was not noticed: it
prevents to type `-` at the end of the input, which sounds good but is
not.
Indeed, when typing `a-word`, you will type `a` then try to type `-`
which won't work as considering a (forbidden) trailing slash, even if
you actually want to type something after.
This commit allows trailing slashes again, it's not a big deal and one
can remove it if he wants to.
[1]: https://github.com/odoo/odoo/commit/bb43d4dbb5745be84f0f9462e768989e50607bea
opw-3075419
closesodoo/odoo#107746
X-original-commit: bb43e343c0ec823dad8b102a81945b4a05a7af85
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
For some reason, safari on mac is not showing the sidebar menu content
at all. It remains a white div without content.
Seems like a bad implementation of that browser for this case, or at
least an implementation which is not shared by all other browsers.
Note that removing `z-index`, `position:absolute` or `overflow` css
property from the `wrapwrap` will make the menu appear.
!!! Also note that having a non scrollable page (not enough content),
like an empty homepage, will make the menu appear too. !!!
As this issue is quite critical:
- All mac/safari users are not seeing your website menu..
- And the admin don't event know it most of the time (as not on mac)
And since:
- It's been going for months without someone finding a proper fix
- It's hard to investigate as devs generally don't have mac to
investigate and have to use browserstack which is really bad for such
work
Step to reproduce:
- Select the sidebar header template
- Visit the website on safari
-> The menu will be invisible, like if the navbar was empty
opw-2984536
opw-2896939
closesodoo/odoo#107616
X-original-commit: ffa34d840a07efbbec3b180839d7cbf64787e4ef
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [this commit], a new option is available on the steps block to
change the style of the connectors. Unfortunately this was causing
errors in the console. This commit makes sure that we don't have these
errors in the console anymore.
Steps to reproduce the issue:
- Drop a steps block on a page
- Change the type of the connectors
=> Errors are displayed in the developer console.
[this commit]: https://github.com/odoo/odoo/commit/aba31e9f2d8a44ce1586403f2a621a6caeed57b4
task-3069766
closesodoo/odoo#107511
X-original-commit: c1805fc5d3c3eeaa5c2edca69a6b9375f4ea1a39
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
If the website domain is wrongly configured (set to a URL that will
actually be redirected through DNS/proxy/cloudflare etc), the website
preview iframe will loop forever.
The wrong configuration this commit is about are:
- Having set the website domain to naked URL while you configured your
naked URL to redirect to your `www` URL.
- The other way around (`www` to naked URL).
- Having set the website domain to `http` while you configured your
`http` domain to redirect to your `https` domain.
- The other way around (`https` to `http`) if it's even possible/done by
someone
While this could just be considered as a misconfiguration, it's a low
effort to support it. Also, the bug it implies is quite critical as the
user can't access his website app anymore (if he is smart enough and
somehow figure it's because of the website domain, he will think about
going to the General Settings to remove the domain).
All in all, it's a low effort to fix a (rare) critical issue.
Step to reproduce (`https`):
- Go to runbot (in `https`, normal way)
eg: https://21544921-16-0-all.runbot172.odoo.com/
- Edit the website domain and set it to the `http` version
eg: http://21544921-16-0-all.runbot172.odoo.com/
- Try to access the website app, it will loop forever, indeed:
1. You are on the `https` URL in your browser tab
2. The website app will try to load the iframe with the website domain
as URL, which is the `http` version.
3. The code in charge of loading the iframe URL (website_preview.js)
will detect that `http` URL as originating from a different domain
than the one of the current tab URL (parent window).
4. In this case, that code will reject that URL and instead load it in
the parent window URL -> It will basically redirect your whole
browser tab to that URL.
This is done as if you are loading the URL of a different website,
we want you to be completely redirect to this other website domain.
5. As `https` to `http` redirection (and naked -> www or www -> naked)
is done at a lower level (through nginx, dns, cloudflare etc), the
browser will not load the `http` requested URL but redirect and
load the `https` one.
6. Now, you are basically back to step 1. and entering an infinite
loop.
The same issue can be reproduced with naked domain and `www` domain but
not on runbot and difficult in local.
You can also reproduce it in local, but it will just do the useless
redirect once and won't loop as nothing is redirecting the naked to www
in local:
- Edit your `/etc/hosts` file and write
```
127.0.0.1 rde.com
127.0.0.1 www.rde.com
```
- Edit your website domain to `http://www.rde.com`
- Now go to `rde.com:8069`
- It will wrongly redirect to `www` version
-------------
On top of that, the domain misconfiguration would also lead to useless
reload when using the website switcher (it would reload the whole page
instead of just the iframe).
Step to reproduce on local (on runbot it will be replicable but it will
then enter the infinite loop described above):
- (Still with the `/etc/hosts` tweak described above)
- Edit the website_1 domain and set it to the `www` version
eg: `http://www.rde.com:8069/`
- Edit the website_2 domain and set it to the `naked` version
eg: `http://rde.com:8069/`
- Open the website app, land on one of the website (and its URL)
- From there, select the other one, it will redirect the whole page to
the other domain (naked vs www) instead of just reloading the iframe.
-------------
opw-3079168
closesodoo/odoo#107394
X-original-commit: 0808659dd29db938bb6f8386ee2027eafecb2f0f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Some commands from the powerBox command bar were not working
properly in the e-shop product "terms and conditions" section.
This was due to the isolation of Odoo fields
inside the odoo editor as a all.
Those fields do not always have an editable block element
to apply the command on.
We disable some commands that should not be apear in this context.
We also remove a redundant command (separator) in website pages.
task-2962067
closesodoo/odoo#107174
X-original-commit: 3776faa178314c4df889f4c04cc3931f8bef225c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit enables the use of the option "All pages" when using a popup
snippet.
Steps to reproduce the bug:
- Drag & drop a popup snippet.
- On its option in the right panel, there is "Show On" set by default
to "This page".
- Try to modify this option and select "All pages".
Bug observed: The "All pages" option can not be selected and the "Show
On" stays on "This page".
This commit has been done because since the version 16.0, the footer is
on an iframe [1]. Because of that, the program does not have a direct
access to the footer. This is why it is needed to first access the
top-level document before using the querySelector.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2983822
closesodoo/odoo#107236
X-original-commit: f469385dcfcbd9290c3522422f9e10600bb60b76
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
There are several customizations of the list and form view that consist
in modifying the behavior of a static menu action (archive, unarchive,
export, delete, duplicate). We have seen that this one is very complex.
So we decided to simplify it.
Solution:
Add the getStaticActionMenuItems API point. This allows us to easily
modify the behaviour of static actions.
We also took advantage of this commit to simplify the ActionMenu api.
We have removed the other actions because it was not clear enough.
They are directly added in the action category.
closesodoo/odoo#107086
Taskid: 3089039
Related: odoo/enterprise#34598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
As a fix, this introduces a new option for images in grid mode. When an
image is alone in a column which later becomes a grid item, or when an
image is directly added as a grid item via the dedicated option, the
image used `object-fit: cover` so that when the image is resized as a
grid item, it fits the dimensions of the selected grid area.
This confused some users as the image did not appear the same depending
on the screen size. Indeed, if an image is set to take 5 columns as
width and 3 rows as height, it does not ensure the ratio in pixels to
stay the same depending on the screen size: the grid is always made of
12 columns (so the width of each column depends on the screen width),
while the rows are always 50px tall. We could enforce the ratio of grid
items to stay the same or limit the ratio loss by reducing the 50px
height on smaller breakpoints but that would actually increase another
problem: for colored text grid items, their text would more easily
overflow their fixed area.
In the end, using the grid mode is about compromises, even if it allows
to achieve nice things and to have more freedom. This commit although
adds a new option to mitigate the issue for images: users now have the
possibility to switch the default "cover" mode of grid images to
"contain": in that mode, the whole image will always be visible (and
thus keeps the same ratio) and is just "contained" in the grid area
which is selected as dimension.
opw-3069234
closesodoo/odoo#107172
X-original-commit: faf19ef7f87fc043fb9a814516e01b8eeafd9b61
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Just change double the by single. This fixes various typos in error and
code comments.
closesodoo/odoo#107266
X-original-commit: 09dfedfc19c2bc34c2bb394dcc4bc609c5ac0107
Related: odoo/enterprise#34681
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When breaking a page from a Carousel or other slider snippet (eg by
hitting the backspace key at the beginning of a page), the editor's
history gets reverted but ends up applying the `active` class to all
pages. This is due is some way to the `_computeHeights` method of the
slider snippet, which applied the class to all pages to observe their
heights, then put them back in place. It seems in the labyrinth of ticks
the history step somehow started from a place where every page was
active, so we reverted back to that. The point where these classes were
applied should have never been observed in the first place since it's
purely technical. Not observing it fixes the bug.
task-3081259
closesodoo/odoo#106986
X-original-commit: be1d93edcfbd496c22a7c988b4570858a3d06c2c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since [1] when the search bar was refactored, images can be displayed in
the autocomplete results, and fallback icons are displayed instead of
images for records that have no images.
However, if no module that participates in the results provides actual
images, then the fallback icons are not displayed at all.
This commit makes the fallback icons displayed only based on the "Image"
toggle option of the search bar.
It also disables the hidden display options and enables the visible
ones.
Steps to reproduce:
- Do NOT install website_sale (which is currently the only module that
provides autocomplete results with images).
- Drop a "Search" block.
- Save.
- Type a single letter in the search box. (e.g. "a")
=> Autocomplete results were displayed without their icons.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-2951026
closesodoo/odoo#106953
X-original-commit: 4eecba4c8f5327fd1a137a8d88574c2b6a5eda05
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The comment became outdated:
- For 14.0 and above: mentioned the "Customize dialog" which does not
exist anymore.
- For 16.0 and above: mentioned "Bootstrap 4" instead of "Bootstrap 5".
Related to opw-3056683
closesodoo/odoo#106916
X-original-commit: fe90329ee32f9608c143a9fd658fe2a00712f9e4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit [1] introduced a website tour util to assert the value of a CSS
variable. This was used at the start of theme tours to check we are in
fact on the right theme before starting the tour.
While it's great for those tours when they are started as a test, it was
not meant to be shown to users following that tour. This commit fixes
that. Notice that theme tours are currently broken so the issue was
probably hidden. Those will be fixed at [2].
[1]: https://github.com/odoo/odoo/commit/b29e17765f4e912b2dd472493b5be500b3a32c87
[2]: https://github.com/odoo/odoo/pull/106703
Related to task-3084175
closesodoo/odoo#106756
X-original-commit: 696c45b4e5917d086f60fd960590328b878014f0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the website homepage tour was starting with an
unresolvable "Wait for the editor to be started", useful only for tests.
This commit removes that technical step for user tours.
task-3035156
X-original-commit: d45ce39b2904bcb4335f74fab3c42f3eebf477d5
Part-of: odoo/odoo#106746
Co-authored-by: qsm-odoo <qsm@odoo.com>
When entering edit mode, the navbar is hidden. The problem is that since
the merge of the website-in-backend feature at [1], it is only not shown
via an animation (height 0 + out of screen) but not `display: none`. The
tour system thus thinks it is still shown and keeps showing the related
tour tips.
E.g. with website_sale installed (and no demo data, to have the tours),
go on the shop page, there is a tooltip pointing at "+ New", enter edit
mode => the tooltip is still there and it even prevents to click on
"Discard" to leave the edit mode.
This commit fixes the issue by making the navbar `display: none` once
the closing animations are finished.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3082439
closesodoo/odoo#106735
X-original-commit: cdc8d4c889b316664323afad0d848403960150d5
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
While showcasing your website inside the website application, there is
the possibility to hit the escape key to enter fullscreen (hiding the
backend navbar outside edit mode and the editor panel during edit mode).
There was a problem following this flow:
- Go to your website inside your website app
- Hit escape to enter fullscreen
- Press CTRL-K to switch to another part of the backend
=> You are now somewhere in the backend, without the navbar (fullscreen)
and you cannot exit it.
As it was a one-line fix (except for the re-indentation), this commit
now allows to exit fullscreen mode wherever we are.
Discovered during task-3082439
X-original-commit: bd225ec782e26c87301e9e786ffd7250ad62ebfc
Part-of: odoo/odoo#106735
Quick feedback from client, this is following [1] that added a button
next to the URL input of `we-urlpicket` to be able to preview the link.
The wording was not great, it gives the impression it's an option to
chose to have that URL opened in new tab (eg when form is submitted).
Also, giving it the style of a conventional we-button was also giving
the same impression that it was actually an option that you could click
on to enable something.
Changing the wording and the style of those special we-button should
reduce the confusion.
Arguably, one might think about the usefulness of this button but it
acts as the counterpart of the regular links which have a "Open in new
tab" possibility when hovering the link in their preview tooltip.
[1]: https://github.com/odoo/odoo/commit/acdf3cf7f5aebd803ffa1507e81ed8801727a03a
opw-3060966
closesodoo/odoo#106538
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In this commit [1] (merged in 16.0) a bugfix has been made in the
`removeSlide` function but this one should have been applied on all
supported versions because the bug it fixes is present on all versions.
The bug it fixes is the following:
- Drop a carousel block on a page
- Remove the *first* slide
=> There is no active indicator.
Moreover, the bugfix made in 16.0 [1] introduces another error: when a
slide is removed from the carousel the indicators are not in a correct
state anymore.
Following the same steps with the changes of [1]:
- Drop a carousel block on a page
- Remove a slide
=> Indicators are no longer consistent with the slides so tracebacks
appear during the carousel slides. The list of indicators must have on
each element a `data-slide-to` attribute which must reflect the
position of the slide (starting with 0).
So this commit is to backport the fix from 16.0 [1] to 14.0 and to fix
the new bug that [1] introduces.
[1]: https://github.com/odoo/odoo/commit/f7055d3dbabfbe471f490bd65c2032f5251f3f37
task-3040931
opw-3051615
closesodoo/odoo#106639
X-original-commit: 212e8ce620f6eb95aeff6426e06cb29b2c06d0c1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the buttons to scroll to the next element might not
work if the next element was invisible.
Steps to reproduce the bug fixed by this commit:
(Note that these steps are only reproducible from 15.0. We decided to
merge this fix in 14.0 to be custo-friendly)
- Install two languages on a website
- Drop a cover block (1), with a height of 100% and a scroll down button
- Drop a new block (2) only visible for language B below the block 1
- Drop a new block (3) visible for everyone below the block 2
- Save and go to the site in language A
- Click on the scroll down button
=> No scroll at all while the user expects to scroll to the block
visible to everyone (3). This commit fixes that by making the user
scroll down to see the next visible element.
opw-2967706
closesodoo/odoo#106477
X-original-commit: 076d7ac7795f86d48b532b6c2a1ff76e4503604e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With commit [1] we refactored the cookies bar to let the user decide if
he wants to accept the cookies (and/or only part of it).
Before that commit, the `website_cookies_bar` cookie could only hold
`true` as value, which now is holding an object like
`{"required": true, "optional": false}`.
This creates an issue if a user is coming from a previous version with
`true` as cookie value because since the refactoring it will crash both
in JS and PY because `in` instruction with a boolean value will fail in
both languages.
The decision taken here is simply to remove the cookie if we face such a
case so the user can decide again what he wants (since there is more
choices now).
It also means that we won't be holding an outdated value in the cookie
any longer.
[1]: https://github.com/odoo/odoo/commit/2cbda6c98ee947cea1d06c09880eee8c758304a8
opw-3074303
closesodoo/odoo#106621
X-original-commit: 22392755ed4c504e6ba2a5a9c9eb6643f2c95994
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Ever since the website is previewed in the iframe [1], pressing CTRL-K
(or Meta-K on macOS) while previewing the website can result in
focusing on the browser's URL bar on top of summoning the command
palette.
Steps to reproduce:
- Preview the website
- Click on the iframe to focus on it
- Press CTRL|Meta - K
- URL bar is focused
This commit fixes that by preventing the default behaviour within the
iframe and only summon the command palette.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3035637
closesodoo/odoo#106483
X-original-commit: 797a0514b58a37efc5246a655339353c200b4214
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
*: auth_totp_portal, mail_group, portal, survey, web, website_event,
website_event_track, website_mail, website_mail_group,
website_mass_mailing, website_payment, website_sale
Although this is deprecated since 5 years with [1], new occurrences of
`this.$target` in widgets kept being introduced. `this.$el` can be used
just like in any other widget, or even better: `this.el` to not rely on
jQuery.
For now, this still keeps the definition. This just removes the bad uses
to prevent more copy/paste... let's delay the decision to remove the
definition entirely to another day.
[1]: https://github.com/odoo/odoo/commit/2972976962617d4b8a0113bae58c640ab41cdff8closesodoo/odoo#106437
Related: odoo/design-themes#618
Related: odoo/enterprise#34343
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the icon to create a blog post in the new content
modal, inside the website "+ new", was not really fitting.
task-2941545
closesodoo/odoo#106269
Signed-off-by: Delacroix Pierre (pde) <pde@odoo.com>
Follow-up of [1].
After [2], color previews on the side panel would be changed by the
wysiwyg adapter. The adapter would add each block individually inside
the iframe and check its current styling to then add the style to the
color preview elements. This was performed many times (as color palettes
all have their own individual rendering of the color previews)
and slowed down the editor.
This commit improves that by relying on the copied variables introduced
at [3]. This removes the "re-render" of the color preview elements,
instead relying on styling rules and CSS variables which are initialized
when the editor is started.
[1]: https://github.com/odoo-dev/odoo/pull/1149#discussion_r900120846
[2]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
[3]: https://github.com/odoo/odoo/commit/a396f791da94d064d58cce15892e74f45d29b7b7closesodoo/odoo#106366
X-original-commit: 7f5a9d040348048990b25c271875c77d2c314e4d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Steps to reproduce the issue (see opw):
- Add a form to a page
- Add a checkbox
- Add a second checkbox that is required and visible only if the first
checkbox is not checked
- Save
- Do not check anything and try to send => Good, you can't, the required
checkbox is not set
- Check the second checkbox and try to send => Good, you can, the
required checkbox is set
- Go back to the empty form, check the first checkbox and try to send
=> Bad, you can't but you should: the required checkbox is hidden, it
is not supposed to be required anymore.
(Not that arguably, that two checkboxes setup should be replaced by a
required selection field but the issue of the OPW would remain as there
is another required conditionally-hidden field (a file upload) when the
second checkbox is checked.)
Conditionally-hidden fields should not require validation while they are
hidden. Indeed, their purpose is to be able to enter additional data
when some condition is fulfilled. If such a field is required, it is
only required when visible. The problem only occurred with checkboxes,
the other fields were already working in that case. Although there could
be issues with dates too, this commit added a series of FIXME and TODO
comments as well as some things need to be investigated.
opw-3003952
closesodoo/odoo#106204
X-original-commit: f501c25a9d33399cfbb45526d95038266d91686e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when submitting a website form which has invalid
radio buttons, checkboxes or file upload elements, they had no visual
difference. Now they will have red labels as intended with bootstrap.
For alone checkboxes, a warning label will appear after the checkboxes.
This will only take effects for newly added checkboxes.
Related to opw-3003952
X-original-commit: 3268b4c902c92c12f50081d31eb08d4c330ca03f
Part-of: odoo/odoo#106204
With [1], checkboxes in website forms were wrapped in a <div/> with the
"form-check" bootstrap class (as they should). That forgot to mark the
checkboxes themselves with the class "form-check-input". Without it they
are misaligned.
This fixes the error for newly added checkboxes in forms. Old ones will
stay "broken".
[1]: https://github.com/odoo/odoo/commit/9ea276ae2f00c3a5ba4e10af313085947e70e265
Related to opw-3003952
X-original-commit: b3ff062e8add1e9b810a37112f05a0c1d23136be
Part-of: odoo/odoo#106204
Before this commit, if the user tried to setup a required selection
field whose first value is empty, it was possible but the empty value
appeared as a 0px-height div in the DOM preview. That empty value also
shows up when trying to use the conditionally-hidden fields feature: if
another field's visibility depends on such selection field, the editor
UI was visually broken as the first choice was an empty option element.
Now, we show "<no value>" in both cases.
Note: this is not done in earlier versions than 15.0 although the
problem exists, but it was decided that the real problem was about the
visibility select being visually broken and that feature only appeared
in 15.0.
Related to opw-3003952
X-original-commit: a62f3dbef31c4750ba16d55adf28c235a27dbc56
Part-of: odoo/odoo#106204
Since [1], the google map UI to search for locations thanks to the
google map API was not working anymore. Indeed, the lib was loaded
inside the iframe (as it should) but not outside of it, preventing to
use the `google` object in the related editor panel widget. The
autocomplete UI style was also broken as the CSS is not available
outside the iframe.
As a fix, the code outside the iframe now use the `google` object from
inside the iframe (no problem seems to come out of it) and the style is
restored via custom CSS (custom CSS already existed and was already
changing most default style anyway).
As a reminder, this snippet is only available in debug mode or if your
google map key is setup, which we do not allow to enter anymore via
standard flow since 16.0 (15.3).
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#106103
X-original-commit: 7d60d0ae4ea195edc4a12e57bf1c3b7c661bcf82
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Using the "gps picker" (for example with the "Google Map" snippet) was
not flawless. The autocomplete menu which shows up when the user enters
an address is handled by the gmap API. It was actually not working at
all on Firefox for an unknown reason. Not listening to blur events on
the input seems to solve the issue. This commit also prevents triggering
a value change if the same address is reselected which seems to make
address changes a bit more robust too.
opw-2976261
X-original-commit: 50bf0b7f1677b8125d892fad968ccc8174c974c1
Part-of: odoo/odoo#106103
Some part of the google map API was deprecated and showed a warning
at each snippet redraw. Probably harmless but since the related API are
really capricious, best satisfy them as much as possible, even in
stable versions.
opw-2976261
X-original-commit: b761c8fe0762f449bd6d9a1763c152833819247c
Part-of: odoo/odoo#106103
Before this commit, when adding a google map snippet in the DOM, the
user was asked for its API key if not already configured, thanks to an
user-friendly dialog. However, in the case it was misconfigured (while
the editor dialog prevents some misconfiguration, configuration via the
backend allow any random key to be given), the UX was terrible: the
google map is simply removed without any notification.
Misconfiguration can be:
- Invalid API key
- "Maps JavaScript API", "Places API" or "Maps Static API" not enabled
- Billing not enabled
Now notifications/messages warn about those things and reopens the key
configuration dialog, which contains links to the gmap API documentation
and now more information.
Hopefully, this can be improved even further later. Indeed, this is
still not perfect as there is no reliable way to understand google
responses. E.g. even with the three mentioned API and billing enabled,
sometimes the google map API still returns errors indicating "not
enabled APIs" but it cannot be reproduced reliably. During my test it
was systematic for 15min at some point but now there is none, ever. Like
if there was a delay after enabling an API on the google console before
it stops sending errors... although the API works immediately.
Notice that in 15.0, this snippet is shown in debug mode only and we
encourage users to use the new "Map" snippet which does not require any
configuration.
opw-2976261
X-original-commit: d9f86840e27463ccf370a748cafc7c4be32f901f
Part-of: odoo/odoo#106103
The dot (period) is removed from user-facing strings in powerbox
commands, and the corresponding msgid in .pot files are updated.
task-2901665
closesodoo/odoo#106032
Related: odoo/enterprise#34116
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
After [1], when an option that requires the page to be reloaded is
changed, the editor will try its best to reselect the same snippet.
However, in some scenarios, the snippets' options could not be activated
leaving the menu on the snippet drag and drop menu.
Steps to reproduce (race condition so might not always occur):
- Activate the cookie bar in the website settings
- In edit mode change the header menu style
- The Snippets Drag and Drop menu is displayed
- Instead the Header Options should be displayed
The reason is that an event is not 'awaited'. Indeed, when starting the
editor, a 'widgets_start_request' is fired and not awaited.
It creates a race condition that is visible in this case but could have
caused other issue.
For the in-depth technical reason this happens:
- The wysiwyg is started, the popup is on screen, its options are loaded
by default (since it's needed to populate the invisibleDOM panel)
- activateSnippet is triggered with the Snippet it should focus on after
reloading
- widgets_start_request is triggered which destroys the popup and
triggers an 'onHide' event within the option
- The triggers a 'snippet_option_visibility_update' which triggers an
activateSnippet(false) which hides everything that was enabled prior to
this point.
This commit fixes the issue by re-ordering the events and making sure
that the 'widgets_start_request' is awaited
[1]: https://github.com/odoo/odoo/commit/a3e34512bf229d5d55f9e9d9eb0a9f7211a5a826
task-2687506
closesodoo/odoo#105816
X-original-commit: 5a2d0a2a88b9ecc2c330a948dfd9140b9edc3af3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Since this commit [1], the header language switcher has been moved out
of the header navbar. This created a bug, when the off-canvas option of
the navbar is activated, the language switcher is no longer accessible
on mobile.
As this commit is in stable version, the fix is only in Javascript. It
puts the language switcher back in the navbar when the off-canvas menu
is opened.
A specific case with the "hamburger full" header template, where there
is the same bug with the "call to action" button, is also fixed by this
commit.
This commit also fixes display issues in the off-canvas menu.
[1]: https://github.com/odoo/odoo/commit/2a000e33c5a44ddf0a777b43d8266cc413d8e4e2
opw-2964824
closesodoo/odoo#105504
X-original-commit: b89dbb2e18c4ccebcd72e87758b5d3363ed875b3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, `view_hierarchy` extended the QWeb view to see
the hierarchy of views.
With the evolution of the javascript framework, this use case has
now more sense in a client action rather than an extension of a
QWeb view.
This commit refactors `view_hierarchy` into a client action.
Part-of: odoo/odoo#103477
This commit updates the tooltips of disabled form field's duplicate &
remove buttons so that they do not reference the concept of "model".
task-2950433
closesodoo/odoo#105278
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website_mass_mailing (tests)
- Web Editor facts:
Since the refactoring of the editor done at [1], the cookies bar popup
is receiving a `contenteditable=true` attribute, making it receive the
chrome default `height` style for such elements.
The problem is that if this cookies bar's modal is hidden, the bar will
be shown as a thin empty white bar.
- Website Builder / Popup Snippet / Cookies bar facts:
A popup element is composed of a `.s_popup` parent containing the actual
`.modal` BS modal. Our internal logic and events are hiding and showing
this inner `.modal` modal element without considering its `.s_popup`
parent. It means that when the `.modal` is hidden, its `.s_popup` parent
is not touched and kept visible.
It might looks like it's not an issue as it would just be an empty
element (its only child is hidden) but it leads to some issues as
explained just above: an ugly white bar is shown.
Note that the cookies bar is nothing more than a `.s_popup` snippet.
- Web Editor facts 2:
During the mentioned refactoring [1], they actually added some code to
hide this bug once you were playing with the edit mode (mainly for when
you clicked on the invisible panel element or before saving).
But this code was actually not fixing the case when you just entered
edit mode.
This commit simply remove that "edit only" web editor logic and add a
new one in charge of simply synchronizing the `.s_popup` snippet
visibility with its `.modal` BS modal in a public widget (which is
obviously also executed in edit mode).
Finally:
- note that if there is no way through regular flow to arrive to the
same result with a normal popup snippet, it is still concerned by this
issue and you can reproduce it by moving it somewhere else in the DOM
and/or simply adding it the `contenteditable=true` attribute.
- we already fixed that issue a few months/years ago, I couldn't find
a commit related to that so I don't know if it was due to the same
root cause
- in case one is wondering why we simply couldn't do that in the already
existing `_onHideModal` of the `PopupWidget`, it is because that
`hide.bs.modal` is not called when entering edit mode, because the
`destroy` is destroying it before hiding the modal. The event is thus
not fired. And we can't move the hide part before the destroy's super
because otherwise, it would go through the normal hidden process which
is creating a "seen" cookie for the popup as if it was closed
manually.
[1]: https://github.com/odoo/odoo/commit/740168ce8d27da3d6a7156d2d79655a898394923
task-2754108
closesodoo/odoo#105553
X-original-commit: 21a5e7000f08fbd1936173937c7d90b152a5414f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
Currently entering custom urls will be missing characters if they
contain unicode.
Steps to reproduce:
1. Open Promote dialog
2. Enter a custom url that contains unicode (e.g. `Nội dung có Dấu`)
3. Output: `n-i-dung-c-d-u`
Expected output after this commit: `noi-dung-co-dau`
closesodoo/odoo#105195
X-original-commit: 3c1cd65e2eb44c5d2cb695afad19c58f24bde8b1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Part of [1] was lost during the frontend>backend merge [2].
The SEO name field was not "slugified" anymore in JS, it led to 2
issues:
- Bad UX, one could type something and it would end up after save with
something completely different
- 404/crash: as the generated URL in js (based on the seo name value)
would not be slugified, it would redirect to that URL, which would not
be found as the record URL in python would be slugified. There would
be an URL mismatch between the python route and the JS redirect value.
This could still somehow happen as the JS and PY slug are not doing
the exact same things but at least this will restore what we had
before and mitigate the issue.
Step to reproduce:
- Go to a blog post and open the SEO dialog
- In the custom URL input, type "créé"
- You will be redirected to `/@/blog/travel-1/créé-1`
This will be a 404 page, as the correct URL is now
`/@/blog/travel-1/cree-1`.
[1]: https://github.com/odoo/odoo/commit/c387ec19b4648ae52bf3210253febd7825745627
[2]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 3c266751c41ab0a96494ccd6cd1a1fff3a6a7058
Part-of: odoo/odoo#105195
Guillaume (gdi)