Steps to reproduce:
- Enable the "Cookies bar" in website configuration > Go to website
(Edit mode).
- Select the cookies bar > Change its layout to "Popup" > The modal
container becomes visible in edit mode only.
The `#website_cookies_bar` element will automatically get one line
height (equivalent to its current `line-height` value) because of the
`contenteditable="true"` added to it, which makes it visible in edit
mode (The container has this default height in all layouts, but it's
hidden by the cookies bar content in "Discrete" and "Classic" modes).
The goal of this commit is to simply hide this element to prevent this
behaviour.
Remark: The same issue occurred on a `.s_popup` parent with an inner
`.modal` element and was fixed in [1] by keeping their visibility
synchronized.
[1]: https://github.com/odoo/odoo/commit/cfd53b8fae3ad9f677df49a03fe6d2945dbb5da2
linked to opw-3485565
closesodoo/odoo#143913
X-original-commit: 4374adfde3627852d0a932f3d10fa74fe0b76a83
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Upon drop, the fix in [1] did consider invisible the blocks that were
visible within the current preview mode (mobile/desktop).
Because of this `onTargetHide` was be called instead of `onTargetShow`.
This commit changes that behavior so that the correct method remains
called according to the actual visibility, but the `DeviceVisibility`'s
`onTargetShow` is adapted to only add the override if it matches the
current preview mode.
No steps to reproduce for this first change, but third-party options
could have been impacted by it.
This commit also adds that condition on the cleanup that was added in
[2] to keep the `dataset.invisible` state consistent upon toggling the
preview mode.
Steps to reproduce this second issue:
- Drop a Columns snippet.
- Make a column visible only on mobile.
- Make another column visible only on desktop.
- Toggle preview mode several times.
=> `dataset.invisible` was set to `1` on all columns having
device-dependent visibility.
[1]: https://github.com/odoo/odoo/commit/acfca25e48ac9bc227234de860fe8128f0312ed4
[2]: https://github.com/odoo/odoo/commit/174e9fe0d8665d1a81c90a6f7bf5cc9e3361f161
task-3538535
closesodoo/odoo#143640closesodoo/odoo#143875
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit prevents the editor to search for anchors when the link URL
is an email. This way we prevent an error in the console.
Related to runbot-18747
closesodoo/odoo#143791
X-original-commit: e767c7d4b0ccdeb016cf224b80e269afce4b3028
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
In grid mode, if an image is in an image column (with the class `o_grid_
item_image`), it has the "Position" image option, allowing to select
between "cover" (= the image takes the whole grid-area, which means it
could be "cropped") and "contain" (= the image is entirely visible and
keeps its ratio in the available space). When there is a shape on the
image, this option is hidden and it is "contain" by default (or else the
shapes would be cropped). See commit [1].
Commit [2] added the "On Hover" animation option, to add hover effects
on images. In order for the effect to be applied, a shape is needed and
if no shape is specified, a dummy square shape is used instead. As there
is a shape, if it is a grid image, the "position" is forced to "contain"
(because of commit [1]).
The issue is that while it is logical for some hover effects to never be
"cover", as they could be cropped (i.e. "Dolly Zoom", "Outline", "Mirror
Blur" and any effect with a shape selected), it is not the case for the
other effects when there is no shape.
This commit improves this by allowing the "Position" option to be used
with these other hover effects when no shape is selected (so only with
the dummy square shape).
Steps to reproduce:
- In edit mode, drop the "Banner" snippet.
- Add the "Overlay" hover effect on the big image.
=> The image became "smaller" because it was forced to "contain".
[1]: https://github.com/odoo/odoo/commit/faf19ef7f87fc043fb9a814516e01b8eeafd9b61
[2]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
task-3568406
closesodoo/odoo#141468
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Steps to reproduce:
- Drop a "Share" snippet anywhere on the page and save.
- Click on the email icon.
- Your default email client should open with, as a subject line, the
title of the page where spaces are replaced by +.
=> This should not be the case, spaces should show as spaces.
Since the sharer refactoring in [1], the title of a page used in share
buttons of the `s_share` snippet is encoded as a `URLSearchParams()`,
which encodes spaces as "+" characters (see the specs [2] of the
built-in method). This works fine for most share buttons, but not for
email clients, which do not properly parse the "+". Typically, that
means that the subject line of the mailto link is something like
"Home+%7C+My+Website", which renders as "Home+|+My+Website" in a mail
client, instead of showing spaces.
This commit uses another way to encode the title parameter, so that it
works for every share button. It also replaces a space that was encoded
twice for Whatsapp.
[1]: https://github.com/odoo/odoo/commit/5297388cd2aa1f693b04538c846c7025e243b09d
[2]: https://url.spec.whatwg.org/#ref-for-urlsearchparams%E2%91%A4
task-3603556
closesodoo/odoo#142876
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Steps to reproduce:
- Go to website (in "Edit" mode) > Drop a new popup snippet > Make it
visible on all pages ("Show On" = "All Pages") > Save.
- Add a new language (e.g. fr) > Try to translate the page > A warning
is displayed: "Action 'get_page_option' was not able to be handled."
- Try to save > The "save" button just keeps loading and the same
warning is displayed again.
Now let's try to do the following actions [1]:
- Go to website (in "Edit" mode) > Drop a countdown snippet in the
footer > Set a conditional visibility on it (e.g. "Visibility" =
"Conditionally" = "Visible for Logged In") > Save.
- Try to translate the page > Save > We get the same error described
above.
Technical details:
Starting from [2], user has the possibility to translate invisible
blocks by allowing `_updateInvisibleDOM()` in "Translate" mode, which
makes them accessible in the edit bar.
In the case of an "All page" popup (The snippet is moved to the
`<footer/>` element to make it available on all pages...), the snippet
editor will be created with the parent's one (`<footer/>` in this
case) leading to the following behaviour when saving the page content
in "Translate" mode:
A- `cleanForSave()` called for all snippets...
B- `toggleTargetVisibility()` is then called for the `<footer/>` (which
doesn't have a `o_snippet_invisible` class).
C- `onTargetShow()` is consequently called allowing `_isShown()` to
check the footer visibility via the `get_page_option` action.
Since the navbar action widget (`ContentMenu` in this case) that handles
the action is not available in "Translate" mode, the action demand will
be aborted and we get the warning above.
Implemented solution:
- In "Edit" mode (for `s_popup` snippets):
The initial goal of this commit was to fix this behaviour by excluding
the parents when creation the `s_popup` editor in "Translate" mode.
But after some discussion, we prevent this behaviour for all `s_popup`
snippets (even in "Edit" mode) since they should not display their
parents options.
- In "Translate" mode (for all invisible snippets):
As described in [1], the issue will always occur if an invisible element
enables a parent option that needs action handers... And since we only
need to hide / display invisible elements to translate them, we also
prevent creating parents editors in "Translate" mode.
[2]: https://github.com/odoo/odoo/commit/04409af0571ed763c5712dbf857ea7dda81b2374
opw-3485565
closesodoo/odoo#143269
X-original-commit: 33e5bc36ecb5a4316ad7a61380461cb1663cb38a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Since [1], dropping a form snippet generates a `TypeError: Cannot read
properties of undefined (reading 'disconnect')`.
Note that it only happens if this is the 1st snippet dropped, and if it
is dropped as a section, not as inner content of another snippet.
This is due to the SnippetEditor being destroyed before being started,
as `destroy()` is synchronous but `start()` is async. A field from
`s_website_form` (specifically the field `.s_website_form_dnone`) is
removed through `_addHiddenField()` when dropping a new form. The result
is that it gets destroyed immediately and tries to disconnect an
observer that doesn't exist yet, but the async start() ends a little
later - and creates + connects the observer that will never be
disconnected.
To solve the issue, this commit makes sure (1) in `destroy()` that the
observer was initiated and (2) in `start()` that if the SnippetEditor
was destroyed, it should not create an observer.
[1]: https://github.com/odoo/odoo/commit/f64c9f2
task-3598997
closesodoo/odoo#142291
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since commit [1], anchor dialog is now in OWL. During adaptation, a line
of code was forgotten which lead to a traceback when an anchor is saved
with an unchanged name.
Steps to reproduce:
- Drop a Text-Image snippet and set an anchor on it.
- On the anchor notification, click on "Edit"
- In the dialog, do not modify the anchor name (or change it but then
set the original one again)
- Click on "Save & Copy"
=> Traceback
[1]: https://github.com/odoo/odoo/commit/57ed8bc0bf9d1ae2b7542d677a4d7e8fd1899ea2
task-3576975
closesodoo/odoo#141936
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Before commit [1], anchors would not have a duplicate name as checks
were in place to prevent it from happening. However, after [1], those
checks were no longer valid. They would check in the global variable
document, which was no longer the editable document.
This commit fixes that by using the ownerDocument of the target, which
should always return the correct document.
Steps to reproduce:
- Drop a text snippet.
- Click on create anchor (link icon)
-> notification shows "/#Text".
- Drop another text snippet.
- Click on create anchor (link icon)
-> notification shows "/#Text".
=> It should instead show "/#Text2".
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3576975
X-original-commit: fa75fe60b32537d3c564ddba8117207f468c1004
Part-of: odoo/odoo#141936
This commit removes some text style options when the editor is used in
the backend. In the website it makes sense to have all the options but
in the other apps, it is not necessary to have all the options.
task-1958098
closesodoo/odoo#141412
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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>
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 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>
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>
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 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>
*: 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 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>
Since [1], `qweb.render` was replaced in all Odoo by `renderToElement`
and `renderToFragment`. However, in the case of the template
`website.delete_google_font_btn`, if the font is served from Google, the
template contains multiple root elements, which means it should be
rendered by `renderToFragment`. This commit fixes that.
Steps to reproduce:
- Install Website.
- Go to website and start edit mode.
- Go to theme menu and open the "Font Family" menu.
- Click on Add custom font.
- Add a Google font (e.g. https://fonts.google.com/specimen/Tilt+Neon).
- Make sure serve from Google is selected.
- Try to open the theme menu again.
=> Traceback
[1]: https://github.com/odoo/odoo/commit/f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b
task-3557794
closesodoo/odoo#138927
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
This commit implements a way to expose any model publicly on the website. Both manual and
existing models can create such pages called 'Model Pages'.
A manual model is a model that has been created by the user at runtime, via the technical menu,
via studio, or with an xml declaration.
The main interface to easily create such page is in Studio, in the tab Website Integration. But a
partner or developer could easily import those without studio installed. That's the reason most of
the code to handle the display of such pages is present in the website module directly.
The listing can handle two display modes (Grid or List). Once the user changes the display mode,
the latest value is set in the session to be remembered for the next visit of the page.
A default_layout can be set and is customizable in the website editor or from the backend of Website.
This value is linked to the page to display, so each listing page can use a different layout by default.
The route on which the models are exposed is:
"/model/<string:page_name_slugified>",
With the derived routes:
"/model/<string:page_name_slugified>/page/<int:page_number>",
"/model/<string:page_name_slugified>/<string:record_slug>"
task-id-3231144
Part-of: odoo/odoo#130544
Co-authored-by: Florent Dardenne (dafl) <dafl@odoo.com>
Co-authored-by: Luca Vitali (luvi) <luvi@odoo.com>
xO-Tx