Attempt to fix race condition:
> Tour edit_link_popover failed at step Change the URL
(trigger: #o_link_dialog_url_input)
According to the runbot build screenshot from the error [1], when clicking on
the navbar `Home` menu, the previously deleted link on the `<p/>` is not really
deleted.
According to the runbot logs, some extra calls are done to `/`, probably coming
from extra preview calls.
It might be coming from the fact we click on the link itself to exit the right
panel URL edition.
This commit click on a non-link element to exit the right panel URL edition,
avoiding to show a popover for nothing.
[1] See the image on pull request
closesodoo/odoo#70487
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The page manager shows an advanced structure if the user has multi website
enabled. It will show specific pages as a child of its generic one.
It is useful to directly understand and figure which pages are 'overiden'.
But it doesn't really makes sense for an end user, which doesn't know there is
actually generic and/or specific pages.
It makes more sense to show that behavior only in debug and not in multi
websites, even more since pages are overiden even in mono website.
closesodoo/odoo#68902
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the routing map generated and used would be the one from
the website the request is performed, instead of the one from the `fw` website
ID which will be the one we redirect the user to.
This issue was introduced with the routing map by website, be8fc2296b and is
restricted to a single case: a publisher using the website switcher, and it
won't happen on next page naviguation/refresh as the `fw` website id will be
the same as the current website's ID. Thus there won't be any routing map
mismatch.
Step to reproduce:
- Create a page on website 2, set it as homepage
- Naviguate to website 1 on '/' url
- Naviguate to website 2 on '/' url
This will raise a werkzeug error about `EndPoint not iterable`.
----- Technical analysis ------
This is the current flow:
1. `_dispatch()` is setting `website_routing` to `get_current_website()` -> 2
2. `_dispatch()` is calling `_match()`
3. `_match()` is calling `routing_map()` with key = `website_routing`, which
was set to 2 in step 1.
4. `routing_map()` is calling `_generate_routing_rules()` which generate the
rules based on `website_routing`, which was set to 2 in step 1.
5. `_dispatch()` authenticate the user by calling `_authenticate()`
6. `_dispatch()` is calling `_add_dispatch_parameter()`, where URL param `fw`
is forced in session, so `get_current_website()` now return the correct
`website_id` -> 1
The issue: in order to handle the `fw` URL parameter (step 6.), we need to
check the rights to ensure we can allow the website switch.
To check rights, user need to be authenticated (step 5.), which is done after
generating the routing map (2. & 3. & 4.).
The routing map is generated based on the current website (step 1.)
Step 6 depends of steps 5 which depends of steps 2/3/4 which depend of step 1,
but step 1 should depend of step 6, which is an impossible cycle.
closesodoo/odoo#70397
X-original-commit: 4eb26497a774e934d7e1a6be9f505400fd9e2cdb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
This commit will add the needed ESLint configurations on the JS files.
These configurations are added if the JS file uses a different
environment (serviceworker, node, etc) or if it uses a specific global
(google, ace, etc).
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Previously :
Once a user enabled the cookie bar, it prevented him from dropping
snippets in the main area of the page because the focus was on
the cookie bar. Dropping snippets there has a confusing behavior and
might make the user think the editor is broken.
Reason :
The cookie bar has an oe_structure class and takes over the body
if it's not hidden or dismissed. The oe_structure allows to drop
snippets.
Fix :
Hiding the cookie bar when user enters edit mode to avoid dropping
snippets in it by mistake.
task-2477430
closesodoo/odoo#70258
X-original-commit: 8c672662c80d0dfaeb06eedfc7136a68734fbdb3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This replaces the setup of the attribute 'currency_field', which depends
on the presence of other fields on the model, and may therefore vary
from one registry to another. This is necessary to make monetary fields
shareable across registries.
The attributes field.depends and field.depends_context are problematic
for sharing fields across registries, because they depend on the model's
registry class, which may vary from one registry to another. In order
to make computed fields shareable, we have to move those values away
from fields.
For the same reason, field.recursive should not be inferred, because its
value may depend on the registry, although it is generally not the case.
Moreover, the flag recursive=True is set on a field when field triggers
are determined (on the registry). A compute method may be called before
the flag is set (if no update has been done yet), and that can lead to
incorrect computations.
This happened in test TestUsers2.test_reified_groups in module 'base'.
The user groups view was apparently determined without the flag being
set, and the view depends on the recursive field 'trans_implied_ids',
which was not correctly computed.
We thus force developers to be explicit about recursive computed fields.
The code now logs a warning when the flag is not set up properly.
Some feature descriptions and titles have been reworded.
A sentence has been added below the title to indicate
that choices made on this screen are not definitive.
Task ID: 2451965
closesodoo/odoo#70252
X-original-commit: 63195ba03ccc1bf40b4682fc7c9aa4a1a55f1e43
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Previously, when toggling on background shapes, they always had the
default colours. In [1] we made it so that when you toggle on a shape on
a section, it would automatically reuse the colors of the surrounding
shapes if any.
Unfortunately, when the "implicit" colors were also the default colors,
they were still marked on the shape, and it got an explicit background
image that would no longer react to changes in the palette.
This was caused by the fact that the call to _getDefaultColors returns
an empty object when the section doesn't already have a shape-container,
this was not a problem before since we were not passing in any colors
when creating the initial shape previously, the the aforementioned
change made it so that we did.
This commit fixes the issue by creating the shape-container before
calling the method that will set the colors on the shape, this way
getDefaultColors works as expected, and the colors are not marked on the
section when they are the default ones, restoring the ability of the
shape colors to adapt to the palette
[1]: https://github.com/odoo/odoo/commit/875aca63f7dab287c61485ebe999b3b8dd89d91c
task-2500607
closesodoo/odoo#70054
X-original-commit: 63acc2b0d1957dedd40af2033722f9ea4ef2e597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Tom De Caluwé <tdc@odoo.com>
Make translation works for "Website Visitor" that was appearing when a
logged-out user open a livechat session.
note: list comprehension has to be removed since translation only search
language in direct calling method closure.
opw-2504461
closesodoo/odoo#70146
X-original-commit: 7d28f32d9be1590764883f4621df04e04c4e1f12
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Convert `custom_code_*` to `Html` with no sanitization, such that qweb
considers them markup-safe.
`base_popup_options` value comes from a rendered XML body so should
already be safe
raw -> out in the extended website info template, not sure why this
was even raw
Also mark robots_txt as an unsanitized Html field, that's
not *actually* true but it is true enough for our purposes, especially
since the field gets edited through a text-mode wizard.
One was always there, the other was apparently added due to a double
escaping issue.
Seems unnecessary either way:
- Additional_title should always be set via markup, meaning it's
marked as safe (if necessary).
- The other one is less clear but neither website.name nor
company.name should contain markup so...
Trying to repro the issue reported at 1725212, still seems to work
fine.
* QWeb bodies should be markup-safe so `0` should always be
markup-safe.
* `head` is qweb-rendered so the same.
* The `json` pseudo-module in qweb templates is `json.scriptsafe`,
which should be markup-safe.
`markupsafe.escape` always escapes single and double quotes, and
escapes them to their numeric values rather than symbolic
According to pallets/jinja@f35e28154f,
this is for compatibility with HTML 3.2: the only named entities in
the HTML 3.2 DTD are `amp`, `gt`, and `lt`.
Update tests to match.
Add a big fat warning when the qweb compiler finds a `t-raw`.
`t-esc` should now be used everywhere, the use-case for `t-raw` should
be handled by converting the corresponding values to `Markup`
objects. Even though it's convenient, this constructor *should never
be made available in the qweb rendering context* (maybe that should be
checked for explicitely?).
Replace `werkzeug.escape` by `markupsafe.escape` in
`odoo.tools.html_escape`, this means the output of `html_escape` is
markup-safe.
Updated qweb to work correctly with escaping and `Markup`, amongst
other things QWeb bodies should be markup-safe internally (so that a
`t-set` value can be fed into a `t-esc`). See at the bottom for the
attributes handling as it's a bit complicated.
`to_text` needed updating: `markupsafe.Markup` is a subclass of `str`,
but `str` is not a passthrough for strings. So `Markup` instances
going through would be converted to normal `str`, losing their safety
flag. Since qweb internally uses `to_text` on pretty much
everything (in order to handle None / False), this would then cause
almost every `Markup` to get mistakenly double-escaped.
Also mark a bunch of APIs as markup-safe by default
* html_sanitize output.
* HTML fields content, sanitization is applied on intake (so stripped
by the trip through the database) and if the field is unsanitised
the injection is very much intentional, probably. Note: this
includes automatically decoding bytes as a number of default values
& computes yield bytes, which Markup will happily accept... by
repr-ing them which is useless. This is hard to notice without `-b`.
* Script-safe json, it's rather the point (though it uses a
non-standard escaping scheme).
* Note that `nl2br`, kinda: it should work correctly whether or not
the input is markup-safe, this means we should not need to escape
values fed to `nl2br`, but it doesn't hurt either.
Update some qweb field serialisations to mark their output as
markup-safe when necessary (e.g. monetary, barcode,
contact). Otherwise either using proper escaping internally or doing
nothing should do the trick.
Also update qweb to return markup-safe bytes: we want qweb to return
markup-safe contents as a common use-case is to render something with
one template, and inject its content in an other one (with Python code
inbetween, as `t-call` works a bit differently and does not go through
the external rendering interface).
However qweb returns `bytes` while `Markup` extends `str`. After a
quick experiment with changing qweb rendering to return `str` (rather
unmitigated failure I fear), it looks like the safest tack is to add a
somewhat similar bytes-based type, which decodes to a `Markup` but
keeps to bytes semantics.
For debugging and convenience reasons, MarkupSafeBytes does *not*
stringify and raises an error instead (`__repr__` works fine). This is
to avoid implicit stringifications which do the wrong thing (namely
create a string `"b'foo'"`).
Also add some configuration around BytesWarning (which still has to be
enabled at the interpreter level via `-b`, there's no way to enable it
programmatically smh), and monkeypatch `showwarning` to show warning
tracebacks, as it's common for warnings to be triggered in the bowels
of the application, and hard to relate to business logic without the
complete traceback.
`t-out`
=======
`t-esc` is a bit confusing for the new behaviour of "maybe escape
maybe not", so add a `t-out` alias with the same behaviour.
Unlike `t-raw`, `t-esc` is only soft-deprecated for now: there are
thousands of instances, so editing all the templates is not
great. Eventually we'll add a `ci/style` to prevent addition of new
ones, and eventually we might do a bulk-replace and hard-deprecate.
Attributes handling
===================
There are a few issues with respect to attributes. The first issue is
that markup-safe content is not necessarily attributes-safe
e.g. markup-safe content can contain unescaped `<` or double-quotes
while attributes can not. So we must forcefully escape the input, even
if it's supposedly markup-safe already.
This causes a problem for script-safe JSON: it's markup-safe but
really does its own thing. So instead of escaping it up-front and
wrapping it in Markup, make script-safe JSON its own type which
applies JSON-escaping *during the `__html__` call.
This way if a script-safe JSON object goes through `markupsafe.escape`
we'll apply script-safe escaping, otherwise it'll be treated as a
regular strings and eventually escaped the normal way.
A second issue was the processing of format-valued
attributes (`t-attf`): literal segments should always be markup-safe,
while non-literal may or may not be. This turns out to be an issue if
the non-literal segment *is* markup-safe: in that case when the
literal and non-literal segments get concatenated the literal segments
will get escaped, then attributes serialization will escape
them *again* leading to doubly-escaped content in attributes.
The most visible instance of this was the `snippet_options` template,
specifically:
<t t-set="so_content_addition_selector" t-translation="off">blockquote, ...</t>
<div id="so_content_addition"
t-att-data-selector="so_content_addition_selector"
t-attf-data-drop-near="p, h1, h2, h3, .row > div > img, #{so_content_addition_selector}"
data-drop-in=".content, nav"/>
Here `so_content_addition_selector` is a qweb body therefore
markup-safe, When concatenated with the literal part of
`t-atff-data-drop-near` it would cause the HTML-escaping of that
yielding a new Markup object. Normal attributes processing would then
strip the markup flag (using `str()`) and escape it again, leading to
doubly-escaped literals.
The original hack around was to unescape() `Markup` content before
stringifying it and escaping it again, in the attribute serialization
method (`_append_attributes`).
That's pretty disgusting, after some more consideration & testing it
looks like a much better and safer fix is to ensure the
expression (non-literal) segments of format strings always result in
`str`, never `Markup`, which is easy enough: just all `str()` on the
output of strexpr. We could also have concatenated all the bits using
`''.join` instead of repeated concatenation (`+`).
Also add a check on the type of the format string for safety, I think
it should always be a proper str and the bytes thing is only when
running in py2 (where lxml uses bytestrings as a space optimization
for ascii-only values) but it should not hurt too much to perform a
single typecheck assertion on the value... instead of performing one
per literal segment.
Note: we may need to implement unescape anyway, because it's still
possible to get double-escaping with the current scheme: given an
explicitly escape-ed `foo` and `t-att-foo="foo"`, `foo` will be
re-escaped.
fixup! [CHG] core, web: deprecate t-raw
Before this commit, we would compare a lang `code` (used in context) and a lang
`url_code`. For languages where those 2 are differents, the `if` condition
would always be falsy, making the canonical URL impossible to be reached.
Technically, this condition is used to get the translated name of records to
later construct the canonical URL.
Since the canonical URL will be incorrect and unreachable, the whole system to
tell search engine/crawler about translation won't work since no
`alternate/hreflang`[1] will be set in the DOM.
[1] see https://developers.google.com/search/docs/advanced/crawling/localized-versions
--------
Technical explanation:
- italian language `code` = `it_IT`, `url_code` = `it`
- belgian french language `code` = `fr_BE`, `url_code` = `fr_BE`
Install those languages on website as secondary languages.
Translate blog `Travel` to `Voyager` in french and `Viaggi` in italian.
Visiting `/fr_BE/blog/travel-1/post/post-1` will redirect to
`/fr_BE/blog/voyager-1/post/post-1` as it should, and the canonical URL will be
set to that same URL.
Visiting `/it/blog/travel-1/post/post-1` will redirect to
`/it/blog/voyager-1/post/post-1` as it should, but the canonical URL will be
set to `/it/blog/travel-1/post/post-1`.
opw-2486918
closesodoo/odoo#69918
X-original-commit: 733411fe03b924832d6b10cadf93c8fc09cc5802
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Add the 'data-snippet' attribute on each snippet rendered
by the configurator when building website pages.
closesodoo/odoo#69706
X-original-commit: 7c203eda4210eec7db476aa5ac056150b795b921
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
The timeout for images download from unsplash is set to
3s. The exception raised when this limit is reached was
not correctly handled.
closesodoo/odoo#69758
X-original-commit: abca5f73c9e2b992f2638341e81bcb01d86872a6
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
A colorpicker in an option positioned above the toolbar in a snippets
menu would be hidden by the toolbar because of the toolbar's z-index.
That z-index is only needed when the editor is in a modal.
The bug this commit fixes only arises when the toolbar is in a snippets
menu.
This applies the z-index only when there is a snippets menu in the page.
To accomplish that we need the "editor_has_snippets" class that the
website module applied to the body. For the sake of harmony within Odoo,
that class is now applied by snippets.editor so that no matter the
module, if there is a snippets bar, the class is on the body of its
document.
closesodoo/odoo#69680
X-original-commit: b1aa9c6093cea918337d5600ff9b16b7dd80de23
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Add a new parser in the ace for the qweb highlight. This makes it possible
to visualize the qweb tags and the part of code.
Used in the website and in xml fields.
closesodoo/odoo#69609
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Strings in python expression in 't-att-placeholder' are not translated
automatically.
opw-2467404
closesodoo/odoo#69559
X-original-commit: 8f8d55ee4e773884ab35e11bfd0573d7997f3ad3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, the top position of a modal in website was always
the height of the main menu navbar. Even if the main menu navbar was
not displayed when the user is not logged.
That bug was introduced in 6ef622772f
After this commit, the top position of a modal is the height of the
main menu navbar but only if that navbar is displayed.
task-2507949
closesodoo/odoo#69391
X-original-commit: 00ab01d05b3876c5d926e16b9a5d65ace4df7360
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
On initialization, the website configurator makes a
call to an external service (api_website) hosted on
iap-services.odoo.com to retrieve a list of industries.
This call might fail if the external service is done.
This potential failure is now correctly handled:
On '/api/website/1/configurator/industries' call
failure, the configurator is silently skipped and the
user is redirected to the view website.theme_view_kanban
closesodoo/odoo#69465
X-original-commit: 35311608197ec77bafed82505639314ca693fb19
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit fixes multiple bugs related to the new link popover edition [1].
Those bugs mostly comes from new editor integration [2] conflicts, as those
where merged almost at the same time and needed a quick fix of rebase
conflicts.
- The navbar & footer link would not load the popover link edition anymore,
as it was only targetting `#wrap`.
- Double click on links was re-introduced but it was supposed to be gone.
- Tooltip from Edit and Unlink inside the popover remained open after popover
was closed.
- Some leftover code that were not related to popover but kept during the
rebase.
[1] Commit 8fcf930a6b
[2] Commit 740168ce8dclosesodoo/odoo#69389
X-original-commit: e13966cc8e04111a9e18a344132546c6baa79fea
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
The following two points are necessary adaptations for
the correct functioning of the configurator with the
module deployed on iap-services.
- The routes of the api_website module deployed on
iap-services.odoo.com use model converters to retrieve
the industry selected by the user. The configurator
has been updated accordingly. We now use industry id
instead of industry name. Using id instead of name make
record retrieval faster and model converters handle
exception if the record doesn't exist.
- 'homepage' is now added to the requested pages by
the client. Previously, this page was added by the iap
module to the requested pages.
The following two points are changes to the configurator
route handling:
- multilang=False has been added to the route rendering
the configurator in order to avoid having the lang in
the url.
- If no step is specified in the url, the implicit step
is 1. Therefore /website/configurator/1 has been changed
to /website/configurator.
closesodoo/odoo#69370
X-original-commit: b6efa4caf6514484c254869cb2f1965d207e7c65
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
If the user type his website URL as suggested by the helper, and he redirects
his `http` to `https` (nginx, cloudflare..), then his canonical url won't ever
be reachable.
Most critical issue will be that we won't display the `alternate/hreflang` tag,
which basically tells the search engines what and where is our translated
content.
opw-2486918
closesodoo/odoo#69093
X-original-commit: 15bf30b7b5312a943772ece20303e215b1ed6f6c
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
The website scroll effects using the `AnimationEffect` Odoo API were not
working anymore if custom code enforces the html element as the
scrolling element. Indeed in that case the scroll event handlers were
now attached to the html element itself while it needs to be the window
in that case.
This may be something to fix at the source (the `getScrollingElement`
method). This will be checked later.
closesodoo/odoo#69087
X-original-commit: 21650ce342d0329c5385acf1181be154abbec550
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Without this commit, a database with only one website would not see the domain
field in the res settings.
But the domain field is useful to set even if there is only one website.
For instance, if no domain is specified, the web.base.url ICP will be used
instead to generate links, but it might be the wrong url as it is the last
domain used to login as the admin (unless web.base.url.freeze is set).
Also, one might want to unset the `localhost` domain that was set by default
in xml data (now removed with 1f0edacdf)
closesodoo/odoo#69038
X-original-commit: 0650862c7adcbe4113e071778a66053b88e004ef
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Rationale:
The majority of cases where an ir.asset is manually declared
outside of manifest files is to specifically add a single asset file.
This means developers are specifying a single asset *path*, and not a
glob expression. In this context, it seems better to name the filepath
field `path`, and document that it can be specified with a glob
expression when (seldom) needed, rather than making the exception appear
to be the norm - possibly puzzling many developers (What's a glob and
why do I need one?)
The doc is updated as well, and some spell-checking and wording
improvements were done too.
This required some adaptations to the existing `ir.asset` declarations:
- odoo/enterprise#17465
- odoo/design-themes#459closesodoo/odoo#68695
Related: odoo/upgrade#2348
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Without this, the website selector was not working
closesodoo/odoo#68877
X-original-commit: 967132be52d259eaa89b7c0d32b8e4a116d4ad9e
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The eCommerce module installation is sometimes taking over 30 seconds,
to manage the user wait a loader is now displayed during the
process.
Part of https://github.com/odoo/odoo/pull/68823
task-2446852
X-original-commit: 9a75b8cc09b3210e0a555f225ac347801b584d3a
When moving blocks up and down, the speed has been decreased by 35%, as
it was too fast for the user before.
Part of https://github.com/odoo/odoo/pull/68823
task-2446852
X-original-commit: cbbaa74fe15efd19e0614d984247995af9a64247
It prevents users accidentally writing below the image when they modify
the snippet.
Part of https://github.com/odoo/odoo/pull/68823
task-2446852
X-original-commit: b6684fcdf6b62b6d12dd500ca5f9c2187a91fe97
The option to add the label "Share" before the social media icons is
still usable.
Part of https://github.com/odoo/odoo/pull/68823
task-2446852
X-original-commit: c5c601ec18ad415320ccfa9012b9a1c17e080040
Icons were not centered in the share snippet.
Part of https://github.com/odoo/odoo/pull/68823
task-2446852
X-original-commit: 6b2a6b3d6730b320f673ee544b2be607a258f914
Added o_not_editable class to carousel-control-prev and
carousel-control-next container divs so that the user can't add text
when sliding carousel items
Part of https://github.com/odoo/odoo/pull/68823
task-2446852
X-original-commit: a6d52aed947180bf73718aa95ac3b4e0016e4a9f
On website app installation and on new website creation a configurator is launched.
The purpose of this configurator is to generate a website that meet the user's needs.
The configurator is composed of 4 steps:
1) Business description: the user is asked to describe its need with its website purpose (dropdown), its industry (autocomplete search) and its objective (dropdown).
2) Logo and palette selection: the user must select a color palette for its website. He can also upload its logo. In this case color palettes recommendations are generated based on the logo's colors.
3) Features selection: the user select the pages and applications he needs.
4) Theme selection: three themes are recommended to the user based on its industry. This screen display a preview of these three themes.
task-id: 2451965
ENT PR: odoo/enterprise#16949
UPG PR: odoo/upgrade#2316closesodoo/odoo#67537
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
- The test was clicking on a link "too soon" in some cases (editing a
link then immediatly clicking on it while the save action is not fully
performed). Ideally, this should probably be more robust around the
save action to first edit the link synchronously then perform the
actual save in DB but this can be checked later on.
- Removed useless popover update while it was hidden.
- Make sure that two consecutive update of the popover only updates its
UI relying on the last asked data.
- Make sure the popover correctly clean what it did once destroyed
(however, it is never actually destroyed for now... to check later).
closesodoo/odoo#68686
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
*: portal, portal_rating, product, sale, sale_product_configurator,
website, website_sale_comparison, website_sale_product_configurator,
website_sale_stock, website_sale_wishlist, point_of_sale
Redesign of the product page + various UX improvements.
task-2009483
Part of #66736
*: website_form
This commit introduces a simple & light popover/tooltip (as in Google Doc) when
editing a link.
It will be used:
1. (web_editor) On every page links.
2. (website) In the website navbar, when clicking on a menu, it will replace the
popup shown to ask the user what he wants to do (edit the menu or go to the link
or do nothing). That popup was a bit invasive and old-fashioned.
Part of https://github.com/odoo/odoo/pull/64756
task-2439860
closesodoo/odoo#64756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Romain Derie