Prevent edition on e-commerce products header bar.
Since we cannot save any change done in the header object anyway,
And some edition would trigger error.
We put the all bar in a read-only mode.
task-2745151
X-original-commit: e2f7b8fad76dc816b2f6864340d3740446117cdb
Part-of: odoo/odoo#91840
There is 2 issues regarding the responsiveness of the cookiebar:
==== Problem n°1: ====
======================
By default, `.modal-dialog` receive a O.5rem margin.
```css
.modal-dialog {
margin: 0.5rem;
}
```
But it only takes effect in small resolution, as starting from SM (576px,
see _breakpoints.scss), the margin is set to 0. `.modal-dialog` receive:
```css
@media (min-width: 576px)
.modal-dialog {
margin: 0 auto;
}
```
On top of that, the `.modal-dialog` has a `min-height` of 100%, which is
getting too big in XS, as there is a 0.5rem margin, which adds up on top
of the 100%
```css
.s_popup[data-vcss='001'] .modal-dialog {
height: auto;
min-height: 100%;
}
```
It results in a modal height bigger than the screen size, ultimately
creating a scrollbar for just a few pixels (2 * 0.5rem margin), making
the cookies bar partly hidden by the screen.
==== Problem n°2: ====
======================
The buttons from the cookies bar "discrete" template are simple `<a/>`
elements inside a `div.col`.
Those links have no bottom margin like a paragraph would have.
In LG screen, it is fine as the col containing those links is next to
the other col containing the paragraph which adds the margin bottom,
making elements not stuck to the bottom edge of the screen:
------------------------------
| COL-LG | COL-LG |
| <p/> | <a/> <a/> |
| | <-- bottom margin set on <p/>
------- screen edge ----------
But in lower resolution, as both col would be on top of each other, the
`<a/>` would be stuck to the bottom screen border.
--------------
| COL-LG |
| <p/> |
| | <-- bottom margin set on <p/>
--------------
-----------------
| COL-LG |
| <a/> <a/> | <-- Against the screen bottom edge
-- screen edge --
======================
Steps to reproduce:
- Install Website
- Enable cookie bar in the Settings
- Go on the Website with a mobile screen width
opw-2784233
closesodoo/odoo#91712
X-original-commit: 843e57694dd73ed4b7fca0460a4cf9b166820843
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Co-authored-by: thcl-odoo <thcl@odoo.com>
This is an attempt at fixing a runbot "race" condition.
A first attempt was done in [1] but the selector introduced to make
sure the page was reloaded after the assets were changed was wrong.
This commit fixes that selector.
During the investigation of the problem, it was also discovered that the
SCSS change could take quite a long time on a busy server becasue it
triggers the SCSS compilation each time.
To reproduce that problem locally, run the `stress` command while
executing the `test_html_editor_scss` test.
E.g.:
```sh
$ stress --cpu 32 --timeout 120
```
The error that shows up in that case is misleading because it makes it
look like the confirmation popup was not clicked on.
What is actually happening is the following:
- the Reset button is clicked on
=> the confirmation popup is shown
- the confirmation is clicked
=> the popup is closed and the RPC call is made
- the RPC does not respond within the tour step's timeout
=> the last step is not shown as succesful and the screenshot shows the
non-reset state since the server response did not arrive yet
To be safe on busy servers this commit also increases the timeouts
related to steps that follow updates of SCSS files so that they can be
recompiled on time.
[1]: https://github.com/odoo/odoo/commit/b35f127c86c1d271a76dae7186a96190e8558c73
runbot-3744
closesodoo/odoo#91725
X-original-commit: e04c4f06086ff4287ef4acfc65d5b3d957396ae7
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit add the way to specify the Plausible shared key auth token and
the plausible domain on your website to have the Plausible Dashboard integrated
in your Website > Dashboard > Analytics menu.
Some custom event are already pre-configured as:
Push an event 'Shop' on confirmation on ecommerce (with amount bucket +/- 50)
Push an event 'Lead Generation' on:
'Thank you' page of contactus
Confirmation of subscription for an event
From this way, the end user can just add a goal 'Lead Generation'
or 'Shop' on Plausible to have the Goal values visible.
closesodoo/odoo#91058
Related: odoo/documentation#2007
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, when searching something via the searchbar snippet
when it is in a mega menu, the dropdown that appears could not overflow
the mega menu dropdown and thus was mostly hidden.
opw-2779432
closesodoo/odoo#91512
X-original-commit: 4805b31e160493715f3c0647b6e8f2d5f6d50c0b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Configuring the email_to field on the contact us page was not working
anymore. The email was always sent to the company email whatever the
user chooses in edit mode. This was due to [1] which gave the priority
to the data-for and prefill system over default values. While this makes
sense in general (e.g. if the URL on the contact us page contains
?name=John, then the form is prefill with "John" whatever the value that
is set as default), it does not make sense for the email_to field which
is always prefilled with the company email.
The data-for/prefill system priority probably has to be reviewed in the
future. Meanwhile, this commit will make the email_to field as an
exception for this system and only use the data-for value if nothing
has been configured by the user.
This commit also handles another case. Indeed "if nothing has been
configured by the users" is currently kinda broken as just clicking on
the form and saving will force the value "info@yourcompany.example.com"
as the email_to value... thus making the form use it instead of the
company email. We will make that as an exception of the exception: use
the data-for value (company email) if what was configured by the user is
the dummy default value "info@yourcompany.example.com".
A test for each of those two exceptions has been added (only the first
test breaks before this commit as [1] made the second test pass by
chance).
[1]: https://github.com/odoo/odoo/commit/7b23d3aacd22f87cb0c22ecd0478eba4a17b4bf3
opw-2842211
Original idea for the first exception:
closesodoo/odoo#91407
X-original-commit: a08574a04ff2ce8ea2d6fd2b79f56cc57bba953b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Ivan Yelizariev <iel@odoo.com>
Before this commit, it was possible to click on the "Create page" button
before the JS was loaded, as that button is a simple link with a href.
But that link is supposed to be handled by the JS which transform the
GET href link to a fake form submit to send a POST request to the
`/website/add` controller.
If the user clicks before the JS had the chance to handle that click and
do the "transformation", the controller will reject the GET request and
a raw 405 error page will be shown.
Now, we wait for the JS to be fully loaded before allowing user to click
on this button.
The fix is made globally as it should be the case of every link related
to this behavior.
Note that the `/website/add` controller was changed from GET to POST
with commit [1]. It most likely forgot to adapt the button from the 404
page which was later done with [2] by using the `post_link` util class
introduced with [3] (for need of website_blog at the time).
[1]: https://github.com/odoo/odoo/commit/714f0aa07f25e8a88a778e8b21c79b48e9801231
[2]: https://github.com/odoo/odoo/commit/2c85c1cb6ee0f6000cd2db182d5b8cfd3d040876
[3]: https://github.com/odoo/odoo/commit/0f2cada32319b3910d6ace6d412cfa94a646c9c7
task-2847785
closesodoo/odoo#91151
X-original-commit: d4a8ec96900c0e0923901bc2672f18aa51b1a9fb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, some images were never appearing on Chrome,
especially when using the 90% zoom.
Steps to reproduce (on a 1920x1080 screen and using Chrome):
1. Edit the homepage
2. Add a "Cover" block and setup a 50% min-height on it
3. Add 2 "Columns" blocks below the "Cover" block
4. Set the width of the first "Columns" snippet's first image to the
recommended size (690px)
5. Save
6. As a public user, set the browser zoom to 90% and go to the page
(you may need to reload the page again so images are in cache)
=> The first image of the second "Columns" block never appears.
opw-2731507
closesodoo/odoo#91075
X-original-commit: e9ef21b6cd5ae58322fa9102f9f34f06835f0485
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
There is some classes that are technical and should not create steps.
Otherwise it compromise the ability to undo/redo or compromise the
ability to detect the dirty elements properly.
This commit prevent thoses classes additions and removals to create
history steps.
task-2836351
closes odoo/odoo#91074
Forward-port-of: #90064
X-original-commit: 41d8a0f246a134e2b5292da4db11e67aa9cfb4ed
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the modifications of the form were not saved if the
user had only clicked on the submit button of the form. Only elements
with the class o_dirty are saved, but since this commit [1], the
observer that adds this class was disabled. The resolution of the bug is
just to remove the fact that the link tool disables the observer that
adds the o_dirty class. This commit also adds a test to make sure that
this bug does not happen again.
Here are the steps to see the bug:
- Go to /contactus page
- Click on edit
- Click on the Submit button
- Change a Form option (eg: Recipient Email, Labels Width, URL, ...)
- Save
Edit again the see that the changes are not saved
[1]: https://github.com/odoo/odoo/commit/c29fe9fa8fc8ff4a5e6f042607ef9b3070d1d339
task-2812722
Forward-port-of: #90064
X-original-commit: 3b45ef633adbeebee4819c30808680644b85c5fc
Part-of: odoo/odoo#91074
*: website
Issue: from 15.0 onwards all image options are available on "/shop".
Details:
On 14.0, images options were removed for unsupported images (we had
a message "Quality Options Unavailable" - see [1]) and images related
options on old editor toolbar were hidden too.
On 14.4 and after [2], images options from the toolbar (crop, width,...)
were moved to a separate 'ImageTools' option and as a consequence, they
don't respect the same visibility rules as 'ImageOptimize'. Other
options were added in XML and they have the same issue, they are visible
as long as the target is an 'img'.
This is a list of options that should be available for unsupported or
partly supported images:
[A] For "t-field" images (shape & quality options are available only if
the image is supported for processing):
- Shape
- Filter
- Width (image width)
- Quality
- Transform (crop)
[B] For external images or images unsupported for processing:
- Description
- Tooltip
- Transform (crop, transform)
- width (CSS width)
- Alignment
- Style
- Padding
- Animate
[C] For illustrations:
- Same as [B]
- Dynamic colors
The goal of this commit is to fix this visibility issue on the JS code
of image options.
[1]: https://github.com/odoo/odoo/commit/84417a174bc2bb76730cc89783d3426a3a3b07d9
[2]: https://github.com/odoo/odoo/commit/d934b81aaae8d68b5579d1489b1fbe8ea347b4ed
task-2724946
closesodoo/odoo#90224closesodoo/odoo#90832
X-original-commit: 8e6ca51ed3ebf121acfc7cb1ab992984d0764c90
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1], that feature was lost because a `_computeWidgetVisibility`
was duplicated inside of the same class. The feature is now restored,
indeed the option does not make sense as animations will always launch
on every dropdown openings no matter the configuration.
[1]: https://github.com/odoo/odoo/commit/187acb938f70a2130d25fa76079221339c742f1e
X-original-commit: bde55751608b1679bd6599238a4da6279b8f74fa
Part-of: odoo/odoo#90832
Co-authored-by: xO-Tx <mou@odoo.com>
Before this commit, the animations were never launched in a mega menu
with the navbar option "sub menus = on hover" enabled.
Indeed the animations are launched when the element to be animated
appears in the viewport according to the scroll. But in the case of a
mega menu we just want the animation to start when the mega menu is
opened. For that we don't need all the code that checks the scroll, etc.
The animation starts by itself when the element inside the mega menu is
made visible in CSS.
A first attempt to fix this was made by this commit [1], but this fix
was wrong. Indeed, as explained above, animations in a dropdown do not
need to be triggered on scroll. And moreover, it didn't work properly
because the animations were never reset when the dropdown was closed.
[1]: https://github.com/odoo/odoo/commit/7a96557b839a69a9d44aac4242af2d21bc7f0e38
opw-2764895
closesodoo/odoo#90826
X-original-commit: bae04041a528e1a1fe97387ca5b75943c1d0fe97
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Currently, if a page is loading and someone quickly clicks exactly on
the input checkbox within publish management button of website navbar,
the checkbox (input) is toggled but the string does not change.
This happens because the checkbox is toggled before the click event on
`js_publish_btn` is bound. Ideally, the checkbox should be toggled only
based on the state of the object (whenever it's changed after a
successful RPC call) so that the information we see is correct.
This commit fixes the issue by disabling the input checkbox so that
it is toggled only after the state is changed by RPC call and not
when user simply clicks on the input. Apart from that, now we toggle
`css_published` and `css_unpublished` based on the state of RPC so that
the button strings are always consistent with the checkbox.
task-2819345
closesodoo/odoo#90550
X-original-commit: 86225a7f00ae90463570221e87ace5212fb71dba
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This is an attempt at fixing a runbot race condition.
It was executed succesfully without any error on Multi build around
200 times on runbot.
Since [1] the reset button could be clicked before the HTML editor was
reloaded.
The `MutationObserver` in `tour_service.js` is debounced. Because of
this the states used to detect tour steps triggers might differ between
executions.
With the Reset button of the HTML editor not being hidden in the
rendered template, it might be detected before it gets hidden during
the `start` of `ace.js`.
This commit makes sure the the editor is both closed then reopened with
the Reset button visible before clicking on it, and also makes sure the
Reset button is not visible by default upon rendering.
[1]: https://github.com/odoo/odoo/commit/d20468c3463927a54c34688769a22b3949c5c465
runbot-3674
closesodoo/odoo#90453
X-original-commit: b35f127c86c1d271a76dae7186a96190e8558c73
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The isDirty method of the wysiwyg was not very accurate
and was most of the time returning true
even if no changes were done in the editor.
task-2692125
closesodoo/odoo#90200
X-original-commit: bab673488e185ddd7792aedecc3870663290fed3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, some editor options could break the autocompletion
of form fields. This commit ensures that auto-fillable fields remain
auto-fillable when using the editor. In addition, this commit improves a
test to ensure that this bug does not reappear.
Steps to reproduce the fixed issue:
- Go to the "contact us" page or drop a form in a page
- Edit an auto-fillable field of the form ("Your Name" for example)
- Change the label position of the field
- Save
-> The field is no longer auto-fillable.
task-2715201
closesodoo/odoo#90103
X-original-commit: 455e0cc58c7fa1e02ebaa19dd2f99d829ca6e302
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit allows to give priority to auto-fill values and to values
coming from a data-for when in addition to one of these values this same
field has a default value. The form's test are also improved so that it
checks for this desired behavior.
task-2715201
X-original-commit: 7b23d3aacd22f87cb0c22ecd0478eba4a17b4bf3
Part-of: odoo/odoo#90103
Some form fields are dynamically filled. As the inputs that hold these
values do not always have a value property, their HTML value attribute
can be modified. Before this commit, the form option had to remove these
values before saving so that these values wouldn't become default values
(see [1]). Sadly this system is problematic and can remove default
values set by the user. This commit ensures that only values from
auto-fillable fields and from data-for fields will be removed and from
now, the suppression of these values is done at a more appropriate time
than what is done in [1]. Test is added with this commit to verify that
the default values are not erased on later form edit.
Step to reproduce the fixed issue:
- Create a form, add a (required hidden) field with a default value
- Save, then enter edit mode again
- Add a new field and save again
The default values of the form are gone. Enter edit mode again to see
the hidden input, you will see there is no value.
[1]: https://github.com/odoo/odoo/commit/b637a5e32f767b62736241042f88fa0cecf9f10b
task-2715201
X-original-commit: 043e1fdf923d2037dd8da128ab99388f0c92e544
Part-of: odoo/odoo#90103
* web_editor
Prior to this commit, removing a snippet while its widget was still
active could lead to slow removal as editors would be created for its
inner content.
Stopping a widget before removing it is good practice as it will clear
the DOM from any content it may leave behind and will prevent snippet
editor to be created for its dynamic inner content.
As an example, the `Products` snippet had SnippetEditors being created
for its product cards, which could lead to slow removal especially
in later versions of Odoo. E.g. in 14.0, because ImageTools were
introduced.
Closes#85464
task-2781418
closesodoo/odoo#90100
X-original-commit: ca1359e0f40b94b93eb8cfd6834a05796f64c675
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
For some unknown reason (part of a huge refactoring during the BS3 to
BS4 migration at [1]), a background color was applied to the <header>
(behind the navbar) once it becomes fixed (after scroll if the related
header scroll effect has been chosen).
That $light color made no sense as is visible if the header uses rounded
corners but is impossible to edit / remove.
This commit, for master, simply removes it. This is not possible to
migrate (for example to try and handle the case where the menu color is
transparent) as it would require to know the color of $light. It would
be overkill anyway, this just relies on users with that problematic
transparent header (probably nearly no one) to review their header in
the next Odoo version.
[1]: https://github.com/odoo/odoo/commit/09f40036b9c14161db90c6128861369c91c8c64e
opw-2686695
closesodoo/odoo#90058
X-original-commit: f721e6187933cde4366a7f987fb80612da581670
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The autoplay option for youtube videos in a .media_iframe_video snippet
does not currently work on mobile devices. This happens because the
autoplay param in the url is only considered for desktop devices.
Mobile autoplay can be forced by using the youtube js api, in the same
way as it is already done for background videos. Therefore, the common
code is extracted into a mixin, extended by both widgets.
opw-2607308
closesodoo/odoo#89439
X-original-commit: 83972aa28957414d53c69bb41ce36646891a829e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Current behavior:
When an admin user modified a file with the HTML/CSS/JS editor in a
website, users that had "editor and designer" right couldn't access
the HTML/CSS/JS editor anymore.
Steps to reproduce:
- Have user 1 (U1) admin
- Have user 2 (U2) with website access set to "Editor and Designer"
- U1 modify the css user_custom_rules.scss with the HTML/CSS Editor
- U2 can't open the editor of that website because he is not in the
setting groups or the one that created it
opw-2733109
X-original-commit: d20468c3463927a54c34688769a22b3949c5c465
Part-of: odoo/odoo#89211
Co-authored-by: roen-odoo <roen@odoo.com>
Since [1] nested menus were not saved anymore because model ids do not
support `str` anymore.
After this commit the menus update data contain an integer `parent_id`
making them understood again by the model.
The `parent_id`s returned by `nestedSortable()` are the ones obtained
through a regex match, and therefore are strings.
Steps to reproduce:
- go to the 'Home' web page
- click on 'Edit Menu' in the 'Pages' menu
- drag and drop a menu item to nest it (e.g. put 'Contact Us' inside
'Home')
- click on 'Save'
=> nested entry disappeared from the menu instead of being nested under
its parent
[1]: https://github.com/odoo/odoo/commit/534087fa8d3c9947a918aa109f4030b5628a80d1
task-2781260
X-original-commit: d7bfb935580d6cc70dc213657c1a6dbc85dfa756
Part-of: odoo/odoo#89147
Before this commit
The items of the megamenu were not saved after being translated
After this commit
The items of the megamenu will be saved after being translated
task-2810332
X-original-commit: d159e7ffd30645d346a8a04ca281a728878c83ed
Part-of: odoo/odoo#89071
Before this commit, this bug was present in edit mode:
- Go into edit mode on an empty page.
- Click on the THEME tab on the right.
- Click on the empty "DRAG BUILDING BLOCKS HERE" area.
- Click on the THEME tab again.
- The content of THEME is empty.
It was because since this commit [1], clicking on an 'oeStructure'
activate the Blocks tab but without updating the options in the tabs.
Another similar bug was present when clicking the style tab and then
clicking on the theme tab.
About the first bug, actually a call of '_updateRightPanelContent' is
already done in '_activateSnippet()' (and the Blocks tab is activate by
default) so we only have to use '_activateSnippet(false)' to activate
the Blocks tab. This commit also remove '_updateRightPanelContent' from
the click event of the Blocks tab where it was not necessary.
For the second bug, we can't do the same fix, because it's not possible
to activate the options tab with only '_activateSnippet(false)' so we
had to combine the two functions.
[1]: https://github.com/odoo/odoo/commit/fbe048c202ff7878984adf26bef0651a45851f0a
task-2794266
closesodoo/odoo#88537
X-original-commit: 52d32e26c34bef10823582ef5c1f840492b73d7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1], when editing cover texts only and saving, the cover
properties values (background, size, etc) were lost. This is because
we prepare the values to save only when one of them is edited... and
editing the cover texts is marking the cover as dirty thus without
the prepared cover properties values.
After this commit, the cover properties in the database are only updated
if the cover is marked as dirty *and* the values to save have been
prepared.
[1]: https://github.com/odoo/odoo/commit/ad59cbd33e0eaf5c7c77f9e5c0b0435917e2c155
task-2792006
X-original-commit: dffe8d2f8809a3e8e841bea1f2164fa42b578906
Part-of: odoo/odoo#88482
As social medias can no longer be d-none in the DOM, some code can be
removed from the social media snippet option.
task-2739937
closesodoo/odoo#85476
Related: odoo/upgrade#3292
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
During edit mode, editing the social media snippet induced losing the
whitespaces between the social media icons, thus reducing the space
between them. That space was however restored after saving.
After this commit, after each social media snippet change, we restore
a line break whitespace between each social media icon.
task-2739937
closesodoo/odoo#87933
X-original-commit: 3b8f11273bfa926172a4297785e58dfea92728d9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit replaces the thumbnail for the social media block. The
previous one was a duplication of the facebook thumbnail.
task-2739937
X-original-commit: f10c16948095fb1590decf7d7c2428993d2829d7
Part-of: odoo/odoo#87933
Co-authored-by: @Guillaume-gdi <gdi@odoo.com>
This commit permits to:
- avoid DOM modification when starting options of social_media.
- remove the useless HTML related to the social media block.
- generate all available social networks that are present in the DB for
the social media block.
- delete DB social media if there is no value for it in the DB.
- display an alert banner in edit mode if the block has no link.
- use a shared variable for social media db urls in order to avoid too
much RPC.
- custom links are no longer togglable, only deleteable.
task-2739937
X-original-commit: f243bcbafb9291d94840795951c8fd51cab0cae1
Part-of: odoo/odoo#87933
This commit permits to detect social media urls even if it's just the
domain name. Moreover, the icon detection is more accurate.
task-2739937
X-original-commit: 1045118985a7a04de47da6f1a4360e1eede84e34
Part-of: odoo/odoo#87933
This commit permits to check if the urls of the social media links start
with a correct protocol, if not, we correct it with https protocol.
task-2739937
X-original-commit: 7779d36749c5dd9d60f94985eefdbbe06ea2d818
Part-of: odoo/odoo#87933
Before this commit and since [1], there was an issue regarding the
group feature on the page properties dialog.
When a page visibility is set to restricted groups, and that more then
one group is required, a link would be displayed to edit the page's
view in the backend. That link was hardcoded, always pointing to the
same view.
[1]: https://github.com/odoo/odoo/commit/e239934abe456257c9dc285d1ad9829c0353900c
task-2800685
closesodoo/odoo#87549
X-original-commit: 9c7a540ddb3e23d847bd1564274b76d8426b2732
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit
The code called `action_demand` without specifying a failure
method.
In website, there is bug arising where a promises is not rejected
causing spinner of the sidebar of the website builder to never stop.
After this commit
Failure is propagated and the website builder bug does not prevent
the user from continuing to work.
closesodoo/odoo#87125
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet <age@odoo.com>
The bold format is overridden to use inline style on a <span> rather
than a <b>. The other formats (italic, underline, strikethrough)
continued to use the default browser behavior. This harmonizes them.
X-original-commit: ce59bbd1c13d7fd4cc6971b89cc95386d95fcd75
Part-of: odoo/odoo#86930
When clicking on readonly stat button (website related), it would
sometimes raise a traceback since there is no action to redirect to.
Step to reproduce:
- Go to Website > Visitors > Visitors
- Select a Visitor to enter its form view
- Now, either:
A. Enter edit mode
B. Enter edit mode and discard (or save)
- Click on stat button
This will raise a traceback, since the `disabled` property is now gone.
Indeed, the framework is adding/removing that attribute when entering
or leaving edit mode.
See disableButtons()/enableButtons()` called by
_setEditMode()/_onDiscard()/..`
Note:
- With the new framework/owl, there is no TB as the `disabled`
attribute is not removed anymore.
- In 14.0, there is no issue despite the `disabled` attributed being
removed.
Fixes#78500Closes#80884
Courtesy of @odooaktiv
closesodoo/odoo#86552
X-original-commit: e8882fb745d140eb8d4385b7a1d0f754c78453ab
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Purpose
=======
Add "Activate" button when selecting multiple languages, select multiple
languages when clicking on "Add languages" in settings.
Specifications
=============
`lang` variable in `base.language.install` changed from Selection to
Many2many to allow multiple languages being activated at once.
Hide globe icon for language fields from view mode (only visible when
editing). Remove state in base.language.install since it's no longer
need to keep track of the installation step.
Task-2662548
closesodoo/odoo#78287
Related: odoo/upgrade#2921
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since [1] only floating fixed headers were included in the calculation
of the `dom.scrollTo()`'s offset.
Because of this when a snippet was dropped on the top of a page, the
header being shown but non-floating was not used in the offset
calculation, which made the automatic scroll operation hide the header
partially for headers taller than the requested 50px offset from the top
of the display.
After this commit, any shown header is included in that calculation -
even non floating ones.
Steps to reproduce:
- drop snippets into the page until it has to scroll
- drop a snippet right below the header
=> header was partially hidden upon drop by the automatic scolling
[1]: https://github.com/odoo/odoo/commit/ee47bd9ce0da526ea5b3387a354ab8fbd06cc55f
task-2765820
closesodoo/odoo#86038
X-original-commit: f3e51a7beb4b0d4ccb6a883d2c53bd303e94a200
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With commit [1] and its parent ones of the same PR, some OWL Component
became LegacyComponent, and some were adapted to work without the
previous Component compatibility methods. The theme selection component
was forgotten.
Steps to reproduce:
- Install website with themes repo
- Go through the configurator flow and select a theme
- A traceback appears and you cannot complete the flow
This commit loads the rpc service in the ThemeSelectionScreen component.
[1]: https://github.com/odoo/odoo/commit/b81861233d7a3911d4dfe53b33469ee0d951ad04closesodoo/odoo#85859
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before fixing a bug occuring in this file in a next update, let's fix
linter errors and make it a bit prettier. Note: it will be refactored
in the big website backend refactoring.
Part-of: odoo/odoo#85859
This commit will adapt website's topmenu icons in order to be a
consistent with the backend.
It also solves a minor layout issue for '.o_menu_brand' that was
rendered incorrectly in enterprise.
Part-of: odoo/odoo#85651
All named arguments on the catch block must be used. If for some motive
the named argument on the catch block is not used, its name must begin
with '_'.
closesodoo/odoo#85569
Related: odoo/enterprise#24867
Related: odoo/design-themes#552
Signed-off-by: Géry Debongnie <ged@odoo.com>
Nicolas Bayet