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>
Since the scrollbar was moved from the window to .modal-content at [1],
animations inside popups without backdrops would not be working anymore
because the scroll was not checked against the right element.
This commit fixes this by using the right scroll element's scrollTop.
task-3328419
[1] https://github.com/odoo/odoo/commit/cb7cf77closesodoo/odoo#135404
X-original-commit: 1b618b323424e29b0ddf9eae686e0ef2540b3627
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
*website
Steps to reproduce the bug:
- Drop the "Form" snippet on the website.
- Add a new field.
- Replace the field label by "test\".
- Save.
=> Traceback of type "Cannot read properties of null (reading
'dataset')" appears.
In the `start()` function of the `s_website_form` public widget, the
field names of the form are extracted thanks to the `serializeArray()`
function. The field elements are then found by doing a `querySelector()`
on the field names. In our case, the field name of the new field
extracted by `serializeArray()` is `test\\` (there are two backslashes
because the field name is a string so the first backslash has to be
escaped by a second backslash). The problem is that this string has to
be escaped one more time in order to be used in a `querySelector()`. As
it is not the case, the result of the `querySelector()` is `null`
leading to a traceback when the code tries to access its dataset. To
solve the problem, the character `\` is encoded before being stored in
the `name`, `data-name` or `data-visibility-dependency` attribute of the
field element. Thanks to the encoding, the `querySelector()` operation
can perform correctly on those attributes.
opw-3470291
closesodoo/odoo#135587
X-original-commit: 03f230a77c0d38b46944d45b4991f48e45b275dd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
before this commit:
translations updated by `update_field_translation` api cannot be detected by
t-cache and some cached data whose model overrides `write` with an extra
'clear_caches()'
Step to reproduce:
- Create a mega menu, select any template, `Odoo Menu` for the example
- Install another language on the website
- Go to the translated version of your website and enter translate mode
- Change "Camera" in the mega menu to something else
- Save
The change won't be replicated, looking like it did nothing.
From there, removing or adding `edit_translations=1` in the URL will
use different cache version of the page's views and you will see the
outdated value on one and the correct on the other one.
after this commit:
`update_field_translation` will call `write`
it does the following 4 important things
1. mark field as modified
2. execute logics in the override `write` method
3. update write_date if needed to support t-cache
opw-3305117
X-original-commit: 2beb466668e4eb80d7c3ca3947445fb1cb141cff
Part-of: odoo/odoo#135277
This commit reworks a little bit the backend assets to remove a
bundle and thus save a call at webclient startup. The bundle
"assets_backend_prod_only" existed only to allow to add files in
production, but not in the tests (typically, the file that spawns
the webclient).
This commit introduces a new bundle "web.assets_web" that contains
"assets_backend" and the few files that we only want in production.
In the /web page, we now load "assets_web" instead of
"assets_backend" and "assets_backend_prod_only". In the /web/tests
page, we keep loading "assets_backend", which is now directly
included into "web.tests_assets".
For the sake of consistency, this commit also renames the dark
mode bundle "dark_mode_assets_backend" into "assets_web_dark".
closesodoo/odoo#135204
Related: odoo/enterprise#47316
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
In odoo/odoo#133349 some code in website was adapted to use the new
datetime picker and luxon instead of tempusdominus and moment, but some
conversions were improperly performed causing a crash that would prevent
the website editor from opening. This commit fixes this issue and also
formats the chosen default date/datetime correctly while within the
editor.
This commit also fixes a minor issue with props validation of the
datetime picker, where we would give it an empty string instead of null
or false, causing props validation to fail in debug mode.
closesodoo/odoo#134493
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since commit [1], which converted the wysiwyg to Owl, trying to
customize the Google Map API key causes a traceback.
Steps to reproduce:
- In edit mode, go to the "Theme" tab.
- Click on the Google Map "Custom Key" button.
=> A traceback appears.
It happens because when getting the parent with the `this.getParent()`
call, the parent is now a `WysiwygAdapterComponent` component and so,
calling the `trigger_up` function on it does not work anymore.
This commit triggers the `gmap_api_key_request` event in a way that is
compatible with the Owl component.
[1]: https://github.com/odoo/odoo/commit/76d4f9811b756f0e57b0a33dbba534c900c7fe15
opw-3489976
closesodoo/odoo#135069
X-original-commit: 355a593fe2dea05a96d0491d684722770533ab7d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, there was a 1 pixel border around the image that
remained visible after the "outline" hover effect mouse out animation
was triggered.
This happened due to a typo where the initial value for the "outline"
animation was set to 1 pixel instead of 0 pixels.
task-3495241
closesodoo/odoo#134975
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The website menu is cached for each page, but there is no difference
between the cache of a logged user or of a public user. If you have a
page restricted to logged in users in the menu, this can sometimes lead
to:
(1) the link appearing in the menu even though the visitor is logged out
(because the cache was done when logged in), and
(2) the link not appearing even though the visitor is connected (because
the cache was done when logged out).
While (1) only leads to a 403 error if one clicks on the menu link, (2)
is more annoying as it hides a page that should be shown.
This commit therefore also caches the website menu depending on the
visitor being logged in or not.
Note that the same bug occurs for pages restricted to a specific group.
In these cases however, there is no technical solution as of now. It
should be considered as a limitation.
In such cases, workarounds are possible:
- Going on the "My account" page (by clicking on the username) will
always show the page.
- One could add a snippet on the homepage with a link to the restricted
page, and conditionally display the snippet only for users of that group
Steps to reproduce the bug:
1) Connect as admin, create a new page, open its properties and set its
visibility to 'Signed in', then publish it.
2) Logout, connect as portal
3) Logout, connect as admin
4) Unpublish and republish the page
5) Logout, reconnect as portal
6) Go to the homepage: the new page doesn't appear in the menu
7) Go to 'Contact us': the page reappears in the menu
opw-3445032
closesodoo/odoo#134908
X-original-commit: cfd19012f3a44b4961fe953cf077c55cc986d45c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Go to website > Create a mega menu.
- Go to edit mode > Switch to narrow width for the mega menu.
- After save, the update is lost.
After the refactoring in [1], non-returned class values (in the code
that replaces `_.without()` by native JS) will prevent setting the
option class on the mega menu, leading to the behaviour described above.
[1]: https://github.com/odoo/odoo/commit/f4f0f783183507df8227b37fe1234c256325df6d
opw-3465004
closesodoo/odoo#134901
X-original-commit: 293fce5cc5407705a4314c85fd780cff435202bc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
This commit rewrite the module loader to simplify it and to improve error handling.
before this commit, you could have silent errors or "lucky" imports (import a module based on the fact that his asset will surely be load and if not, the error would be silent anyway).
e.g.: The tours cannot import modules extern to tours' bundle anymore. Or load module before your libs in assets.
TASK ID: 3266021
closesodoo/odoo#128502
Related: odoo/enterprise#44100
Signed-off-by: Bastien Pierre (ipb) <ipb@odoo.com>
This commit tried to remove owl_compatibility completely but its last
uses are either in refactoring or a bit complex to migrate. Instead of
removing the helpers completely, this commit simplifies them a lot and
makes them more readable and safe.
closesodoo/odoo#134295
Task: 3439226
Related: odoo/enterprise#46899
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: mass_mailing,website,website_sale
Before this commit, the ComponentWrapper was used to mount some
components which then render a dialog. This commit replaces these cases
by using the dialog service.
Task: 3439226
Part-of: odoo/odoo#134295
*account,web_editor,website,website_sale,website_slides
This commit removes all legacy utils except Markup, which will be
removed in another PR. A lot of those utils were no longer used and
thus have just been removed. Those that were still used either
already existed in the wowl codebase, so usecases have been adapted
to use the new version instead. A few have been re-implemented (or
moved basically) to the wowl codebase (e.g. isEmail and humanSize).
Part of task~3439226
closesodoo/odoo#134620
Related: odoo/enterprise#47044
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When building a website with the website configurator, you get pages
with a nice layout. However, the text inside is not adapted to your
company, industry or even, most of the time, language.
Using a LLM, we could easily get text much more relevant to customer
needs. The scope of this work is static pages generated with the website
configurator (homepage, about us, pricing, ...).
Later, in other tasks, we also want users to be able to generate text
inside the website builder.
This commit implement the bare minimum to generate and replace a website
content by AI generated sentences (based on the information provided by
the user).
Related IAP PR at https://github.com/odoo/iap-apps/pull/656
task-3248852
closesodoo/odoo#121021
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
During the rendering of website configurator pages, we check that the
rendering of each snippet is done for some reason. That check is useless
because:
- Either the rendering fails and in that case, there is a raised
exception that we catch (note that catching it could also be useless
actually: we will check that post 17.0 release).
- Either the rendering is empty (weird case to cover ?) and the
remaining code should work regardless anyway.
Note that in the original code, that `if` covered the case of trying to
render a non existing view... but was changed in [1] such that in that
case, an exception (that we catch) will be raised.
[1]: https://github.com/odoo/odoo/commit/880954ebfc1106411b7f7a7d60aee05dfae60893
Related to task-3248852
Part-of: odoo/odoo#121021
The configurator code organization should be reviewed. This is a first
step that will be needed for the integration of a new feature: this
removes the one-call inner functions inside that `configurator_apply`.
Related to task-3248852
Part-of: odoo/odoo#121021