The `o-bg-color` mixin was used to color the mobile navbar: it was
useless. First, in general, `o-bg-color` should rarely be used:
`o-apply-color` is best as it will call the other one when needed. Then,
this comes with many extra rules to color the text, inner subtitle, etc.
All of those rules are already inherited from the parent navbar: we only
want to re-apply the background-color on a sub element (the mobile
navbar) in this case.
Part-of: odoo/odoo#141198
In many situations, when you click on a button, you want to disable all
the other buttons while it is running.
Currently, in each of these situations, we duplicate the same code that
disabled all the buttons and enabled them afterwards. Unfortunately, in
many cases, if the code executed crashes, the buttons are not enabled.
In this commit, we're going to create a helper so that we have a single
version of the code that correctly handles crashes. This helper will
disabled all the buttons, then execute the click code and enabled all the
buttons afterwards. If the code crashes, it will also enbaled them.
The problem has been reported for the Settings Form view:
When you edit this view and click save, if an error occurs in the save,
all the buttons remain disabled.
closesodoo/odoo#140938
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The text and links in the header configurations were always the root
elements that were editable. For them to be properly editable, we need
their container (at minimum) to be the root editable element. Indeed,
on root editable elements, only the class and style can be changed (if
not dynamic). But changing a link requires to change the href, the
target. Changing a text style requires to change the tag entirely, etc.
For this to work, the `_link_class` configuration was removed, it was in
fact mostly useless and actually even breaking some layouts. So doing
this fix actually improves the design as well. For the layout were it
made sense, it actually became useless by refactoring the templates.
This was necessary anyway for texts which did not use `_link_class` but
were root editable nodes anyway because of the `t-if` conditions laying
around.
closesodoo/odoo#140869
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The configurable text in the header templates has a `_link_class`
option which sometimes was set to add the "nav-link" class on the
links in the default header texts... but that class was already there
no matter the config.
This removes the double class addition.
Part-of: odoo/odoo#140869
This commit reduces the padding of the website loader to prevent too
much line breaks of the text.
task-3557675
closesodoo/odoo#138921
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds a fake loader during website install. [Another commit]
already added a loader during extra module install. The goal here is to
have a loader even if there is no extra module to install. This should
make the user think the install is faster and prevent him from leaving.
This commits also improves the loader when there are extra modules to
install. We split the loader in two parts: one for the modules install
(70%) and another for the rest of the install (30%).
Note that to test this feature properly, you need to be in a multiple
workers environment.
[Another commit]: https://github.com/odoo/odoo/commit/ab6564be94533a64a0a942202f0860423ec7dc4d
task-3557675
Part-of: odoo/odoo#138921
Since [1] when the generation of missing configurator templates and new
page templates was introduced, `_load_xmlid` was called for every
generated record so that `_process_end` does not delete them after a
module update.
Unfortunately, this trick does not work when using the "Upgrade" command
on the Website app in the Apps view. (or calling
```py
env['ir.module.module'].search([
('name', '=', 'website')
]).button_immediate_upgrade()`
```
from the shell): in that case, the `self.pool` onto which the xmlids
were registered was a different instance from the one accessed by
`_process_end`.
This commit avoids this problem by making the generated templates
`noupdate: True`, thus preventing `_process_end` from deleting them.
Steps to reproduce:
- Install website with -i
- Go to Apps, search Website, upgrade Website
=> In the logs you can see that some templates are deleted at the end of
the upgrade
- Website configurator: a business website, furniture store, get leads,
choose a palette, about us + services + pricing + privacy policy,
choose the center template (loftspace)
=> You see some crash in the logs
[1]: https://github.com/odoo/odoo/commit/a2f8e18b76e52e1a349b77691d0af18edc09a1beclosesodoo/odoo#140986
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since commit [1] removed `legacyRejectPromiseHandler()`, trying to edit
a link leading to an HTTP error triggers an "Uncaught Promise" error.
This commit makes sure such links do not cause a traceback: the link
popover is just less detailed (no title, favicon).
[1]: https://github.com/odoo/odoo/commit/fcb16a3b1bd373726ffb54f0fbe41fb6d1784769
task-3584686
closesodoo/odoo#141225
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since this fix[1] of the overlapping. The `UrlAutocomplete` wasn't
working as expected, The `AutoCompleteWithPage` dropdown is displayed
behind the dialog when it was inside a dialog.
Steps to reproduce:
* Open the `Website` app
* Click on `Site` > `Edit Menu` > `Add Menu Item`
* Start to type in the url field, the dropdown is displayed behind the
dialog. => bug
Link
[1]: https://github.com/odoo/odoo/commit/9682cfa174fb39ec9d9874951ea9ee2884058d96closesodoo/odoo#141159
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Steps to reproduce the bug:
- In website edit mode, drag and drop an 'Image-Text' snippet onto the
page.
- Click on the button in the second column of the snippet.
- Type "/" in the URL input of the link options in the customize panel.
- Open the 'Page Anchor' selector and select the '#top' anchor.
- Bug: The anchor is not added to the link in the URL input.
The bug was introduced by this commit [1]. Indeed, the events in the
'Start' of LinkTools were no longer attached to the main element but
directly to the event target. This means that in this particular case
where the 'we-button' elements are created after the 'Start', the click
event had no effect because no event was properly attached to it.
This commit also includes test steps to prevent this bug from
reoccurring in the future.
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
task-3580414
closesodoo/odoo#141034
X-original-commit: 72eb761545c51c9dc7c6490c0ce0e38650dfa985
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
When creating a new website through the configurator, the images that
will be used on the website will be the one specified by the selected
industry.
We recently introduced 2 new images with commit [1] for which the
industries have no images set as we did not have time to do it.
It would require going through the ~4000 industries and finding a
relevant image on Unsplash for it.
This commit is simply using another existing set image instead.
Indeed, if an industry hasn't set an image, the theme one will be used
instead, which is less ideal.
Step to reproduce:
- Create a new website
- Select "Garden furniture store"
- Select the Orchid theme (the one in the middle to this day)
- Drag & drop the Banner snippet, 2 out of the 3 images used in this
snippet will use the theme images (images about flowers) instead of
images of furniture (related to the selected industry)
[1]: https://github.com/odoo/odoo/commit/3cbdf754ff8fac8a77887c4307b658cb86b0be1dclosesodoo/odoo#141117
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Add a form on the website.
- Add two fields on the form ("A" and "B").
- Change the conditional visibility of "B" and put it to "Visible only
if".
- Change the label of "B" and set it to "A".
- Try to change the dependent field.
-> "A" is still on the list of the eligible dependent fields. It should
not be the case as setting this field as a dependent field would create
a circular dependency.
To solve the problem, the file visibility selector is rerendered after
modifying a field label. Because of the `_findCircular()` check at the
rerendering, the problematic field will not be displayed in the list of
of the eligible dependent fields.
task-3291044
closesodoo/odoo#140928
X-original-commit: 788218dff61e65f2213c31ebc660183ef3e73087
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Steps to reproduce the bug:
- Drop a "Form" snippet on the website.
- Change the "Label" of the first field (and put it to "test" for
example).
- Select the last field and change its visibility so that it depends on
the first field.
- Change the "Label" of the selected field and put it to the same than
the first one ("test").
- Save.
-> Traceback "Maximum call stack exceeded" appears.
At the end of the procedure, the last field visibility depends on itself
and a circular visibility dependency is created. To solve the problem,
this commit checks that the renamed field does not bring a circular
dependency while updating the dependencies. If it is the case, the
problematic dependency is deleted.
To resolve this bug, the `visitedFields` set has been introduced. Its
goal is to register the already visited fields to not enter an infinite
check loop. Let's take an example to illustrate this: Imagine there is a
form of type A->B->C->D. In this form, the field "A" depends on "B" that
depends on "C" that depends on "D". Imagine you rename "D" by "B". You
now have A->B->C->B. The system will check that the renamed field does
not create a circular dependency. To do so, it will apply
`_recursiveFindCircular` with "A" as the `targetFieldEl` and "B" as the
`dependentFieldEl`. Because there is a circular dependency between "C"
and "B", the system would enter in an infinite loop. Note that we do not
notify the system if such indirect circular dependency has been found as
it will be detected as a direct circular dependency while the system
will apply `_recursiveFindCircular` with `C` as the `targetFieldEl`.
task-3291044
X-original-commit: 5f0b62fc30867e03e69a824d5e426bf3f74c8ff5
Part-of: odoo/odoo#140928
Steps to reproduce the bug:
- Drop a "Form" snippet on the website.
- Add three fields and rename them by "a", "b" and "b".
- Change the conditional visibility of the first "b" and make it depend
on "a".
- Change the conditional visibility of "a" and make it depend on "b".
- Save.
-> Traceback "Maximum call stack exceeded" appears.
A field with a conditional visibility is visible if at at least one
field with the dependency name is visible. The problem is that in our
case, it exists a circular dependency between "a" and one of the "b"
leading to an infinite loop during this check. Before this commit all
the fields of the form were checked and all the labels of the fields
that do not create a circular dependency were proposed in the file
visibility selector. The problem is that in our case, one of the "b"
field does not create a circular dependency while the other does. To
solve the problem, the `_recursiveFindCircular()` function has been
adapted in order to not propose a label that would create a circular
dependency in the file visibility selector.
task-3291044
X-original-commit: f010b128be29e884c89dd58f1c575a163e229d5b
Part-of: odoo/odoo#140928
There is a visual "glitch" in the website builder, there is a 2px white
bar (2x1px border) at the bottom of the screen in edit mode.
Steps to reproduce:
* Enter edit mode on a page
* Drag & drop a few snippets to have a scrollbar
=> The bottom white bar appears
closesodoo/odoo#140979
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Since we remove jQuery UI[1], the owl component `AutoCompleteWithPages`
doesn't work correctly on Safari.
When we clicked on the `AutoCompleteWithPages` input the code in the
`AutoComplete` component `onFocus` make a selection on the input of the
`AutoComplete` component and not on the `AutoCompleteWithPages` input
this make a unwanted effect such as blur the clicked input and focus
the other input. This commit fixes that.
Steps to reproduce:
* With Safari, open the `Website` app
* Click on `Site` > `Edit Menu` > `Add Menu Item`
* You can't type in the url field and if you spam click on its.
Sometimes, it produces a browser crashes
Links
[1]: https://github.com/odoo/odoo/commit/99f5ae32d3ee4a3dcc75e31ad0a88f42d6ce3589
Part-of: odoo/odoo#140979
Prior to this commit, on mobile, we couldn't see the entire offcanvas
menu because the browser's UI was hidding part of it.
To fix that, this commit adapts the height of the offcanvas menu using
`dvh` unit.
task-3582657
closesodoo/odoo#141032
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This PR refactor the "inputs design system" by reverting the correlation
'$input-bg == $light == color-3', initially introduced by #120302.
Beside ensuring color-consistency, the former system aimed to simplify
palette edition by clarifying how color-3 was used (simply all the UI
elements...).
While the former system was responsive to user customization and
color-presets, it didn't necessarily delight everyone's discerning
taste, at least not with default settings/palette.
This commit enforces a classic "white with borders" design that's
independent from the color palette and doesn't adapt to color-presets.
The rationale behind this decision is that the need for non-white inputs
is "nonexistent" and exceptional cases should be addressed using the
SCSS editor.
As a workaround to ease edition for users that still wants to challenge
themselves with the creation of "not standard" palettes/designs, this
commit introduce a colorPicker option assigned to $input-bg.
The hope is that this new controller help users finding a "compromise
color" that could work with any color-presets.
task-3568806
closesodoo/odoo#139642
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When introducing the templates for the "new page" feature in [1], on
some elements classes ended up being specified twice, or being added
without removing a contradicting class (e.g. different bottom paddings)
This commit adjusts the blocks of the new page templates so that:
- no class appears twice
- only the visually applied class of several conflicting classes is kept
For `pt*`, `pb*` and `o_cc*` the class with the highest number is the
visually applied one.
[1]: https://github.com/odoo/odoo/commit/b27d52c193a08fe6a4471c844afa3d01a33ccace
task-3562147
closesodoo/odoo#139572
Related: odoo/design-themes#731
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [this PR], some headers have some preselected options. For
instance, by default the header_sales_one displays social icons without
colors and a CTA button with rounded sides. However, if one modifies the
option in the panel, it appears to be working, but upon save it goes
back to no_icon_color / rounded sides.
This happens because the option is forced by the header template. That
behavior takes the precedence over the user's option choice.
As there is no proper way to make it work without modifying the model,
this commit removes the forced option on the templates for Odoo 17.
It should be properly reintroduced in master.
[this PR]: https://github.com/odoo/odoo/pull/119650
task-3576074
closesodoo/odoo#140669
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This follows [commit 1], which introduced a way to separately reorder
columns on mobile and desktop.
This commit replaces the custom mobile order classes with the Bootstrap
`.order-x` classes.
It also ensures those orders are not used for mass mailing in case the
editor composes their email on a small window. The reorder would indeed
not have any effect for the end users in such a case.
[commit 1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba
task-3576046
closesodoo/odoo#140362
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Since [1] when the layout of the theme options was reorganized, the
button's font-family option was not displayed anymore.
This commit restores the button's font-family inside the "Button"
section, before the button "Padding" options.
[1]: https://github.com/odoo/odoo/commit/388e4bb2bfcaebdd4ff30277fb49a034592d7086
task-3478355
closesodoo/odoo#140692
X-original-commit: 718ae15606fe452da26fe9c4fa9c90cc443fd8f1
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Whenever calling `_adapt` in `autoHideMenu`, whenever the odooEditor
is active, some mutations could trigger the unbreakable rollback of
the odoo editor. We should not check for unbreakable in `_adapt` as
the unbreakable mechanism is not meant to be used in that context.
task-3439226
closesodoo/odoo#139209
Related: odoo/enterprise#49220
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Previously, we attempted to debounce in what appeared to be an override
of the onWillStart method, but this method doesn't actually exist on the
parent classes and as such is never registered with the onWillStart
hook. This commit fixes that by registering it in an override of the
setup method instead.
task-3439226
Part-of: odoo/odoo#139209
Adapt the website industry selection autocomplete inside the
configurator to use the autocomplete owl component instead of jquery
autocomplete
task-3439226
Part-of: odoo/odoo#139209
*: web, website, website_form_project
Remove the jQuery UI Widget `urlautocomplete` by using made some
refactor to allow usage of the owl component.
task-3439226
Part-of: odoo/odoo#139209
This commit sets `s_text_cover` default color preset to `o_cc4` to make
it look more like the header of "Anelusia theme" that was the initial
reference for the design of this snippet.
It also fixes a typo in `o_ccx` class introduced in commit [1] at the
same time actually.
[1]: https://github.com/odoo/odoo/commit/5ac340b1b27c9527463e2eed65fe2e7768b36702
task-3568868
closesodoo/odoo#140721
X-original-commit: 66f63ab23159fae86ba81369287e1cf8aac66d87
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This rearranges the non-floating toolbar buttons so that the AI, animate
and highlight buttons are grouped together at the bottom and take up the
full width of the toolbar, and so that the options appear below them.
task-3572337
closesodoo/odoo#139857
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Steps to reproduce the bug:
- In Website edit mode, drag and drop an "Images Wall" snippet onto the
page.
- Click on the first image of this snippet.
- In the "Animation" options of the image, select "On Hover".
- Save the page.
- Click on the first image of the "Images Wall" snippet.
- Bug: The image in the slideshow still has the overlay that appeared
due to the hover effect.
This commit fixes this issue by resetting images to their original
source in the slideshow.
task-3562305
closesodoo/odoo#139695
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Prior to this commit, the button with the search icon, inside the search
bar, was `primary, which is not consistent with the filters that are
`light`.
Part-of: odoo/odoo#137729
Prior to this commit, when you removed a social link in the header,
there was an error.
This is because `website.header_social_links_no_color` targets selectors
that do not exist in this situation.
task-3572219
closesodoo/odoo#139883
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website, web_editor, website_sale
The goal of this commit is to replace all Dialog in the Website Editor
flow with OWL Dialog. This uses the new `bindService` and `call` methods
available on legacy widgets. The replacements mainly use the
ConfirmationDialog component, but some had to have custom-made dialogs.
closesodoo/odoo#138947
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
This code was use in 14.0 to allow users to edit the Company Information
visible on the /contactus page. It is no longer needed as the page is
now fully editable and the t-field has been replaced with static text.
Part-of: odoo/odoo#138947
In this commit, we will remove "closestScrollable", "compensateScrollbar"
and the last usage of "scrollFixedOffset" outside of dom.js.
closesodoo/odoo#140181
Part-of-task: 3439226
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
-> This commit add/change the name of the page corresponding to the string
attribute because To be able to detect a field, Knowledge needs to be able to
read its page name.
For more reference: Task-3501211
Task-3524474
closesodoo/odoo#137428
Related: odoo/enterprise#48315
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit introduces some adjustments to the dark mode color scheme
and the use of bootstrap classes in Community.
- Mini calendar contrast -
The colors were not using variables, making them non dynamic
and breaking the contrast in dark mode.
- Avoid !important rules spreadsheet -
Prior to this commit, spreadsheet top bar was using a `bg-white` class,
making it pure black in dark mode.
Since spreadsheet is designed with light colors and we don't provide a
dark mode for it, we remove that class and set a `background-color`
property using CSS in Enterprise.
- Input color -
This commit fixes the focus behavior on the searchbar in the control
panel, the `command_palette_search`, and the `start a conversation` in
discuss.
- Copy clipboard field border color -
Make use of the `text-primary` color for the copy to clipboard field
We use the o-theme-color function to avoid an undefined since primary
doesn't exist in the o-theme-text-color map in white mode.
- Web_editor toolbar variables -
The toolbar was using the `o-brand-primary` variable
which was set to a darker shade. This caused issue when activating an
option due to how vibrant the color is.
- Improve the controls on border-color -
Introducing a custom property on the border-color to allow
further control on individual components (such as the popover).
- Improve setting tabs colors use -
Prior to this commit, the colors of the settings tabs menu were kinda
inverted. The menu was light in dark mode and dark in light mode.
We fix this by changing the values associated to the CSS variables in
use.
- Make model field selector dark mode proof -
Fixing the design of the model field selector popover in both
light and dark mode. Since the popover was using custom style with
arbitrary values, it was not designed for the dark mode and had a lack
of consistency.
To improve the design, we use variables rather than custom style, and
make sure the desired render is as close as before.
- Sign colors use -
This commit aims to improve the sign module in both light and dark mode.
There were some readability issue with some `btn-light` having poor
contrasts in both light and dark mode, and the use of some classes was a
bit unexpected (e.g `card-header` to set a grey background with some
padding).
- Improve buttons design inside listview -
Prior to this commit, this button was using custom CSS to make it look
like a primary button, while it was using classes related to secondary
buttons.
We remove the custom CSS used to style it correctly and keep our button
design consistent.
- Messaging menu layout in mail -
This commit aims to improve the design of the notifications displayed
in the messaging menu. Prior to this commit, the notifications dropdown
was using custom CSS variables overriding the regular behavior
of our dropdowns.
In fact, the layout was generating some friction:
1) Marking a notification as read would turn its background into a
darker color
2) Effects like `:hover` were all based on the custom CSS variables
resulting in an inconsistent layout.
- Multi company selector adaptations -
In darkmode the multi company selection was using the btn-light which
creates a weird effect and overrides the dropdown default hover behavior
This commit uses the btn-link to display an hover effect on the
company switch and on the checkbox while blending with the background
and the default dropdown hover effect.
- Adapts default badge design -
Improve the design of the default badges in dark mode.
If you open the light mode, these badges are dark grey with a white
text. If you switch to dark mode, they are dark grey but with a dark
text, which makes them look either muted or off.
We make use of SCSS variables to handle the color of the component,
providing a good styling in both modes.
- Fix kanban cards borders inside dropdown -
Fixes the issue with the divider inside the kanban dropdown menu not
showing in dark mode.
To ensure it is visible, we assign it the `$dropdown-divider-bg`, which
is the color it should use, as the horizontal divider above uses.
- Fix tour pointer design for dark mode -
This commit aims to insert the tour pointer and its content inside the
styling we applied to our tooltip.
To do so, we make sure it uses CSS variables, allowing more control and
consistency, plus we replicate the overall look of our tooltips.
- Fix `text-primary` on action background contrast -
This commit improves the readability of our `text-primary` classes when
it's used on a `$o-component-active-bg` background.
Prior to this commit, the `text-primary` was not meeting the contrast
standard, mainly when you were using the `CMD+K` shortcut on the
app switcher.
To prevent that, we changed the background to a `$o-component-active-bg`
background with an opacity ensuring our text provides a good contrast.
- Fix input states -
Prior to this commit, the `--o-input-border-color` CSS variable was
using the `$o-form-lightsecondary` variable to define the standard color
of the `border-bottom` property of our inputs.
This was conflicting since `$o-form-light-secondary` is also used to
define the `background-color` of our table on focus.
With this commit, we separate these two element with different variables
to make sure they don't affect each others.
- Fix kanban ghost background -
Before this commit, if you created a project without any stage or element
in it, the ghost cards that act like placeholders would be pure `#000` in
dark mode, due to the `bg-white` class.
This commit replaces that class with a `bg-light`, providing a better
visual result in both light and dark mode.
- Fix new message design -
Improve the design of the new message element while
inside Discuss, using our danger color, ensuring a good visual result in
both modes.
task-3201038
closesodoo/odoo#139966
Related: odoo/enterprise#49666
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: chgo-odoo <chgo@odoo.com>
Co-authored-by: stefanorigano <sri@odoo.com>
Steps:
- In website, click on a link to edit it
- Type "/" in the LinkTools URL input field
- Pick a URL among the suggested ones
The chosen URL was supposed to be applied to the link, but it is not.
The same applies for the LinkDialog (create a link with the "/link"
command).
Reason:
It might be a little confusing, but the `_onURLInput` method actually
means "update UI according to the URL" (more specifically, display/hide
the "Open In New Window" and "Autoconvert To Relative Link" buttons).
The `__onURLInput` (two underscores) method, on the other hand, is the
actual handler for input events in the URL field. In this case, picking
a URL from a drop-down menu needs the same treatment as inputting text,
that is, the `state.url` property must be set to the new value.
task-3552700
closesodoo/odoo#140061
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
This commit fixes two bugs with the sidebar header.
Steps to reproduce the 1st bug:
- Go to "/shop" and edit the page.
- Click on the header.
- Open the header selector.
- Choose the "sidebar header".
- Bug: infinite loader (or traceback from V16).
Steps to reproduce the 2nd bug:
- Go to "/contactus" and edit the page.
- Click on the header.
- Change the "Header Position" option to "over the content".
- Save the page.
- Go to the homepage and edit the page.
- Click on the header.
- Open the header selector.
- Choose the "sidebar header".
- Save the page.
- Go to /contactus.
- Bug: the "sidebar" header is broken on the "/contactus" page.
The first bug was caused by triggering the deactivation of the "Overlay"
header from a location other than a website.page (in this case, the
"/shop" page in the steps to reproduce). In this place, the "Overlay"
header option isn't available.
However, while trying to fix this, we noticed the second bug => When we
activate the "sidebar" header (which is a general option for all pages),
we were deactivating the "Overlay" header only on the current page (this
option is specific to the page). It was done since this commit [1].
This doesn't make sense because the "Overlay" header should be
deactivated on all pages, not just the current one.
To address this in the simplest way, we modified the CSS so that the
"Overlay" header doesn't have an impact when the sidebar header is
activated. Without this change, we would have needed to add an RPC to
remove the "Overlay" header on all pages, which wouldn't have been worth
it.
[1]: https://github.com/odoo/odoo/commit/618fd49642310c7b97ef3b9e6c01f8f691c7b12f
task-3454161
closesodoo/odoo#139955
X-original-commit: b27279492fea98f2cd6bfba962bfd570e464d361
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Currently creating a record with 'is_published' being False (aka not published)
crashes when people can't publish. However 'is_published' being False is the
default value, and create should work in both cases.
It now correctly checks that published records could effectively be published.
This allows to remove a small workaround done in eLearning.
See odoo/odoo@4086f344d8 for ref.
Only failing use case would be having
def _default_is_published(self):
return True
def _compute_can_publish(self):
for record in self:
record.can_publish = self.env.user.has_group('something')
But this would not be a really valid use case: not being able to publish
but having default publish to True makes no sense: what matters is publishing
records as it gives more visibility to records, not the flag change itself.
Followup of odoo/odoo#70291
Task-3299702
closesodoo/odoo#137900
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
qsm-odoo