Steps to reproduce the bug:
- Create a storable product ”P1” with 2 BoM:
- BoM 1:
Type: manufacture
Component: C1
- BoM 2:
Type: manufacture
Component: C2
- Create a MO:
- Add the product “P1”
- The BoM 1 is automatically set and the component “C1” is added
- Save the MO
- Edit The MO:
- set the BoM 2 instead of BoM 1
Problem:
The component C2 is added, but the component “C1” linked to BoM 1 is
not deleted
To delete the existing lines, we check if the product has changed,
but we do not check if the BoM has changed:
https://github.com/odoo/odoo/blob/16.0/addons/mrp/models/mrp_production.py#L694
Solution:
clear “move_raws” if BoM change.
No need to check if the product has changed to clear component,because
if the product changes, the bom changes too
opw-3069283
closesodoo/odoo#105983
X-original-commit: 916449eb382715f341b05666cfec336e30c5db36
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
New class `fields.Json` is introduced in v16. The feature lacks some converting
methods for export/import. This commit fills the gap.
Example: field `line_ids/analytic_distribution` in `account.move` (Invoices)
opw-3056669
closesodoo/odoo#105973
X-original-commit: abbe2e002c0125ecb83a1ab3ee80acf3f43e3cb6
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
On creating views manually via UI, the web client sends following parameters
arch_base: "<data></data>"
arch_db: false
(in previous v15 release is was only `arch_base` [1])
This triggers `_check_xml` method, which raise error because of empty value for
`arch_db`.
Fix it by removing empty `arch_db` attribute in `create` method.
[1]: https://github.com/odoo/odoo/commit/e5735d0a467afcfc66a2b17275b27d4cf80789bf
opw-3038722
opw-3032865
closesodoo/odoo#105971
X-original-commit: 77f10460a6fd8d5de0853b3fb95c753e08060a5a
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Before this commit:
When we try to copy paste link into another link then url of the old link does
not change and only lable change.
After this commit:
Now when we try to copy paste link into another link then the url of the link
changes with the label.
Task-2768541
closesodoo/odoo#105966
X-original-commit: ea1e410f4174d235609181bdba692a98e7381396
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
traceback is raised in settings page and on clicking activate stripe button after deleting the paypal payment provider from the database
closesodoo/odoo#105692
X-original-commit: 4d34606baf314c78d608904720778ff2ac6bf5b4
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Bug
===
If we hover the property label, we should see the bottom border of the
property value (like for standard fields).
The bug still exist for the tags and many2many, because it's based on
the AutoComplete component, and the same bug exist for standard
many2many tags.
Task-3039733
closesodoo/odoo#105969
X-original-commit: 3ced33f434e84361448062b4795108df6186ffed
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
activate warnings from purchase settings and open any purchase order and click the create alternatives button from alternatives page. in the next wizard, Warning Messages field is visible always, upon checking the view, it seems the visibility condition given is wrong and thus it get visible always.
closesodoo/odoo#105977
X-original-commit: 40ec1fe8fbaf97faccda7dcd87e308277275bae4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- Install `sale_timesheet`
- In Sale, create a so with a 'service' product with invoicing policy
set on `Based on Timesheets` for customer A
- Confirm the SO
- Create a new project and check Billable and Timesheets
- Edit the Project and set customer to A
- Go in the `Invoicing` tab
- Enter the SO line you created before.
- Create employee mappings on the SO line you created before
- Click on the Save manually button
- Click on the Invoice button
- Chose Down payment (percentage)
- Set the percentage to 10%
- Click on `Create Invoice`
Issue:
A traceback is displayed when trying to create a downpayment on a project.
Cause:
Currently we filter the sol that are to invoice (`invoice_status` set to 'to_invoice')
prior to provide them to the wizard `sale.advance.payment.inv`.
As the result is an empty recordset, no sol ids are passed to the wizard.
Thus when trying to create a downpayment, no related sol is provided and
the error is thrown.
Fix:
As the `sale.advance.payment.inv` handles the fact that there are items to invoice
when choosing `regular invoice` there is no risk passing so line with an
`invoice_status` set to 'no' which will be used in this use case.
Closesodoo/odoo#104720closesodoo/odoo#105987
X-original-commit: 8ec5aed363c8e714c109b2eb0fc7da966b6d31a3
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
remove checkJS: It made the ts server check for error, bypassing some
eslint rules (such as globals).
add ts files in the include: ts files need to be included in the project
as there are some .d.ts files defining types.
closesodoo/odoo#105984
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Exporting a Binary field with a value of type dict from a record raises
an error
Steps to reproduce:
1. Install Accounting
2. Open Accounting and go to Vendors > Bills
3. Open any posted bill and register the payment
4. Go back to the list view and export the bill in payment
5. Add field Invoice Payments Widget to the exported fields and export
6. An error is thrown
Solution:
Make the field attribute `exportable` work (pass it in the field
description)
Make fields `invoice_outstanding_credits_debits_widget` and
`invoice_payments_widget` non-exportable as they contain computed
aggregated data for the client's benefit and it doesn't make sense to
export them
Problem:
xlsxwriter's `write` doesn't support type dict
opw-3054184
closesodoo/odoo#105972
X-original-commit: c925ecb2a22750524020f0d111888fd76eedb0cb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In rating/controllers/main.py, the method action_submit_rating accepts
only post request. This creates a problem when you're trying to use the
web editor on the template as well as when you just paste the url in
your browser, for those are get request. The current behavior is a crash
with 'method not allowed'. This commit's purpose is to change the method
so it also accept get request. The use case of editing the feedback
rating page is arguable but it schould not crash.
The behavior after this commit is that the web editor is enable for the
page, and relaoding the page does not crash anymore.
task-3047893
closesodoo/odoo#105985
X-original-commit: 1b61faad8281d8b8d2fa1bf526f2ae2c4c8ba07b
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Steps to reproduce:
- go to e-commerce app;
- select a product;
- try to return to the shop with the browser's back arrow.
(if the URL contains `\@\`, is not necessary to click on a "action", otherwise we must)
Issue:
It is not possible to go back.
Cause:
Modifying the hash modifies the history of the browser.
Solution:
Change hash without changing browser history.
`window.location.replace` documentation: https://developer.mozilla.org/en-US/docs/Web/API/Location/replace
opw-3061027
closesodoo/odoo#105976
X-original-commit: b3f501db38e14b28cc6b63ffe91562e556a97c16
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
closesodoo/odoo#105963
Checkjs: provide better erros in the IDEs
Disablesizelimit: experience to see if it works better with this
Target: import the default lib.d.ts for type checking
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
This commit adds and fixes type annotations to give more accurate
autocompletion for javascript.
closesodoo/odoo#105670
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
*: im_livechat, website_livechat, website_slides
In c989ff3, the odoo module system has been changed so that it now
errors out when modules are defined but have missing dependencies and
cannot run. Unfortunately, tours are defined in a single bundle,
`assets_tests`, and this bundle is used everywhere tours need to run,
but some of these tours depend on modules that only exist in the backend
and others on modules that only exist in the frontend. We don't want to
break up the `assets_tests` bundle as this creates a poor developer
experience, and so the solution that was chosen at the time is that when
the `assets_tests` bundle is defined, we ignore all module dependency
errors.
This causes a problem however, which is that if a module dependency is
missing in production code, the page will be broken by the module error
(which is expected) but if the `assets_tests` are present, which is the
case when running tours and tests, then it won't, meaning the tours will
happily pass despite the application being broken, which is
unacceptable.
This commit fixes this issue by replacing the assets_test bundle by a
new bundle (`__assets_tests_call__`) within which all module dependency
errors are ignored, which lets dependency errors that are hapenning in
other bundles (ie in production code) happen even during the tests.
Because of this, this commit also fixes the dependency errors that
already existed but were previously silent:
- for im_livechat and website_livechat, the code was refactored to use
the standard mechanism that we use elsewhere to add data directly in the
page: we store the data in __session_info__, and the module that exposes
that data is always present, instead of having a module that's defined
conditionally, which causes issues when non-conditional modules depend
on it.
- in web, the `report_assets_common` bundle was used alongside
`assets_common` but without `assets_frontend` or `assets_backend`.
Reports do not need any js and it appears that it already had what it
needed as far as css is concerned except for one fontawesome override.
Code was changed so that the js from the bundle is not included and it
reports no longer use `assets_common`, the js part of the bundle is no
longer used.
- in website_slides, the `slide_embed_assets` bundle is used alongside
`assets_common` without using `assets_frontend` or `assets_backend`
which is required for `assets_common` to function, the approach here was
to simply take the files from `assets_common` and remove the files that
were causing issues. This bundle should be trimmed at some point, as it
contains way too many things that it does not need.
The file colors.js was also moved to core, as it isn't graph specific
and was causing dependency issues with a field that was importing it.
Fields shouldn't depend on files in specific views' directory.
closesodoo/odoo#104794
Related: odoo/enterprise#33909
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When the price and the event are the same, nothing allows
ordering tickets in event_sale. Therefore, add a sequence
number and handle widget to the tickets (in data as well).
Also do it for ticket templates. Also, order the tickets
(on events and templates) by name before id.
Since event type tickets are not linked to any event, the
order does not include the event_id. However, event event
tickets are, and if they appear in the same list / reporting
someday, it makes sense to order them by event_id first.
In event_sale, we make sure the price is also in the order.
As the price is in the copied fields on the event when
using an event template, we add the price on the event
type tickets ordering to align with the event event tickets.
Add default value to sequence and sequence number to data
for event.type model. They were sequenced but demo data had
none, hence not really ordered.
We also add the id in the event.event _order value, otherwise
when ordering on the event (for instance ordering on event_id
for event.event.tickets), the order is random for events
having the same date_begin. We prevent this from happening.
Also make description optional hide on event types.
Task-2997391
closesodoo/odoo#101384
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
It is not possible to consume a component tracked by serial that comes
back from a scrap location
To reproduce the issue:
1. In Settings, enable "Multi Routes"
2. Create two storable products P_compo, P_finished
- P_compo is tracked by serial number
3. Update the on-hand qty of P_compo:
- 1 x P_compo with serial SN
4. Process a manufacturing order MO:
- Product: P_finished
- Compo: 1 x P_compo with SN
5. Unbuild P_finished
- It brings SN back to stock
5. Scrap one P_compo with SN
6. Unscrap it (thanks to an internal transfer)
7. Repeat step 4
Error: a user error is raised: "The serial number SN used for component
P_compo has already been consumed"
When checking the SN uniqueness of a component, we don't consider the
case where a product came back from a srap location
OPW-3055252
closesodoo/odoo#105926
X-original-commit: 476dbb6f2138294200ba7bfef96553e5d89b1a0e
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Remove the Dynamic Placeholder from the legacy Odoo field.
Introduce in 308f639e295fce07e4f34d6c76b35aab259e21ad
And migrate to be OWL compatible in #101768
Therefore the old code targeting legacy odoo field is unnecessary
and need to be cleaned.
task-3071417
closesodoo/odoo#105920
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, once a user was disconnected from internet (eg.
network failure, laptop screen closed), the code disconnected the user
from the peer to peer network and upon reconnection to the internet
network, the code did not try to reconnect to the peer to peer network.
This created a network partion in the peer to peer network each time
a user disconnected and reconnected to the internet network.
When there is a partition in the peer to peer network, the last subnet
to write to the record erased the changes of another subnet without
notification.
This commit prevent the code to disconnect from the peer to peer network
when there is any disconnection signal triggered.
closesodoo/odoo#105900
X-original-commit: 8bce8cd53d1c6da89fce8c2f8b64615168d45a0d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
- Use of jsconfig instead of tsconfig
- jsconfig deployed with tooling, no need for CLI
- ecmascript bumped to version es2022 (static properties)
- prettierrc merged inside the eslintrc
- add a few globals
- cleanup package.json scripts
- add script to lint/format only the diff (opposed to staged files)
- bump up node packages versions
- use eslint as cli instead of prettier-eslint, as eslint does provide
parsable output for runbot.
- add the typescrit types of libs as dependencies + main.d.ts to
improve autompletion.
This upgrade makes it easier to deploy and use the js tooling, as it is
expected more and more people will use it if a lint check is added to
the runbot.
About the runbot:
The commit gets the code ready to enable the lint on the runbot.
It will lint the code with the same rules and same ignore file.
The only difference is the runbot will check only the diff and not the
entire commited file.
The goal will be to progressively (and aggressively) whitelist modules
to converge to a nice formatted codebase.
closesodoo/odoo#105165
Related: odoo/enterprise#34048
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Previous commit 0501bbd62e made it so
the `product_uom_id` for the `line_ids` of a purchase.requsition (i.e. a
blanket order) were no longer being saved when the UoM setting is not
active. This would cause an error to occur when the "New Quotation"
button is pushed because the missing uom is expected by purchase
_onchange_requisition_id.
Steps to reproduce:
- Have UoM setting NOT active
- Create a blanket order for any product/vendor
- Confirm the blanket order
- Click on "New Quotation"
Expected Behavior:
New RFQ created
Actual Behavior:
Stacktrace
We also properly restrict the product_uom_id in the form view of the
line_ids to when the uom setting is active.
closesodoo/odoo#104900
X-original-commit: e90200a7b927ecccb8d4d6f31e3ddecba24d0b6d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Previous fix
https://github.com/odoo/odoo/commit/72dff43a4da277b002966f5fd4045b7f9a3855ad
re-exposed uoms in the view even if the setting is not active, but we
prefer to avoid this if possible. In order to do this we ensure that the
uom is set even if it is not visible in the view. Most of these are
already handled by compute methods, but except for `repair.fee` so we
only add in a guarantee for that model.
Note that the write case is included in cases when:
- the uoms were previously activated and set => deactivated again
- demo data has different uoms set and uoms setting is not active
X-original-commit: 7e64ebb3d8d3f3d3749304a325eb073777b129dc
Part-of: odoo/odoo#104900
scrap_qty was recently turned into a compute but was missing
readonly=False so scraps created from scratch were stuck on a scrap_qty
of 1.
X-original-commit: e2a2a6e2526446b6f8d041135a4e5653fa96bb47
Part-of: odoo/odoo#104900
Steps to reproduce:
- Switch to `?debug=assets`
- Change the user language to Arabic and back to English
-> The page is still displayed in rtl mode
Cause of the issue:
The css is retrieved like this
```py
>>> self.env['ir.attachment'].sudo().search([('url', '=like', '/web/assets/%/web.assets_common.css')])
ir.attachment(212, 189)
>>> self.env['ir.attachment'].sudo().search([('url', '=like', '/web/assets/%/web.assets_common.css')]).mapped('url')
['/web/assets/212-5d47380/rtl/web.assets_common.css', '/web/assets/189-5d47380/web.assets_common.css']
```
Only the second one should be matched.
Solution:
Check for the absence of an extra parameter in the url
opw-2892012
closesodoo/odoo#105127
X-original-commit: 539427fa2a099b29adf099c2b48d4f1d2fd4ebd2
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Purpose of the commit is to do the generic improvements for project app.
So in this commit did the following changes:
- add the 'creation date', 'last stage update', 'SOL', 'my deadline' fields in
project task list view.
- add the 'my deadline', 'next activity' fields in project list view.
- crop the label of the stage after x characters in task portal form view.
- remove the 'collaborators' stat button from project update right-side panel.
- renamed sold->sales, services->sales order items, effective->delivered,
remove the totals, include non-service SOLs, increase the size of the SOL
column
task-2928100
closesodoo/odoo#97870
Related: odoo/enterprise#30268
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The tour is failing undeterministically, seemingly because a step is
done too soon after the previous one without giving the time for the
website to reload everything as expected.
By reordering the steps a bit, this issue can be avoided and fix the
test issue.
closesodoo/odoo#105891
X-original-commit: ff91efcda8cb80da4c376e74714f4c0dedad63c1
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, some templates for the products snippet in website
had some layout issues. This commit fixes them.
task-3060991
closesodoo/odoo#105890
X-original-commit: e829b345f0f5e5346be416b8354c29fa9acb74a7
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The style was using hardcoded css values for its button. unfortunately,
since it was not based on global varialbes, the colors are now outdated.
Task 3047620
closesodoo/odoo#105889
X-original-commit: 777a831cd7e3096de9421c224e192ef7c718c77f
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
currently odoo is allowing to create a scrap order record with 0 quantty, which doesn't make sense and also if it is allowed, user wont be able to edit change the quantity later. currently zero quantity is not blocked by _check_positive_qty_done on stock.move.line. And it doesn't make sense to scrap 0, thus preventing the same by raising a validation
closesodoo/odoo#105752
X-original-commit: eb899fe8dda12d0f0e4ae515bb01e65981f4fbcd
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
When returning a dropshipped and subcontracted product to the supplier
location, the received quantity of the PO line will be incorrect
To reproduce the issue:
1. Create two storable products P_compo, P_Finished
2. Create a BoM:
- Product: P_finished
- Type: Subcontracting
- Subcontractors: a subcontractor S
- Components: 1 x P_compo
3. Create and confirm a PO:
- Vendor: S
- Deliver To: Dropship
- Drop Ship Address: a partner P
- Products: 1 x P_finished
4. Validate the receipt
5. Create a return with 1 x P_finished:
- Update SO/PO quantities: True
- Return Location: Partner Locations/Vendors
6. Validate the return
7. Go back to the PO
Error: The qty received is 2, it should be 0
There is currently no code to handle the return of a dropshipped product
OPW-3030895
closesodoo/odoo#105863
X-original-commit: 0a03678889d46dfc39922c0df965c06457f28d79
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When returning a dropshipped and subcontracted product to an internal
location, the received quantity of the PO line will be incorrect
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two storable products P_compo, P_Finished
3. Create a BoM:
- Product: P_finished
- Type: Subcontracting
- Subcontractors: a subcontractor S
- Components: 1 x P_compo
4. In Locations, edit WH/Stock:
- Return location: True
5. Create and confirm a PO:
- Vendor: S
- Deliver To: Dropship
- Drop Ship Address: a partner P
- Products: 1 x P_finished
6. Validate the receipt
7. Create a return with 1 x P_finished:
- Update SO/PO quantities: True
- Return Location: WH/Stock
8. Validate the return
9. Go back to the PO
Error: The qty received is 2, it should be 1 (it should not be 0 since
the product has been returned to an internal location)
In `/purchase_stock._compute_qty_received`, there is already a code to
anticipate such a situation (i.e., a user who returns a dropshipped
product to his stock location):
https://github.com/odoo/odoo/blob/bf3c398f0644f690c64815b2b6e298aed7bedd70/addons/purchase_stock/models/purchase.py#L300-L305
However, the methods `_is_dropshipped` and `_is_dropshipped_returned` do
not include the feature subcontracting + dropshipping. This is the
reason why, in `_compute_qty_received`, the above condition is not
respected and why we add the return stock move to the received qty.
OPW-3030895
X-original-commit: 5dffa88e788355efe7b9b9bccff75fdbd52713e9
Part-of: odoo/odoo#105863
**Issue:**
- Open crm.
- Open a lead.
- Input a number in the phone field.
- Click everywhere for the input to be recognized.
- Click the sms button that appears when hovering over the phone
field.
- BUG1: The shown dialog doesn't have the inputted phone number.
- BUG2: When closing the dialog, any changes made in the form
before clicking the sms button are lost.
**Solution:**
Make sure the changes are saved before calling the action that
shows the wizard.
After this fix:
- The phone number input in the form is now used in the
wizard.
- When closing the wizard, the "unsaved" changes are kept.
closesodoo/odoo#105862
Task-id: 3056454
X-original-commit: a1bc67d811cab58e6ab336c636a1b1d83fc64446
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Splitting the method `_get_order_lines` will allow making it
inheritable, this way more order line fields can be added and expand
them easily and avoid having to overwrite it.
closesodoo/odoo#105858
X-original-commit: 457624160f03c28e9b90d14fb4c56fe2f7fabeed
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit: when `Limited Products Loading` is enabled in
PoS settings, and `Load all remaining products in the background` is
disabled, the search bar only uses `name` to look for products to fetch
from database. This causes problem when for example the user is using
barcodes to identify products.
To fix this, the search domain should be expanded to include all of the
fields which are normally used when searching for products.
opw-3055960
closesodoo/odoo#105829
X-original-commit: ac6a7c7c34c0e4d4b4d7c7dcfb2d939a70a5bf09
Signed-off-by: Masereel Pierre <pim@odoo.com>
### Steps to reproduce
* install the *VAT Number Validation `(base_vat)`* and Contacts module.
* Create a new contact from San Marino and set their Tax Id to SM05426
* Save the contact
You should see that the leading zeros have been removed on the Tax Id
(here, SM05426 became SM5426)
opw-3007722
closesodoo/odoo#105830
X-original-commit: 24207914e9dae4b5f7e100245d4efe964f639415
Signed-off-by: Josse Colpaert <jco@odoo.com>
- When importing account move lines, accounts are created with `name_create`. If the `account_id` column only contains the code, like "12345", the `split_code_name`
would only return a value for the name and leave the code empty. This is because the first group in the regex expects a space in the end, so "12345 " would work correctly.
The code is a required field, hence the import fails.
Removing \s from the first group fixes the issue and the code is saved correctly.
- There should be a UserError raised in `name_create` instead of the ValueError. The message should be clearer as well.
- It should not be possible to quick create an account from product category views.
task-3056847
closesodoo/odoo#105815
X-original-commit: 24758778172595388c19fd0a83d93d35f2260261
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
After [1], when an option that requires the page to be reloaded is
changed, the editor will try its best to reselect the same snippet.
However, in some scenarios, the snippets' options could not be activated
leaving the menu on the snippet drag and drop menu.
Steps to reproduce (race condition so might not always occur):
- Activate the cookie bar in the website settings
- In edit mode change the header menu style
- The Snippets Drag and Drop menu is displayed
- Instead the Header Options should be displayed
The reason is that an event is not 'awaited'. Indeed, when starting the
editor, a 'widgets_start_request' is fired and not awaited.
It creates a race condition that is visible in this case but could have
caused other issue.
For the in-depth technical reason this happens:
- The wysiwyg is started, the popup is on screen, its options are loaded
by default (since it's needed to populate the invisibleDOM panel)
- activateSnippet is triggered with the Snippet it should focus on after
reloading
- widgets_start_request is triggered which destroys the popup and
triggers an 'onHide' event within the option
- The triggers a 'snippet_option_visibility_update' which triggers an
activateSnippet(false) which hides everything that was enabled prior to
this point.
This commit fixes the issue by re-ordering the events and making sure
that the 'widgets_start_request' is awaited
[1]: https://github.com/odoo/odoo/commit/a3e34512bf229d5d55f9e9d9eb0a9f7211a5a826
task-2687506
closesodoo/odoo#105816
X-original-commit: 5a2d0a2a88b9ecc2c330a948dfd9140b9edc3af3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Touati Djamel (otd)