Commit [1] introduced an automatic start of edit mode when
selecting a theme but didn't take into account wether the frontend lang
of the user was matching that of the website that is supposed to enter
in edit mode.
Steps to reproduce:
- Create an empty database and install website.
- Add an extra lang on website (e.g FR) and visit the website in that
lang.
- Go in settings an create a new website, skiper the configurator,
select a theme.
- Redirect is with enable_editor but nothing happens.
The editor isn't started if not in the source's lang.
This commit redirect the user to the default_lang of the website
so that editor can always be started. It also introduces a tour
to test out the flow.
[1]: https://github.com/odoo/odoo/commit/f474eac4543712ae5b1c7d614f9eff9367445107
task-2687416
closesodoo/odoo#85058
X-original-commit: 02e08af7278cd66d768fe6a4f23aa17eb816be3c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] when fuzzy search was introduced, fuzzy search was also used
when the search term contained numbers.
This is a problem for companies where the shop search is used on
references: the fuzzy search does not match against the whole database
and therefore the exact match might not be found.
After this commit the exact search is used whenever the search term is
made of 80% of numbers or more - because it is very likely to be a
reference or an identifier.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
opw-2715647
closesodoo/odoo#84943
X-original-commit: 7b44907c322a7b78ef4a5cb46627df4f72b21240
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The configurator introduced at [1] uses a frontend controller to
display its content. However this results in inconsistent language
translation as the python code uses the users's language but the
localization services uses the frontend's language when on a frontend
page.
Steps to reproduce:
- Create a database with the only language being french
- Install website
- In the configurator, all the pages will be in french except
"Pages and Features"
With this commit, the language for the configurator will always be
the language of the website it's configuring. A test also make sure
that this is the current behavior.
[1]: https://github.com/odoo/odoo/commit/e8a5af2e28a4724f86783746706cb59175f086bf
task-2687416
closesodoo/odoo#84810
X-original-commit: a0f8fdc65566fafe98dab21f5c2dbab9505c3d5c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the users with the "editor and designer" role no
longer had access to the theme tab options (and also other flows like
assets regeneration in debug mode, etc). This is because when the
website assets have been changed to be handled by ir.asset records, in
this commit [1], the "editor and designer" rights were not updated to
have an access to ir.asset.
After this commit, the users with the "editor and designer" role have
the rights to access ir.asset (read, write, create, but not unlink
because the admin does not need it).
This mimick what is done with ir.ui.view, which is way more critical
than ir.asset, so it should be relatively safe to add this right to the
website admin for assets, as it is already the case for views.
We could have added sudo() everywhere (as no need of a -u, and which is
less risky that adding rights directly through csv but the ir.asset
rights covers too many different flows to do so.
[1]: https://github.com/odoo/odoo/commit/8cc066173dfb61bd95b8e1f0716f71f4e251810a
task-2748004
closesodoo/odoo#84847
X-original-commit: e3515a7b73c3e173a3ddf0bc48e4a888024c8817
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
PURPOSE
Visitors are useful in terms of marketing analysis but they can bloat the
database really quickly if you have a lot of traffic on your website.
This commit aims to relieve the database by fully deleting inactive visitors.
SPECS
On an active website, you can easily reach hundreds or even thousands of
visitors per day.
While active visitors are useful for marketing purposes, inactive ones were
archived after a period of inactivity (i.e: not connected for X days in a row,
where X is configurable as a parameter and 30 by default).
But archiving visitors is not really useful either.
We don't see any specific cases where you would want to restore some visitors.
That means we are better off unlinking the visitors completely to save database
storage space.
We want to make exceptions and avoid deletion of inactive visitors in some
cases:
- When they are linked to a partner (meaning most likely linked to a
registered user)
- When they are linked to leads
- When they are registered to events
Several tests were added to ensure that leads matching these conditions are not
unlinked.
We also took this opportunity to enforce the "_link_to_visitor" rules in those
tests to make sure that:
- When visitors are linked, the leads are merged into the main visitor
- When visitors are linked, the event tickets are merged into the main visitor
- When visitors are linked, the wishlisted tracks are merged into the main
visitor
This is also preliminary work for a commit that will move the push_token of
website.visitors to a separate table.
That will in turn allow us to link the push_tokens within the
"_link_to_visitor" method and delete the linked visitor instead of archiving
it.
LINKS
Task-2410217
Part-of: odoo/odoo#65113
The concept of 'parent_id' on website.visitors was introduced in the saas-13.3
stable while implementing the "event online" feature:
However, it should have been part of the website module from the start since
it's a 'global' concept that does not depend on events at all.
See #53540 for more details.
This commit aims to clean the code by moving the field to the website module,
which allows a nice cleaning of associated overridden methods as well.
Along with that, we move the website.visitor demo data from the event module to
the website module, allowing a fresh install of website to showcase some of our
visitors feature.
We also took this opportunity to do some minor improvements in the visitors
kanban view in order to make relevant information more visible.
Task-2429652
Part-of: odoo/odoo#65113
Before this commit, during edit mode, the user was able to interact with
form elements. In 13.0, it was somehow prevented by some JS code by
losing the focus immediatly but it was not enough: if typing quickly the
user was able to type text. But the real problem was the user seeing the
input focused for half a second then not anymore, making him think a bug
occured. Worse, the datepickers of the form snippet were able to be used
entirely during edit mode, making the user think it is possible to
configure a default value (which was not true in 13.0). In following
versions, the bug is indeed worse as it messes up with the default
values configuration. In 14.0, it is apparently possible to type
normally in all of those inputs... although still ignored on save. In
15.0... the 13.0 behavior of losing the focus immediatly is back though.
This commit fixes that via CSS, still allowing a click on the elements
to be considered as a click on the parent, but preventing to focus our
snippet inputs (this fix is limited to our own snippets as stable fix).
Note: the 13.0/15.0 JS code which prevents the focus right now was not
found (if it even exists...) but it would not be ok to remove it in
stable anyway. More investigation and review will be done once this
reaches master.
task-2523496
closesodoo/odoo#84717
X-original-commit: ab9fbfb43365fcd39cc782f94b74911155e3f73e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, when a user searches with an upper case search
term of more than 3 characters, the search was considered as a fuzzy
search even if the result was an exact match.
Since the search is always lowered when there are more than 3
characters, the search is considered as fuzzy only when the search and
fuzzy term are case insensitively distinct.
closesodoo/odoo#84593
X-original-commit: 34362a7c07a2868103b24d16a83a97356ad1f60d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit ensures that changes are applied in the same order as the
events are triggered on the we-matrix. This was not the case because of
another bug we had to consider and which is not there anymore, this is
why this fix is done in 15.0 and not before.
This commit is the continuation of [1] which applied the same change for
we-input.
[1]: https://github.com/odoo/odoo/commit/db62a5fac123fc72e37e94709b1a0c80f32a8a29
task-2761187
closesodoo/odoo#84486
X-original-commit: 703e1ec69c2cbdbdbafeef9ac359db9f0f3b7021
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
The `loading="lazy"` attribute was set by default on all images but this
affected the `mass_mailing` module as well while that attribute doesn't
work in emails and can cause some issues in edition.
One known such issue this addresses is to be reproduced as follows:
1. Create a new mail
2. Drop the "cover" snippet
It has height 0 so it won't load until another snippet (with a non-zero
height) is dropped.
task-2761074
closesodoo/odoo#84415
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, on Chrome browser, the page url input and the
visiblity password input were autocompleted with the user's login and
password in the page properties options.
After this commit, they are no longer.
Regarding the url input page, it seems to be because Chrome considers
that the first text input located before a password input in the DOM is
a login input.
task-2502747
closesodoo/odoo#84393
X-original-commit: 7f45822919f8ef5f070a40a4dd41d22757a9da76
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the framework's navbar uses the hamburger_menu in community too,
the `navbar_mobile.scss` code initially shared between frontend and
backend is now needed for the frontend only.
This commit is part of v16 overall restyle (task-2704984).
task-2712151
Part-of: odoo/odoo#82434
Prior to this commit the topbar responsiveness was exclusive to
enterprise.
This commit moves to community the mobile logic for navbar, burgermenu,
user_menu and company_switcher.
The design has been adapted to v16, reviewing font size/colors and
icons. This commit is part of v16 overall restyle (task-2704984).
task-2712151
Part-of: odoo/odoo#82434
Purpose
=======
Several actions are done even if nothing has changed on the configuration.
Example:
Writing on a cron the same value makes a dummy write-lock on the table
...
Part-of: odoo/odoo#82999
Before this commit the target of options and nested options tour steps
could be hidden under an opened palette.
After this commit the tips of options and nested options tour steps
require that no palette is opened.
An 'allowPalette' parameter can be used to remove this condition, for
example if 'changeOption' is used to select an option within the
palette during a test tour.
A step is added to close the color palette - which, while opened,
prevents the next `changeOption` step from being activated.
task-2728994 (was task-2675252)
closesodoo/odoo#84093
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With commit [1] (and the parent commit here which reviews it), we
move the scrollbar to the modal instead of the website content if the
modal has scrollable content even in the case there is no backdrop. An
exemple would be the cookie bar, configured in popup mode, with a tall
content inside.
This was however not enough: the computation which determines if the
modal should be scrollable or not was not re-done after an image was
loaded. So if the popup was around the height of the window, it could be
smaller than the window's height before images loading and taller after
which would result in having the scrollbar on the body instead of the
scrollable popup.
[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6closesodoo/odoo#84139
X-original-commit: b83b465dd98345afeca3844a4796e4a83d15f72b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
Commit [1] was not coded defensively enough: after it, dialogs not using
a proper bootstrap structure triggered a traceback once they were opened
(this was discovered on odoo.com where such unconventional dialogs do
exist). Bad luck: there was actually a check to allow unconventional
dialogs but it was not done at the right location.
However, fixing this, it was found that more than this was not ok. There
is actually no need to consider the modal-content element at all. Just
using our `hasScrollableContent` method is enough and requires no extra
search in the DOM. This actually also properly computes if the modal
overflows or not while it was not the case before as it did not consider
the modal-dialog element's paddings.
Finally, the whole customized behavior of the modal scrollbar here was
only designed to affect our Odoo modals with the s_popup_no_backdrop
class (see original commit [2]). Indeed, only in that case we want to be
able to switch between body scrolling and modal scrolling while the
modal is opened. In custom cases and other Odoo cases, we want the
standard Boostrap behavior of only being able to interact with the modal
while opened. This commit cleans the code to restore that spirit
(hopefully this does not cause stability issues as [1] was introduced
only a week ago). Sorry for any inconvenience.
[1]: https://github.com/odoo/odoo/commit/8f1dd6d6087ad8252d6e7b22d13aad2c4a3f19c6
[2]: https://github.com/odoo/odoo/commit/e5a5f98819b3a70b3e2564fb91722cab415ceea9
X-original-commit: a2363337355ccf4363249657000cd85bfcb3ab4e
Part-of: odoo/odoo#84139
Since [1] when web was migrated to OWL, the cookies bar was considered
as a parent modal of any openend modal that got closed - thus preventing
scrolling the full page.
After this commit the cookies bar in the front end is not considered as
a remaining modal anymore, and therefore does not prevent scrolling on
the currently displayed website page.
[1]: https://github.com/odoo/odoo/commit/29731b404fe624b733d784cd4321113d6b0d27b7
task-2741894
closesodoo/odoo#84128
X-original-commit: c1aab97e6b4e8b916c7d79db5f278c746fd6b119
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Step to reproduce:
- Create a website form with its action set to 'create a task'
- Set a project for the task to be created in
- Submit the form while logged in as a portal user
Current Behaviour:
- Task is created but the data from fields is not take into account
This lead to the task not being linked to the project and ending as 'Private'
- Due to the changes of sudo in V15, authorized fields are not fetched
and thus cannot be set properly.
Behaviour after PR:
- The data is fetch via the SUPERUSER instead of sudo to ensure correct data
- The fields are correctly set and the task is created
in the corresponding project.
opw-2743065
closesodoo/odoo#84020
X-original-commit: de03ee2198e039e14d0852d2346cb8aaf3885b5b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Before this commit the phone fields inside forms did start in a blank
state.
After this commit the empty phone fields are pre-filled with "+" and the
country phone code.
The country is determined based on the IP address with the GeoIP
database. The phone code is obtained from `res.country` where it is
kept in cache.
task-2463563
closesodoo/odoo#78068
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
When selecting the text content of a link
the underline and italic commands were not working in Firefox.
We re-implement the Browser command to fix this.
task-2667950
X-original-commit: 52a5b2bb692ab6712d497492f4f2fbef3a9a7874
Part-of: odoo/odoo#83895
QWeb is the primary templating engine used by Odoo. It is an XML
templating engine and used mostly to generate XML, HTML fragments and
pages.
To create new XML template, please see :doc:`QWeb Templates documentation
<https://www.odoo.com/documentation/15.0/developer/reference/frontend/qweb.html>`
In **input** you have an XML template giving the corresponding input
etree. Each etree input nodes are used to generate a python function.
This fonction is called and will give the XML **output**.
The ``_compile`` method is responsible to generate the function from the
etree, that function is a python generator that yield one output line at a
time. This generator is consumed by ``_render``. The generated function is
orm cached.
In the graphic below you can see theresume of the call of the methods
performed in the IrQweb class.
Odoo
┗━► _render (returns MarkupSafe)
┗━► _compile (returns function) ◄━━━━━━━━━┓
┗━► _compile_node (returns code string array) ◄━━━━━━━┓ ┃
┃ (add technical directives: t-inner-content, t-tag) ┃ ┃
┣━► _directives_eval_order (defined directive order) ┃ ┃
┃ ┃ ┃
┣━► _compile_directives (recursive) ◄━━━━┓ ┃ ┃
┃ ┣━► _compile_directive ┃ ┃ ┃
┃ ┃ ┗━► t-if ━━► _compile_directive_if ━┫ ┃ ┃
┃ ┃ ┗━► t-foreach ━━► _compile_directive_foreach ━┫ ┃ ┃
┃ ┃ ┗━► t-* ━━► ... ━┛ ┃ ┃
┃ ┃ ┗━► t-inner-content ━━► _compile_directive_inner_content ◄━━━━┓ ━┛ ┃
┃ ┃ ┗━► t-tag ━━► _compile_directive_tag ━┫ ┃
┃ ┃ ┗━► t-call ━━► _compile_directive_call ━┫ ━━━┛
┃ ┃ ┗━► t-out ━━► _compile_directive_out ◄━┓ ━┫
┃ ┃ ┗━► t-field ━━► _compile_directive_field ━┛ ┃
┃ ┃ ┃
┗━━┻━► _compile_static_node ━┛
Part-of: odoo/odoo#81024
It was only used one time on a unused field.
We don't want to keep useless fields anymore,
the migration is done for that.
task-2735546
odoo/upgrade#3194closesodoo/odoo#82727
Signed-off-by: Raphael Collet <rco@odoo.com>
As an overridable _neutralize model method was added in a previous
commit, the method is now implemented for various models.
closesodoo/odoo#67825
Related: odoo/enterprise#19042
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When a user clicks on 'could be used in' in the page properties after
chaing the URL, a list is displayed in a popup. This popup was
not properly rendered:
- the content could not be scrolled through, it was thus truncated
- the popup appeared behind the technical modal that kicks in on small
screens
Now the popup is better positioned, a scrollbar is available to access
its content when it is too long and on small screens it is displayed on
top of the technical modal, making it visible on small screens.
task-2092269
closesodoo/odoo#83693
X-original-commit: e2f1f4967a2dd4d730895e924f0c7ca02e23a17b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Jitendra Prajapati <jpr@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
*: web_editor
Steps to reproduce:
- Activate the cookie dialog from the website settings
- Remove the backdrop from the cookie dialog
- Add some blocks to the cookie dialog in the website editor
until the dialog height is bigger than the page height.
Result:
The cookie dialog is not scrollable, so it's impossible to reach
the "I agree" button and close the dialog, leaving the user stuck
at the first page.
I check if the popup content is higher than the window. If it is, I
give priority to the popup scroll over the page one. I had to
overwrite the _showElement method to call _setScrollbar after
the content rendering, in this way I can get its correct height.
I also try to update the scrollbar each time a block in the cookie bar
has been changed and each time the window resize. This is optimize, so
if the overflow isn't changed from the last time I tried to update the
scrollbar no action will be taken. In this way you can always see the
whole popup without refreshing the page.
Also I have to set 'pointer-events' to none only if the popup is
smaller than the page itself (to interact with and scroll the
page behind), otherwise the popup won't be scrollable. I did
this by adding a class "s_popup_overflow_page" if the popup is
higher than the page and I adapted the pointer-events
property accordingly.
opw-2660786
closesodoo/odoo#83691
X-original-commit: 022a4486a99d855a3c6e2cef326bb3b0c5e66db9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the step about the slider to adjust the padding was
only consumed on click, which does not happen if the slider is used in a
drag'n'drop operation as expected.
After this commit this step is consumed on mousedown so that the
drag'n'drop operation is also taken into account.
task-2728994 (was task-2675252)
closesodoo/odoo#83692
X-original-commit: 42ce224fbe97f8d99ca5feec6d271412ce0647e1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
website{_*}: website, website_blog, website_sale, website_slides
Before this commit if several steps were referencing the same trigger
(e.g. "+New" button in website) only one was displayed, but all were
consumed when it was clicked.
Because of this the tour steps on "+New" were active even when its menu
was opened.
After this commit only the displayed step gets consumed if the step is
marked as 'consumeVisibleOnly: true'.
It cannot be done implictly on all steps because of [1].
This new marker is set on all steps referencing "+New".
The tour steps on "+New" now also require their menu to not be opened.
[1]: https://github.com/odoo/odoo/commit/5e888f8a6ccf9996b3231db6bf314d045619109e
task-2728994 (was task-2675252)
X-original-commit: 0fa40e37e596798665a098ee999f49749b6012a2
Part-of: odoo/odoo#83692
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
Issue
-----
Via the field prefetch mechanism, when we need a value of one field
(not in cache of course), the ORM will prefetch all fields
(which has the attribute to `prefetch=True`, the default value of this
attribute is `True`) for all record ids in `_prefetch_ids`.
Then, for each translate fields (where translate is not a callable)
the ORM need to make a `LEFT JOIN` on the `ir_translation` to fetch the
translated value. For big model, it leads to a simple `SELECT` with
several `LEFT JOIN` on ir_translation but each LEFT JOIN have a cost
in the planner time (a small cost in the execution time) of PostgreSQL.
By example, for `product.template` (stock/sale/purchase installed),
there are 6 LEFT JOIN to get all translated fields (5 of this
fields are rarely used).
Proposed solution
-----------------
Deactivate the prefetch by default for all translate fields expect if
this field is the `_rec_name` of the model (which is more likely to
be used).
In the example on the `product.template`:
Without prefetching the translated fields, there is only one LEFT JOIN
(the name, which is translated but is the `_rec_name` of the model).
With the 6 translated fields to fetch, the
query takes 5 ms to plan and 2 ms to execute VS with 1 translate field,
it 1 ms to plan and 1.5 ms to execute.
Side change note
----------------
- All translate of fields of `website.seo.metadata` should be prefetch
to avoid lot of website errors (it is because, website put in cache data
in sudo before reading it without sudo)
- `description` (`mail.message.subtype`), `subject` (`mail.template`),
`body_html` (`mail.template`) should be prefetch to avoid lot of extra
query from mail module.
- `vat_label` (`res.country`) should be prefetch to avoid a extra query
for each website page.
- Increase some queryCount (when it is legit, due to `subtitle` of
`blog_post` or `description` of `event.type.ticket`, etc)
task-2738029
closesodoo/odoo#82896
Signed-off-by: Raphael Collet <rco@odoo.com>
Since [1] when web's owl services were made available to the frontend,
the navigation mixin does conflict with the hotkey service.
E.g.: navigation mixin consumes the 'alt' keyup event, which prevents
the hotkey service from cleaning up the hotkey overlay.
After this commit the old mixin is neutralized and hotkeys in website's
pseudo-backend layer are handled by the general hotkey service.
Also since [2] the menu items are inside `<div>` instead of `<li>`,
adapted the scss to take this into account.
Also added a CSS rule to neutralize the outline on website's menu
dropdowns which are `<a>` instead of the already handled `<button>` in
web.
[1]: https://github.com/odoo/odoo/commit/db7b485d984e50fae5a52308634166460e5fc908
[2]: https://github.com/odoo/odoo/commit/84715436d87bb05b421bc9ccaacda67d07571690
task-2738578
closesodoo/odoo#83529
X-original-commit: 88438fa9b363530aa4e5dec5599c1568fb7ccea0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when we selected a variant of a product and then
clicked on a share button, the changed variants attributes in the shared
URL were not considered.
This commit also takes the opportunity to convert the whole file to new
Odoo modules and stopped using jQuery. The code actually had to be
refreshed following the merge of [1] so it was a good occasion to do it.
[1]: https://github.com/odoo/odoo/commit/8f7c6997e8ab381563a9fa8d06feef4e89fff4aa
task-2122733
closesodoo/odoo#83503
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Those steps were removed with [1] to avoid a indeterminist timeout, but by
doing so that part of the feature was not tested anymore.
Sadly, it was broken by [2] without being noticed for a long period of time.
The error was discovered by fixing multiple lang issues in the website
configurator in master.
Note that by creating a new lang instead of using an existing one will avoid
the timout error that lead to the removal of those steps with [1]. Indeed, as
no .po files will be found for that lang, it won't spend time on processing
those files.
[1]: https://github.com/odoo/odoo/commit/a15c7099a36a3a5b4dca9375b233cbe3fe2a280f
[2]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2aclosesodoo/odoo#83420
X-original-commit: 0b43f52116fd9a58fb0a123db576d822fd541043
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] the redirection supposed to happen after a lang install from the
frontend was broken.
Indeed, the 'url_return' was moved and used before it is actually set.
[1]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2a
Cheers to @jke-be which did the same fix in another branch in parallel.
X-original-commit: 74a594bb2e68662b22477fcce24d9620b2dd0b2a
Part-of: odoo/odoo#83420
In order to anticipate an anomaly in the network to prevent
a save, wait for an rpc to finish.
task-2742008
closesodoo/odoo#83103
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, a traceback occured when trying to remove a popup
snippet, only if content inside was clicked on before (base case but
that last part was not covered by our main test which drags and drops +
removes all snippets).
The problem is complex and annoying to solve in stable. The cause is the
combination of [1] and [2]. Indeed, with [2] we solved the snippet
activation flow to ensure the onFocus and onBlur methods are called when
needed... but that new correct implementation relies on the fact that
the number of snippet editor instances does not change for the whole
async operation of activating a snippet. That should naturally be the
case but is not because of [1]: when we remove a snippet we first
trigger a snippet activation then destroy the snippet (and its editor
instance)... but the snippet activation is not awaited at the moment.
Thus making the snippet editor instance be destroyed *during* the
snippet activation flow. Of course a better solution than this commit
must be found but this fixes the traceback with a very minimal change
for the 15.0 stable version while waiting for that miraculous solution.
[1]: https://github.com/odoo/odoo/commit/ae219ec06baf0280c76ae09b1453cc1481eece30
[2]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e
task-2735663
closesodoo/odoo#83378
X-original-commit: da7c1b5757a7780897c5736ddecc014a7fb50bdb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When Jabberwock was introduced in [1], forms were not selected anymore
by clicking on the form fields.
That behavior got fixed when Jabberwock was removed in [2] but this
commit introducing a test about it was not attached to a task - and did
not get merged at the time.
Before this commit there was no test to verify if the form became
selected when clicking on one of its input field or textarea.
After this commit there is a test that makes sure that the form is
selected when the user clicks on either an input field or a textarea.
Also added the renaming of a field label followed by a blur to ensure
it triggers all UI events.
[1] https://github.com/odoo/odoo/commit/347f4413d1b1a2b1a6a9ecd6d9c20cf7f3ec5ff3
[2] https://github.com/odoo/odoo/commit/e5572c317a7775a58675ed73efc89b5c9f6c0c39
task-2729643
closesodoo/odoo#83379
X-original-commit: fe4000cd521b5e1426b9093f7671fa457ef45eb8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit, since [1], when the cookies bar is opened, the pages'
animations would not work at all.
Animated images would not even be shown, remaining invisible.
This is because the s_popup when not using the layout 'popup' is still using
the modal/popup snippet structure but is not really a modal anymore.
As BS provide a built-in way to know if there is an open modal, which works
well with the cookies bar, use it instead.
[1]: https://github.com/odoo/design-themes/commit/e025296ccf5b8d8ea19bd354d9fbd52a12fc4d94
opw-2712755 (detected during migration)
closesodoo/odoo#83291
X-original-commit: 48bb9efee99d3bee2b4b60eec0f59ed2cb13a096
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Avoid to base64 encode, then decode to process assets and images for a ~25% speed improvement.
Change image processing tool to work on images, rather than base64 encoded strings.
Performance is ~25% faster on assets & images:
/web/assets/...frontend.min.css: 13ms to 7ms, base64 enc/dec: 2 -> 0
/web/image/XML_ID: 10ms to 8ms, base64 enc/dec: 3 -> 0
/web/image/res.users/2/avatar_128: 40ms to 20ms, base64 enc/dec: 6 -> 2
closesodoo/odoo#82851
Related: odoo/enterprise#23537
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Arthur Detroux (ard)