Before this commit and since commit [1], it was possible to clone a page
in the page list view.
It shouldn't be the case, cloning a page lead to bad result: a page
with the same URL which is not shown in the page list view because pages
are filtered by URL to remove duplicates.
Cloning a page has always had to be done through the page properties >
"clone page" button. Doing it this way will ask the user for a new page
name (and so a new url). The page will then correctly be listed.
[1]: https://github.com/odoo/odoo/commit/3192051806e0da1276604a31ad818f8768105362
opw-3591738
closesodoo/odoo#146173
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit correctly aligns certain header elements when the CTA button
has a larger vertical padding.
Steps to reproduce the issue:
- Install 'eCommerce' on your website.
- In Website edit mode, click on the 'THEME' tab.
- Adjust the vertical padding of buttons to 25px.
- Click on the header in the page.
- In the 'STYLE' tab, select the 'Menu - Sales 1' header.
- Bug: The 'logo" and the 'menu items' are not aligned with the CTA
button.
- In the 'STYLE' tab, select the 'Menu - Sales 2' header.
- Bug: The 'menu items' are not aligned with the CTA button.
- In the 'STYLE' tab, select the 'Menu - Sales 4' header.
- Bug: Bug: The 'cart' button is not aligned with the CTA button.
task-3478334
closesodoo/odoo#145683
X-original-commit: d2f6710bcaa5cee7e77fc4df902929264ffa4830
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Commit [1] removed the `email_from` field from the `project.task` model
but forgot to adapt/delete some field occurences.
One of those is related to the form in the website builder which allows
to create task when the form is sent.
Two errors were detected:
- Non critical:
The field is still passed to the form field whitelisting process.
Since the whitelisting is done in raw SQL, it didn't crash or log
anything even if the column did not exist anymore.
- Critical:
The field was still marked as model required in the form JS registry,
altering the form builder behaviors.
One of those is that when the form input related to this field was
re-created (eg when changing / hovering an option in the right panel),
it would lose it's "name" attribute.
Two possible issues from that point:
1. When a visitor submit the form, the "email_from" field value is not
set anymore in the task description and that information is just
lost. You then have no way to reach back to him.
2. (Minor) The auto-fill behavior of the form was not working anymore
Probably more issues were introduced but only those ones got detected as
of today.
Step to reproduce:
- Drop a website form, choose "Create a Task"
- Focus the default "Email" field
- Hover the mouse on the "eye" icon ("Invisible") next to the Position
attribute. If you inspect the DOM, the input has now lost the `name`
attribute.
- If you save, you will face the issues reported above.
- If you then reopen the editor and focus the email field again, the
tooltip will now say that the "null" field is required.
[1]: https://github.com/odoo/odoo/commit/a424cf481c676a230beeb6102fc67bedf472a882
opw-3626573
closesodoo/odoo#146170
X-original-commit: 6679fddbcaf7d9146ab242e0eed61ee0628f047f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit the clean_assetbundle could unlink invalid
attachment, mostly when generating a no website assetbundle with
a different version than a website one, the website assetbundle will be
deleted.
Generating a new asset bundle attachment /web/assets/439-b4c80c3/1/web.assets_frontend.min.css (id:439)
Generating a new asset bundle attachment /web/assets/440-3723971/web.assets_frontend.min.css (id:440)
Deleting attachments [439] (matching /web/assets/%-%/web.assets_frontend.min.css) because it was replaced with /web/assets/%-3723971/%%%
The issue is that %-%/ will match 439-b4c80c3/1/ and not only
439-b4c80c3/
Note that it looks like this issue existed for a while but was invisible
because before 16.4 clean_attachment was invalidating the ormcache,
hiding the fact that a still valid asset was deleted and regenerated.
The proposed fix replaces the domain with %-_______/. The unique is
always 7 character long. Note that this change was already made in 17.0
when removing the id from the asset url so this doesn't need to be
completely forward-ported.
opw-3558552
closesodoo/odoo#145452
X-original-commit: 2ac466547e01bfd65415a53ae1efc9d45d9299fb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
See commit [1] for in-depth explanation and framework-js change but
basically, `renderToElement` do not allow multiple root nodes since
[2].
The fix is just about using the correct method to render multiple root
nodes. Without the fix, it just crashed when you click on the page
dependencies links.
Step to reproduce:
- Go to /
- Open Page Properties
- Edit / to /test
- A list of possible dependencies will be shown, it's a link that can be
clicked to open a tooltip to have more details
- Clicking on it crash without this commit
[1]: https://github.com/odoo/odoo/commit/2cff7e4094ebb4b56ab17a1462ff358b4b3e7ffd
[2]: https://github.com/odoo/odoo/commit/6303a3eacdca012649a2ffda627b65c17a7217f1closesodoo/odoo#145715
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Steps to reproduce:
-------------------
- on ecommerce, activate "Extra Info" feature;
- go to the extra info form;
- write something for "Your Reference";
- press Enter.
Issue:
------
The Bad Request message is displayed.
Cause:
------
Pressing Enter triggers the form's default submit.
To use the controller of the `/website/form/shop.sale.order` route,
we need to apply the JS logic of the `s_website_form`
widget (the `send` function).
Solution:
---------
Add an event for the `submit` which will prevent
the default behaviour and send the form data.
opw-3591135
closesodoo/odoo#145707
X-original-commit: 14fc7f3c923847f5e052888c2cfda0bf92316972
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
If you have the backend in a language A but the website in English only,
you can:
1) modify a record's (event, product...) name in language A (say "New
Name").
2) visit the page `/new-name-11` => the server will redirect you to the
English page `/origin-11`, with the only slug that actually exists on
the website. Chrome caches the redirection.
3) give the same name in English as in language A, try to visit
=> the server now wants to access `/new-name-11`
=> Chrome uses the cache to redirect `/new-name-11` to `/origin-11`,
=> the server tries to redirect to `/new-name-11`
=> infinite loop, Chrome puts an end to it after ± 20 redirects.
In effect, Chrome injects a "Too many redirects" layout inside the
iframe, which in turn raises a CORS error when the app tries to update
it.
At the time of this commit, the flow described here should be expected
of users, because the translation UI in the backend is not clear: the
default field displayed is in language A even though the website does
not use it, and the way to update translations is not obvious (you have
to click on the language tag, which doesn't look like a button).
Another way to artificially reproduce the issue would be:
- Create a website.redirect from /dog to /cat
- Same from /cat to /dog
- Go to /@/dog
After this commit, if we detect that behavior, we reload the iframe with
a new query parameter, making the URL brand-new (and not cached) for
Chrome.
opw-3479651
closesodoo/odoo#145306
X-original-commit: 16d47ddf128f31f13e8d0d74597635faf7f9702a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
This commit converts the industry name in the configurator to lowercase
it in order to optimize the IAP placeholder cache.
task-3626875
closesodoo/odoo#145231
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- In Website edit mode, drag and drop a 'Text-Image' snippet onto the
page.
- Select the word "Subtitle" in the title of the snippet.
- Click on the 'Animate' button in the editor toolbar.
- Bug: The 'Highlight Animated Text' icon that appeared on the right of
the title ("Inline Text") of the editor toolbar is too big.
task-3597377
closesodoo/odoo#144892
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In the past, it was possible to drop elements in non-editable areas.
Commit [1] fixed the issue but then commit [2] added a solution to be
able to edit a media element that is in a `o_not_editable` environment.
Unfortunately, the solution makes it possible to drop elements next to
the `o_editable_media` elements ignoring the editable context (ignoring
the first fix).
Steps to reproduce the issue:
- Enter website edit mode
- Drop a Team block in a page
- Click on the Team block
=> The user is able to drop a "Text highlight" block next to the team
member pictures.
This commit
- reverts the commit [1] because in the meantime, the commit [3] fixed
the issue.
- fixes the Team block issue.
- fixes the filterFunc for the drop-in.
- adds a test to ensure the issue doesn't come back.
[1]: https://github.com/odoo/odoo/commit/67924648676b37898aedd86bc32868299aee542c
[2]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[3]: https://github.com/odoo/odoo/commit/ae7452f18dbd6ed56dbf883ae8495382b336aa78
opw-3536227
closesodoo/odoo#144806
X-original-commit: 9b4c2498b8fa2bc0aca604b6256e6c805b9b4c10
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
During upgrades, customization modules are defined in the database but
their codebase is not in the addons path.
Because of this, when running an upgrade the manifest of such modules
does not exist which makes `_generate_primary_snippet_templates` fail
because it cannot locate some default keys.
This commit adapts the access to the manifest in order to use a default
value in case the manifest is not available.
closesodoo/odoo#144222
Related: odoo/design-themes#751
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
If the first theme that generates configurator templates has the same
block used several times within a single page, a unique constraint is
violated because it tries to create several identical
`configurator_<pagename>_<s_snippet_name>` templates.
This commit avoids this by only considering unique snippet names.
The issue typically appears with `s_title` on `theme_monglia` and
`theme_real_estate` if they are installed by themselves.
Part-of: odoo/odoo#144222
When shapes were extracted to configurator snippets in [1], some
configurator-specific snippets were created that do not appear on pages
of the specific theme.
Because in [2] the call to `_generate_primary_snippet_templates` is done
on a full list of themes instead of only the installed ones, the problem
was not noticed: if any theme defines a block, it's website-side
configurator-specific template is generated.
This is not the case during an upgrade: the templates are generated only
for the installed themes. Because of this some "useless" configurator
templates trigger an error when importing their XML definition because
their parent template does not exist.
This is fixed in design-themes by adding those templates in a pseudo
page `_` in the `configurator_snippets` entry of each theme's manifest.
This commit makes sure to not consider that `_` page name as an actual
page name.
In master, the templates will be removed instead.
[1]: https://github.com/odoo/design-themes/commit/d206c119720d557c11320ebb3d7339890b8f9efa
[2]: https://github.com/odoo/odoo/commit/928eeca714a161f6bc03343e4dc8af9b050b9841#diff-f49a1e9eda23df9f1d48121ba376a5fabafe70ea18b29d4eab23d737e5d4eeb6R446
Part-of: odoo/odoo#144222
The website_page_controller_expose is a technical model for portal and
public, not for employee
The side-effect of the change was that, before this commit, the
category Website was no longer a selection but a list of boolean only
accessible in debug mode
closesodoo/odoo#144342
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
For multi language website, when request http:/localhost/en/something,
Odoo reroutes from the requested path /en/something to the new path
/something with lang=en_US in context.
If the new path is a unicode string like http:/localhost/vi/xin-chào,
http:/localhost/ru/привет, a error should occur at
werkzeug._compat.wsgi_decoding_dance() because the path was not latin1
string.
The utf-8 encoding followed by a latin-1 decoding is required by the
WSGI specification[^1]. latin-1 is used as an encoding passthrought:
that encoding has a representation for all the 256 bytes, i.e. it is
impossible that decoding a text will raise a ValueError. The WSGI spec
uses this trick to save values until the actual charset (present in
the Content-Type header) in known.
[^1]: https://peps.python.org/pep-3333/#a-note-on-string-typesclosesodoo/odoo#143898
X-original-commit: 9b69b87c08b1d62b3581fe651bee692a4f217dff
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The goal of this commit is to prevent the text animation overlay from
blocking small text content selection.
Remark: This behavior was already fixed on 17.0 (by [1]) for text
animations and highlights and was backported here for text animation
options.
[1]: https://github.com/odoo/odoo/commit/f64c9f27f1a9106bc009ad2f696845f2c5c58066
Related to task-3285817
closesodoo/odoo#144086
X-original-commit: b69e105149e5f0dc6a469068ab037b717e017144
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
In the Social Media snippet options, only icons with a `<i>` tag are
considered when updating the social media classes (when adding a new
social network by copying the first one and when replacing the icon by
another one matching the URL). However, there are cases where the icon
is a `<span>` element (with a `fa` class) and not a `<i>`.
For example:
- Replace a social network icon by a real image.
- Re-replace this image by an icon.
=> the icon element tag is `<span>` and not `<i>`.
In this case, after setting its style correctly (e.g. adding the round
shape) to make it look like the other icons, we notice that it does not
behave like the other ones:
- It is not aligned with the other icons, because the CSS rule aligning
them only targets `<i>`.
- Its icon is not replaced by a matching one when changing the URL with
a "relevant" one (e.g. google, facebook).
This commit considers `<span>` icons in the Social Media options, in
addition to `<i>` icons, in order for them to all behave the same way.
opw-3538230
closesodoo/odoo#144076
X-original-commit: a8b5c3045bea0227304306e19ed9d50cf497f518
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
When using the "Social Media" snippet, there are two situations leading
to a traceback. Here are the steps:
1) First issue
- In edit mode, drop the "Social Media" snippet.
- Add a new social network.
- Replace the icon by a real image (so not by an other icon).
- Set the URL of the new social network to a "relevant" one (e.g.
google, facebook).
=> traceback
2) Second issue
- Drop "Social Media" and change the list in order to have the first
social network with a real image as icon: either replace the first icon
with an image, or add a custom one with an image an move it to the top.
- Add a new social network.
=> traceback
Both issues happen because only icons set as `<i>` elements are taken
into account when modifying a social network (`querySelector('i')`) and
this element may not exist if the icon had another tag (like an image or
a span or even a video (as the media dialog allows to upload them)). As
there is no check ensuring that the element exists before changing the
different social media classes, there is a traceback when the `<i>` is
not found.
For the first issue, it happens because when changing the URL, we first
check if it matches with relevant ones or if an icon matching it exists.
If it is the case, we then update the social media classes to set the
matching icon => it can only work if the icon is a `<i>`.
The second issue happens because when adding a new social network, it
actually copies the style of the first one (unless there are none, a new
one is created in that case). If the first one is an image, it fails
when updating the classes because it is not a `<i>`.
This commit fixes these issues by simply adding checks ensuring the icon
element exists before trying to modify it. It also adds tests, ensuring
these use cases work as expected.
opw-3538230
X-original-commit: 0132fa38baee6501f4257dad718359400f1369ad
Part-of: odoo/odoo#144076
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 changes the timeout of the OLG call to 20s. We don't want
users to wait too long for the creation of a new website.
Related to task-3248852
closesodoo/odoo#137703
Signed-off-by: Romain Derie (rde) <rde@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>
A custom script is modifying the output of
load_information_from_description_file to disable the
auto-install of modules during local testing. It was naively adapted for
v16.0 by replacing the corresponding methods. Since a lru cache was added
(nice optimization in most cases) this is an issue because running lint
test afterward will get the cached value with an incorrect autoinstall
value. It makes sens to avoid reading the file on the filesystem each
time, but making a deepcopy looks like an acceptable safeguard to avoid
hard to debug behaviors.
closesodoo/odoo#143628
X-original-commit: ad10ff4410ccf7c38f6154480484495bb57c53ff
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@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>
__Current behavior before commit:__
When searching for an **Internal Reference** of a product variant on the
website shop, the fuzzy search is likely to return a wrong result.
If the **Internal Reference** of a product template resembles the
searched term, it will take it as a fuzzy term and will not even search
for product variants internal references.
This is because the method `_basic_enumerate_words` only parses the
fields of the model considered but not the "subfields", in this case the
`product_variant_ids.default_code`.
__Description of the fix:__
Run `_search_exact` in any case and only then, if no result is found,
run a fuzzy search.
__To reproduce on runbot 15.0:__
In the website shop, search *FURN_0096*. Although there is a variant
of *Customizable Desk* that has this exact **Internal Reference**, the
search will only return *Office Chair Black* because this product
template has a **default_code** set (*FURN_0269*).
opw-3476643
closesodoo/odoo#143635
X-original-commit: 5887b4f7246dac734f192025404d65002fff6f20
Signed-off-by: Benoit Socias (bso) <bso@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>
This commit fixes a bug in page creation by the configurator. This only
happened with pages containing only one snippet, like the "Pricing" page
or the "Privacy Policy" page (default themes). Because of this bug, the
snippet that should be placed in the page had its parent element
"<section>" replaced with a "<div>", so the section options were no
longer available in edit mode, such as background options,
delete/duplicate/save the snippet, etc.
When there was multiple snippets, it worked by chance:
`<section></section><section></section>` was parsed as
`<div><section></section><section></section></div>` using the etree lib.
The web_editor `save` method then copied each children and put them in
the targeted oe_structure.
However, with only one snippet:
`<section><div class="container"></div></section>`
it was parsed as it is, then same: each children was copied and put in
the targeted oe_structure... but the only child here is the `container`.
Then the classes of the section were transferred on the oe_structure
element.
Steps to reproduce the bug:
- Create a new website using the configurator.
- Check the "Pricing" box in the list of features to create the
"Pricing" page.
- Once the website creation is complete, go to the "/pricing" page.
- In edit mode, click on the "comparisons" snippet.
- Bug: Some options are missing for the snippet, for example, it's not
possible to delete the snippet or change its background.
task-3570903
closesodoo/odoo#143049
X-original-commit: 68ffe065c6fa03874ee8c99b91ca317d1c2755a3
Signed-off-by: Quentin Smetz (qsm) <qsm@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
The "reset password" feature does not take into account
multi-website.
steps to reproduce:
- create a website A
- uncheck 'Shared Customer Accounts' on website A
- create a portal user user@example.com on website A
- create a website B
- uncheck 'Shared Customer Accounts' on website B
- create a portal user user@example.com on website B
- reset password for user@example.com on any website
before this commit:
An error is raised "No account found for this login"
(which is false, actually 2 accounts are found)
after this commit:
Only the user linked to the current website is properly
selected
opw-3551540
closesodoo/odoo#142110
X-original-commit: a2196253d6cf90dca3042a777703e0679f74f542
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The header call to action button template was extended by other ones
based on classes that can be changed using the Odoo editor. So if you
changed them, saved then toggle those other template options... you
broke your header.
closesodoo/odoo#141694
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1], when an error exists in an asset, the assets raise a not
found exception. The issue, is that, there is no feedback for the
developer to find the error.
Now, a new console log with the error details is shown.
[1] : bf3b6b0b8bclosesodoo/odoo#141705
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
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
Romain Derie