It introduces:
New navigation flow with buttons inside the cart_summary template
Reviewed tables across the pages removing stripes and improving spacing
Redesigned stepper wizard with a reusable template in /website
task-3083707
Part-of: odoo/odoo#133064
Co-authored-by: Valentin Chevalier <vcr@odoo.com>
This commit removes the module sortable from jQueryUI and adds instead a
sortable service to use the sortable code already used by the backend.
The service can be called using `this.call("sortable", ...)` and the
sortable listeners are added when the `enable` function is called.
This function (`enable()`) returns an object that contains the `cleanup`
function (`cleanup()`).
```javascript
// start / setup
const sortable = this.call(
"sortable",
"create",
{
ref: { el: document.querySelector(".list") },
elements: ".items",
handle: ".drag-icon",
},
);
// on attach callback / on mounted
const sortableInstance = sortable.enable();
// on destroy / on willUnmount
sortableInstance.cleanup();
```
Also, it adds some new property to the useSortable:
* clone: the placeholder is a clone of the drag element
* placeholderClasses: classes added to the placeholder element
* applyChangeOnDrop: on drop the change is applied to the DOM
* followingElementClasses: classes added to the element following mouse
task-3439226
closesodoo/odoo#137527
Related: odoo/enterprise#48371
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
*: auth_totp_portal, event, portal_rating, web, web_tour, website_blog,
website_event, website_event_booth, website_event_sale,
website_event_track, website_event_track_quiz, website_payment,
website_sale, website_sale_comparison, website_slides,
website_twitter
This commit allows to have responsive font sizes on all the Odoo
frontend. It is based on the Bootstrap mixin `font-size` which
calculates the font size based on the viewport width.
task-1958098
closesodoo/odoo#129469
Related: odoo/design-themes#673
Related: odoo/enterprise#44578
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_mass_mailing
Since `btn-lg` should only be used for calls to action, this commit
reduces the submit buttons to the normal size to maintain consistency.
task-3097005
Part-of: odoo/odoo#120302
Before this commit, snippets were using primary buttons too much. We are
now using more secondary buttons and links.
task-3097005
Part-of: odoo/odoo#120302
The "lead" font-size was not related to the base font size. It now is.
It is especially important since we will allow users to set up the
"lead" style on any text in another PR.
task-3097005
Part-of: odoo/odoo#120302
*: web_editor
This commit applies the light color on inputs to keep consistency with
the default theme redesign. That color is now customizable as it is
linked to o-color-3.
task-3097005
Part-of: odoo/odoo#120302
Co-authored-by: Brieuc-brd <brd@odoo.com>
Prior to this commit, some snippets used colors that were not changed or
were not visible (white text on white background) depending on the color
preset, which created color issues.
This commit adapts colors to make elements readable and maintain
consistency with the theme design.
Note: this could be partially backported (with stable adaptation) later.
task-3097005
Part-of: odoo/odoo#120302
Co-authored-by: qsm-odoo <qsm@odoo.com>
In the context of the website's theme redesign, this commit adapts the
pagination component design.
task-3097005
Part-of: odoo/odoo#120302
Co-authored-by: Brieuc-brd <brd@odoo.com>
*: web, web_editor, portal, theme_default, website_sale
The goal of this commit is to improve the overall style of the default
website theme mostly by overriding Bootstrap variables with a bit of
customization for more advanced changes.
task-3097005
Part-of: odoo/odoo#120302
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Antoine (anso) <anso@odoo.com>
Before this commit, you had a very partial control over the light and
dark colors of Bootstrap: it was linked to the darkest and lightest gray
whose tint and saturation could be controlled (a bit) but not their
lightness. This was ok since light and dark were barely used in
components anyway. Later improvements (and future ones in this PR) will
keep using them more and more, especially in apps layout. We thus need
some more control over them.
This commits does this:
Currently, theme colors are divided into two groups:
o-color-1 o-color-3 o-color-2 + o-color-4 o-color-5
Only o-color-1 and o-color-3 are saturated colors by default and are
linked to BS components (basically primary and secondary). The others
are not (barely ?) used outside of color combination classes.
Now there will still be two groups but:
o-color-1 o-color-2 + o-color-3 o-color-4 o-color-5
1 and 2 are still supposed to be the main ones the users should use to
have the color of their company. The 3 others ones will be linked to
light and dark configurations: in color combination classes still but
also for light and dark bootstrap related configurations.
Note: users will still be able to do the same things as before and have
"more than 2 'company' colors": they can still customize their 5 color
combinations classes entirely. So for example, if someone changed
o-color-3 to a bright saturated color to have their second color
combination use that color as background, after upgrade many bootstrap
components will be impacted as it will be linked to the `$light`
bootstrap color. However, they can revert back o-color-3 to a nicer
color to be used as `$light` and force the second color combination
class' background to their old color. That way the visual of their
website will be the same. Some class will still be impacted though
(like o-bg-color-3 which could be added thanks to the secondary tab of
most colorpickers). This is a compromise as this was not "the right way"
to apply a background color anyway, except for icons and text highlights
(in which case users will need to go over their website to force their
old colors if needed) **.
**: Something could be done to help with that in a future commit (maybe
allowing to apply color combinations background on icons for examples).
Also both groups of colors will be named, helping users understand what
they are meant to be used for. Although anything is possible and no
restriction is made on how to pick those 5 colors. Actually, these new
improvements will allow to configure dark themes: just by switching dark
and light colors and/or making the light one a darker color.
task-3097005
Part-of: odoo/odoo#120302
Co-authored-by: "stefanorigano (SRI)" <sri@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Antoine (anso) <anso@odoo.com>
*: website_sale
This commit aims to harmonize default border-color values and to provide
a predictable result when transitioning between color-presets.
We assign a CSS variable to bootstrap `$border-color` in order to let
bootstrap components (and utility classes) align with the chosen
color-preset.
The color itself is achieved by fading-out the current text-color using
CSS 'mix-color()' function.
Since, at the time of writing, the function itself has a global support
of 81% (mainly because of IE which we do not support but... see [1]), a
fallback has been conveniently provided.
Note: the right panel of the editor actually cannot understand the
result of the `mix-color` function either and will display a transparent
color instead. This will be fixed in a later PR.
[1]: https://caniuse.com/mdn-css_types_color_color-mix
task-3097005
Part-of: odoo/odoo#120302
Co-authored-by: Brieuc-brd <brd@odoo.com>
Replace all the calls to get_resource_path to the better file_path or
directly use file_open when not needed
Doing both a get_resource_path and file_open means checking twice that
the file exists.
Doing a simple path concatenation before a file_open is safe.
If given to another method (e.g. etree.parse), calling file_path is
the prefered method.
Note that get_resource_path used to return False when the file does
not exists while file_path/file_open raises a FileNotFoundException
closesodoo/odoo#135607
Related: odoo/upgrade#5187
Related: odoo/enterprise#47475
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
*: test_website_modules, website_sale
When one starts a trial with the website app, they arrive on a webpage
in edit mode. Many users struggle to understand they need to save before
accessing the Odoo navbar (app switcher, creation of new page, etc.).
Additionally, if they want to navigate through Odoo, not having to
discard could save some time.
It was therefore decided to land on the homepage without editor after
creating a website. The first step of the homepage tour should then be
to click on the edit button.
When creating an empty website (skipping the configurator), the website
loader is shown until the page is ready, to avoid the user leaving the
page before the first step is displayed.
On another related note, if one wants to try out the Odoo website
builder, they might create multiple DB, one per website, which is OK. In
such a case, the link to 'my database' is not visible from the website
app because the user profile was hidden.
The user menu is therefore added to the navbar on the website app.
In order to make sure the header and its dropdowns always stay on top of
the website's elements regardless of their z-index, `.o_website_preview`
is blocked in its own stacking context with `isolation: isolate;`.
task-3381773
closesodoo/odoo#133031
Related: odoo/enterprise#46992
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Since [1] an error was thrown when giving multiple files to http.post.
This commit reverts changes in the function but the function now also
allows to give a FormData instead of pojo.
[1]: https://github.com/odoo/odoo/pull/136271closesodoo/odoo#137421
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This commit fixes two bugs with the colorpicker that occur since [1].
Steps to reproduce the 3rd bug:
- Go to Website edit mode.
- Click on the header.
- Choose "Over The content" for the "Header Position" option of the
header.
- Change the color of the header by picking a color in the "Background"
sub option (below the "Header Position" selector).
- Save and Edit.
- Go with your mouse over the different colors of the colorpicker (at
least 2).
- Bug: an infinite loader appears on the iframe and prevents from
editing the background color.
Steps to reproduce the color combinations bug:
- Go to Website edit mode.
- Drop a Call to action snippet.
- Change the background color and try to select another preset.
- Bug: the color of the text and buttons is updated, but not the
background color.
Both of these 2 bugs happen after commit [1] because the colorpicker
widget is started before the ColorPalette component is attached to the
DOM (which only happens once the user opens the picker). However, the
colorNames are only set after the setup() of the ColorPalette.
Initializing the colorNames with possible default values is thus
necessary to avoid bugs on `_computeWidgetState()`.
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
task-3440939
closesodoo/odoo#137306
X-original-commit: https://github.com/odoo/odoo/commit/2ccc01175080ddb549660713d6101dd936e0d304
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The cookie service was replaced by a utils file in core. This was done
to be able to use the cookies without the need of environment.
"Om Nom Nom Nom" - Cookie Monster
part-of task-id 3439226
closesodoo/odoo#136782
Related: odoo/enterprise#48005
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: board, website
This commit simplifies the UX of the 'Custom Group by' menu. Before this
commit, many clicks were needed to apply another filter, from an accordion
menu.
Now, a select element is used instead, allowing a better user experience, by
enabling such group by directly, when an option is selected.
Some tests have been adapted to the new selectors and behaviors, and the
applyGroup and toggleAddCustomGroup has been removed, since groups are applied
when selected, and the value can be modified directly with selectGroup.
task-3458519
closesodoo/odoo#132006
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
users who create products from the website are intended to make it visible immediately for customers
task-3234684
closesodoo/odoo#117884
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit adapts the hover style of the editable fields elements to
match the new overlay style.
task-3368793
closesodoo/odoo#132653
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds a new snippet to display an Instagram page on the
website using an iframe that embeds the Instagram page.
task-2603045
closesodoo/odoo#133905
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Steps to reproduce the bug:
- Modify the website's menu to include only two items: a link to a page
and a dropdown menu.
- Switch to mobile preview.
- Open the "Hamburger" menu.
- Click on the dropdown toggle.
- Bug: The dropdown menu is hidden and requires scrolling the navbar to
see it.
Since commit [1], dynamic positioning of dropdowns within a navbar has
been enabled (before that, Bootstrap disabled it) but this change
introduced this bug.
To fix this, we disable dynamic positioning of the dropdowns when they
are inside a "Hamburger" menu.
[1]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914
opw-3493512
closesodoo/odoo#137165
X-original-commit: 55bc21c9503bf3b319d94e10d73bf672385b455c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
This commit aims to reintroduce CSS variables to handle the different
states of our navbar entries.
Recently, the way we handle the navbar entries changed. Previously, we
used to set CSS variables in Community, which would allow us to control
the color of ours nav entries at every state.
On the Enteprise side, this would allow us to use the different colors we
use for these buttons and style them differently
This approach was also very helpful because we could override these CSS
variables once again to handle the colors of the Studio navbar elements.
Recently, the approach used to control these elements changed :
- On Community, we make use of CSS variables ;
- On Enterprise, we use the Bootstrap `btn-light` class.
Using `btn-light` was a very good approach to ensure that no issues would
appears on our buttons and also to reduce the amount of code needed, but
unfortunately, using `btn-light` directly affects Studio, causing contrast
issues. It was also a bit weird to have CSS variables + Bootstrap classes
being set at the same time.
To fix these issues, we reintroduce CSS variables in Enterprise and Studio,
to fully control the color of our elements and ensure everything is
readable. Most of these variables are defined in Community, inside the
`navbar.scss` file, and we simply override them in Enterprise and Studio.
task-3418936
part of task-3326263
closesodoo/odoo#137140
X-original-commit: af6d914c379953d2deec9833579399f126076194
Related: odoo/enterprise#48174
Signed-off-by: Stefano Rigano (sri) <sri@odoo.com>
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
Steps to reproduce:
1. Go to the website
2. Add website languages
3. Drag Table Of Content
4. Select snippet block
5. Go to customize the block
6. Select visibility conditionally - set visible/hide for languages.
Before the commit, selecting block visibility conditionally makes only
the block is invisible but not the navbar content is invisible due to the
absence of the `data-visibility-id` attribute.
In this commit, handling conditional visibility of the navbar when the
the snippet block is invisible.
Also, This commit adds a check for missing visibility IDs in anchor
links. The code checks if both the visibility ID values exist or if they
are both missing. If either condition is met, the function returns
without creating the `<a>` tag.
task-3373943
closesodoo/odoo#137081
X-original-commit: 182d3f20d8d3ae8149280ac3084423ba11e0975d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, when an existing link was edited with the LinkTools
or LinkDialog, the URL input field omitted the "mailto:" part of the URL
for email links, but displayed the protocol/scheme for http(s) links and
phone numbers (tel: or tel://).
This commit standardizes the behaviour of the referred input field such
that the protocol/scheme for http(s), mailto and tel URLs are omitted,
in order to have a cleaner UI.
task-3516854
Part-of: odoo/odoo#136487
Some pages don't have an image for the sharer. This wasn't too critical,
as the code to retrieve the image was written in JQuery and didn't cause
any problems if no image existed.
```
$('meta[property="og:image"]').attr('content')
```
If there is no element matching the selector, it returns `undefined`.
[This commit] was merged and migrated the JQuery code to vanilla JS.
```
document.querySelector('meta[property="og:image"]').content
```
If there is no matching element, it throws an error (we can't read the
content on undefined).
This commit keeps the vanilla JS code but prevents the error if there is
no image to share. In addition, for this master commit, we took the
opportunity to refactor the code.
Steps to reproduce the bug as an admin:
- Go to /slides and click on "View" next to the user's name
- Edit the page
- Drop the share block on the page
- Save the page
- Click on the Pinterest share button
=> An error appears on the screen.
[This commit]: https://github.com/odoo/odoo/commit/ddb2c06be4196c86ff6a2fd74874487d75b31c94
opw-3326724
closesodoo/odoo#136737
X-original-commit: 66651fabcc36e8d5f455c08d5bffb9036bef8d3c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: analytic, base_automation, loyalty, mass_mailing, project, web, web_editor, website
This commit adds many new documentation of options and their usage for
fields. This makes them more usable and customizable in Studio, and adds
documentation for developers to know the type of expected option.
Some options that might lead to issues or that are too technical have
been removed, as they are not relevant and not required in most use cases.
task-3469741
closesodoo/odoo#134858
Related: odoo/enterprise#47148
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit removes the files ajax.js and rpc.js then adapts all the
places where their exports were used. For most of the changes, it's a
replace of `this._rpc({...})` by a new `useService("rpc|orm")` like
pattern in the widgets.
closesodoo/odoo#136271
Task: 3439226
Related: odoo/enterprise#47775
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The 'like'/'ilike' operators automatically add the wildcard character
(`%`) at the beginning and at the end of the value. This commit fixes
the incorrect usage.
closesodoo/odoo#136007
Related: odoo/enterprise#47886
Signed-off-by: Raphael Collet <rco@odoo.com>
*: website_event
Without this, the seo saving would not forward the current website in
the context. It's especially bad in this case as it's writing on views
which are not triggering the COW due to the lack of a website_id in the
context.
Step to reproduce:
- Go to /shop (if you didn't do anything, this will be bound to the
`website_sale.products` view which has no website_id set and is called
a generic view)
- Open "Optimize SEO" dialog and type something in the title
- Save
- It saved the change on the mentioned view, without duplicating it
(COW) before writing on it. The title you added is now applied to
every websites and not only the one you edited, which is against the
website holy grail rule: only the website you edit should be changed.
Technically, this is because we refactored that part of the code in Odoo
16: the website is now editable in the backend.
Note that this fix also revealed that a test for events (which has been
introduced with [1]) was relying on the bug: it tested the meta title of
a view that should (and will after this fix) have been COW'ed. This test
will now indirectly protects this bug from re-happening, although we
might want to write a dedicated test in the future as the behavior for
events might need some refactoring.
[1]: https://github.com/odoo/odoo/commit/2072a7739eb9a9ee87c8b3c7b0d43a82a7e2375f
opw-3499285
closesodoo/odoo#136550
X-original-commit: c45c0bf8fff7285a9fff33ff9bf1c24bbfb130e7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Before this commit, some actions related to link creation and edition
were not tested by the LinkTools tour.
This commit adds steps to the mentioned tour in order to avoid
regressions of the issues fixed in the referred task.
task-3284649
closesodoo/odoo#136278
X-original-commit: b2a79ed9960d88d1bdf6465389f4ef720f6bc235
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When loading a registry from the route with auth="none" and where module
'website' is set as 'to install', request.env will be None, and install will
crash as follows:
Error:-
AttributeError: 'NoneType' object has no attribute 'context'
reference of previous commit-
https://github.com/odoo/odoo/commit/0ebf849b8e0de33d3b6e7e06c66189591dc7a72c
sentry-42474563
closesodoo/odoo#136096
X-original-commit: ca43e03e6f510520e874b2a8bba092ac9a7f2453
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The livechat button was disabled in website preview because
its implementation could not properly handle being in an iframe
inside the backend [1].
With the public livechat code being refactored to use discuss code,
this is no longer a problem, so the livechat button can be present
again. This also makes previewing the website more correct: the
livechat button is actual present on the website, so hiding it was
a lie.
By re-enabling the livechat button, this also allow to remove the
test coverage by a tour, which was sometimes failing on runbot due
to tour being small and doing `im_livechat/init` rpc after the end
of the tour.
[1]: https://github.com/odoo/odoo/commit/e86c1ce94a148745d58ac38e408e1bc947978670
runbot-24631
closesodoo/odoo#135913
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Issue:
Search on website has a big performance issue because the database has
too many product_template.
Analyze :
The website search mechanism has hardcoded sql query. And the generic
query don't have any filtering. Which lead to make a expensive search
(similarity) on the whole product_template even if the products are
not published and then displayed to the user.
Fix :
Filter the is_published field in the generic website method when the
model has a 'is_published' field and the request is not done by a user
(thus for customers or portal users).
Note:
The internal user is still able to search on unpublished product.Thus
have no performance improvement.
Benchmark:
| SQL Query | # Input data | Before PR | After PR |
|:---------:|:------------:|:---------:|:--------:|
|General best_similarity |700000 products (161 published) | 12.65 s | 0.12 s |
|FROM ir_translation|2,796,000 ir_translation | 6.338 s (586k hit) | 0.091 s (185 hit) |
Related task:
task-3473786
Related ticket:
opw-3418457
closesodoo/odoo#136080
X-original-commit: fcb968836a2d0e49516fe3ecb23dde61f4597749
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes this error:
- The IMP done at [3] added a lot of fields but all of those forgot the
`_t()`/`_lt()` translation.
Note that:
1. A fix to replace `_t` by `_lt` was done at [4] but it was badly done
as it was not targetting the correct version... and only fixed one of
many occurences.
2. In this forward port, using `_t()` seems to be working again, using
`_lt()` is not required anymore. This part of the PR has been removed
here. For tracking purpose, here was the other bug:
- The form registry fields added in [1] and [2] in Odoo 13 had a
`string` attribute translated with `_t()` while now it should be
translated with `_lt()`. It was surely working in Odoo 13 but not
anymore. It's not worth investigating to be sure.
- Not needed since a recent commit which removed `_lt()` (it's a
deprecated alias to `_t()` which now handles the lazy translation
directly too.
[1]: https://github.com/odoo/odoo/pull/32565
[2]: https://github.com/odoo/enterprise/pull/4063
[3]: https://github.com/odoo/odoo/commit/617eba941785aa680edb826e14b0009637d60dee
[4]: https://github.com/odoo/odoo/commit/2be83cae7bcda369ed5bc7806aef845c6c76e687
opw-3471873
closesodoo/odoo#134238
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
---- Horizontal spacing issue ----
The horizontal spacing between systray items in the patched website
systray is too small. It was using the regular margin of the default
Odoo systray which is composed of almost only icons for which a small
spacing is what we need.
But the website patched systray contains a lot of text, where we want a
bigger spacing, exactly how we do for the app menus.
---- New class on systray ----
To target the website systray in scss, a new class was added on it.
There is no clean way in JS to add that class, as the website systray
patch is only altering the method in charge of returning the systray
items. The rest is left up to the base NavBar class component, including
rendering.
That NavBar component does not come with a built in way to add a class.
We could have targeted the DOM directly in the patch through
`this.root.el` and added the class in JS directly but that seems like an
owl anti pattern.
---- Vertical align issue ----
Before this commit, the btn in the systray didn't have the same line
height as other elements: both the "Edit" (in main lang) and "Translate"
(in alternate lang) buttons had a (1-2px) vertical alignment issue.
This was because, despite having the same font style and font size, they
had a different line-height making it glitch 1-2px vertically.
It's a bit less visible for the Edit button as there is a pencil icon
between this text and the text next to it.
For the translate button, it's quite visible directly.
For testing purpose, you can simply remove the icons and the left-right
margins of those systray items so the text are glued to each other and
you clearly see the misindentation.
---- Misc ----
For tracking purpose, there is multiple cases to be tested regarding
those buttons:
- Community vs Enterprise (where those are colored)
- Regular mode vs translate mode
closesodoo/odoo#135956
X-original-commit: 066e4a1ddd9faf7ba866c5428c943b5af8115191
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: "stefanorigano (SRI)" <sri@odoo.com>
Before this commit, updating the color previews in the editor panel was
only done if the user remained in the "Theme" tab.
This means that those steps worked:
- Add a snippet in your page
- Go to the theme "tab"
- Change a theme color: validate the color you chose by closing the
dropdown by clicking inside the theme panel, staying in the theme tab
- Click on the snippet
- Open the background option colorpicker -> theme colors are right
But those apparently same steps did not work:
- Add a snippet in your page
- Go to the theme "tab"
- Change a theme color: validate the color you chose by indirectly
closing the dropdown by directly clicking on the snippet you added
- Open the background option colorpicker -> theme colors are wrong
task-3419142
closesodoo/odoo#135703
X-original-commit: 83c0bd93f0948bed4220ba5e505516f305b1c6ce
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Reproduction:
1. Install website
2. Change to edit mode and edit a link on the main page, for example,
“contact us” at the bottom
3. When you replace the link with /, the rpc breaks and no suggested
links returned
Fix: this issue is gone with a recent update on master, now the rpc used
by linkTools is the new rpc
Task-3444671
[FIX] web_editor: restore double click focusing on URL when editing link
Reproduction:
1. Install website
2. Change to edit mode and edit a link on the main page, for example,
“contact us” at the bottom
3. The focus is on the url at the link tool
Fix: The desired behavior when clicking on links in editing mode is: one
click, edit the text of the link; double click, focus on the URL in link
tools. After converting to OWL, focusing on URL is handled by props, e.g
. `shouldFocusUrl`. We also need to update the state of this prop in
`toggleLinkTools` as we did before conversion.
Task-3444671
Forward-Port-Of: #132167
Also added fix for using the new rpc function instead of the legacy one,
edited the test accordingly.
Part-of: odoo/odoo#135371
The user has the option to remove the last block from the Table of
Content snippet prior to this commit, but doing so breaks the Add Item
feature because there is no reference to adding a new item in the
snippet area, and doing so is also not a good idea.
If the block is the final one in the Table of Content after this commit,
removing the last Content will remove the ToC snippet.
task-3081442
closesodoo/odoo#135733
X-original-commit: 164db4013439042725c94f1690ae0a311be9d554
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
