Will be reintroduced properly afterward. Currently, even if the
field is defined using ondelete='set null', the M2M relation
doesn't handle the fact that the target table is a real model
and not a simple relational table.
closesodoo/odoo#116880
X-original-commit: f58d2ad669710a353263e418bbf69f5f49145cac
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Changeset #115803 tried to reduce issues regarding the statusbar
chevrons wrapping in an ugly fashion when the number of buttons increase
in the header.
Unfortunately, this has side-effect in other cases which actually
degrade the experience.
This commit removes most of that changeset, with the exception of
keeping the -flex-wrap on header buttons - it's better to break the list
of buttons over 2 lines than breaking the buttons themselves into 2
lines.
Follow-up of Task-3215622
closesodoo/odoo#116857
X-original-commit: bc5aebfca3c4b2f67e235b9e0bbdba6fd58140dd
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Some nightly builds failed due to the hardcoded id present in the `test_order_refund_with_owner`.
closesodoo/odoo#116856
X-original-commit: 9c924888635045a34b1d8521c253f9dda83946bf
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Invalid taxes could lead to invalid results from the
`_prepare_edi_tax_details` fonction. For instance: a tax without tax
repartition lines will be disregarded, which in turns leads to an
invalid xml being generated.
opw-3175701
closesodoo/odoo#116855
X-original-commit: 22b18a17348be6bd3982cbffd31da383442a6433
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
list view
In some occasions, we want to be able to download all edi documents so
the user can upload them on a governemental platform. From the list view
of all the invoice, it is now possible to selected as many invoice as we
want, and with a newly added action download them into a zip.
task-3122424
closesodoo/odoo#116854
X-original-commit: 5171f607e1fddde06b769ebb78d82548ad4dc84d
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this commit, tour may end before emojis are loaded.
This results in following crash:
```
Trying to set result to failed (AssetsLoadingError: The loading of /web/assets/3949-d14fea7/mail.assets_emoji.min.js failed
at HTMLScriptElement.<anonymous> (http://127.0.0.1:8069/web/assets/3709-a5ab371/mail.assets_public.min.js:7008:270)) but found the future settled (<Future at 0x7fee7552a410 state=finished returned bool>)
```
This commit hides the crash in case the loading of emoji fail,
and instead show emoji picker without any emoji.
Fix runbot issue 19877
closesodoo/odoo#116845
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
Current behavior:
When no account is set on a product category, you cannot close a POS
session. This happens because we are not using the default account set
on the POS journal in this case.
Steps to reproduce:
- Create product A, and product category B that has no account set on it
- Open a POS session, add product A. Validate the order
- Close the POS session, you will get an error message.
opw-3178181
closesodoo/odoo#116838
X-original-commit: 18be148083ebce27154452bef7aa2620e68f18f0
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Current behavior:
If you apply a discount on a product, the PoS ui will show the old price
without taxes.
Steps to reproduce:
- Install PoS and l10n_fr_pos_cert
- Create a product with a price of 100€ and a tax of 20%
- Create a pricelist with another price for the product (e.g. 80€)
- Open a PoS session
- Add the product to the order
- Apply the pricelist
- It show the old price as 100€ instead of 120€ (100€ + 20% tax)
opw-3211796
closesodoo/odoo#116836
X-original-commit: e5549d7a9962d92b1abc79d416c3c47303e06134
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
In the current tour steps, there's ambiguity in the failing step and its
preceding steps. Basically, the failing step asks to click a selection item
that contains "Monitor Stand" and the previous step also do the same: clicking a
selection item with "Free Product - [Desk Pad, Monitor Stand]". And if you
notice, both step has text "Monitor Stand". Given the nature of the tour runner,
it will try as fast as it could to do the steps, so it will click "Free Product
- [Desk Pad, Monitor Stand]" then it will immediately be followed by clicking
"Monitor Stand" which is the same element clicked by the previous step. In
essence, the two steps only resulted in one action.
As a solution, we make sure to distinguish the first step of selecting
the reward program, followed by selecting the reward product.
We use the fact that a second span under `.selection-item` will be rendered
when displaying the program selection, therefore, we introduce an
extra_trigger in first step (provided by `claimReward` helper function).
Then, we add more steps that checks the selection items on the expected
2nd selection popup.
closesodoo/odoo#116819
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Register a ph contact with vat 123-456-789-012
Validation Error will raise
Currently we use check the PH vat against regexp \d{3}-\d{3}-\d{3}-\d{5}
This seems to be not correct according to the official documentation
https://serp-p.pids.gov.ph/publication/public/view?slug=taxpayer-identification-number-tin-its-development-and-importance-in-tax-administration
"""
12 digit number (E.g. 123 456 789 002), of which the first digit
identifies type of taxpayer (0 for corporations, 1-9 for individuals
and other businesses), second to eighth digits are sequential numbers
between 0 and 9, ninth digit is a check number, last three digits are
000 for individuals and head office of businesses and 001-999 for
branches of businesses, if any
"""
The TIN should be a 9 digit code + 3 for the branch code
opw-3141793
closesodoo/odoo#116491
X-original-commit: f0e9a3ce7fec9bb86b8703a6d49c0bc70c80d5c3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
`PartnerRoot` is a confusing name for what is in fact what everyone call `odoobot`
closesodoo/odoo#116823
Signed-off-by: Debondt Didier (did) <did@odoo.com>
This commit mocks the "preference_save" action on the res.users model during
the test that checks that the user can modify its own preferences.
This allows to ease the testing as a context reload in the middle of test steps
was not handled correctly by the test runner.
Task-3246086
closesodoo/odoo#116800
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since commit 2ecfed335d, m2x_tags_avatar
are based on dynamic.readonly to know if they are readonly or not. This
is a mistake, the only information that depends on dynamic.readonly is
the presence or absence of the popover.
In this commit, we'll set the initial value to readonly and add the
isEditable props that will tell iif you can delete or add records with
the popover.
closesodoo/odoo#116782
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Exporting Kenyan invoices in a format readable by the Kenyan fiscal
device creates some complex output. The data is significantly modified
in order to represent an odoo invoice in the native format of the
communication with the device (for instance global discount lines must
be distrubuted accross the existing positive lines of the invoice, since
the device is incapable of representing negative lines).
This commit adds a series of tests designed to ensure the format of the
export is correct, and that the values of these invoices are
represented in a way that best reflects the data on the invoice, whist
being readable by the device.
closesodoo/odoo#116615
X-original-commit: dec8e7e3fefc8e00b916f4be9227a789c2a40b65
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
When both the price and quantity are negative, this creates a few
problems that the serialisation code does not handle appropriately.
Firstly, the device does not accept negative values for price or
quantity. Price and quantity should therefore always be positive. In the
case where both the price and the quantity are negative, the line is
positive, and we must therefore processes it in the same manner as
positive lines.
A line with both negative and price and quantity should qualify as a
line that, when negative lines are present, can be subtracted from in
order to represent a discount.
This commit adapts the serialisation function in order to correctly
represent a negative price and quantity line as positive (by using the
absolute values of each). It also adapts the discount line code in order
to recognize these lines as candidate lines for discount.
X-original-commit: db774ac144e760e23d4a032971c64e2010486325
Part-of: odoo/odoo#116615
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible.
This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this commit, we change the taxes name so that it's more clear and consistent for the users
closesodoo/odoo#116384
Task-id: 3052677
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible.
This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this commit, we change the taxes name so that it's more clear and consistent for the users
Task-id: 3052677
Part-of: odoo/odoo#116384
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible.
This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this commit, we change the taxes name so that it's more clear and consistent for the users
Task-id: 3052677
Part-of: odoo/odoo#116384
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible.
This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this commit, we change the taxes name so that it's more clear and consistent for the users
Task-id: 3052677
Part-of: odoo/odoo#116384
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible.
This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this commit, we change the taxes name so that it's more clear and consistent for the users
Task-id: 3052677
Part-of: odoo/odoo#116384
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible.
This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this commit, we change the taxes name so that it's more clear and consistent for the users
Task-id: 3052677
Part-of: odoo/odoo#116384
This commit makes the pricelist item selection
in the get_price function inheritable
Description of the issue/feature this PR addresses:
Help inherit the pricelist item selection in the pos get_price function
Current behavior before PR:
pricelist item in the pos get_price selection is not easily inheritable
Desired behavior after PR is merged:
pricelist item in the pos get_price selection is easily inheritable
closesodoo/odoo#116614
X-original-commit: d2d690a80e5265e55b52e15cc52d01a96174e6fa
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit, it was not possible to scroll
inside long activity menu.
Dropdown already manage scroll, so the content should not put
overflow management, to the risk of introducing scrollbar twice
or making content non-scrollable.
Task-3249174
closesodoo/odoo#116815
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Steps to reproduce:
- Install l10n_mx modules
- Switch to MX company
- Create invoice and confirm it
- Send it to PAC in test environment (Process Now button)
- Click Send & Print button
Issue:
- XML Preview does not display, only shows the file name in the top right corner of the chatter.
Cause:
In l10n_mx_edi, when posting the invoice, the only attachment available is the xml sent to the government in `_message_set_main_attachment_id`.
Therefore the xml is set as the main attachment.
When clicking on "Send and Print", the pdf is generated but the main attachment is still the xml
Solution:
Redefine the main attachment everytime the the main attachment is an xml
Note:
- octet-stream have also been filtered out
opw-3085934
closesodoo/odoo#116784
X-original-commit: 48e6e81a47f5371f5985d135e56f39f445eb2854
Related: odoo/enterprise#38861
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
In PoS restaurant, if you refund an order and go back to the floor plan,
before validating the refund, the link between the original order and
the refund is lost.
Steps to reproduce:
- Open PoS restaurant
- Create an order
- Refund the order but do not validate it
- Go back to the floor plan, and go back on the order
- Validate the refund
- Close the session
- Go on the orders, you will see that the refund has no link to the
original order
opw-3202383
closesodoo/odoo#116748
X-original-commit: 3ea9a8a0b3a9085b35314633e56bb7e508df7008
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Current behavior:
When you sell a gift card in the PoS with a discount, the value of the
gift card is not correct. For example, if you sell a gift card of 100€
with a 50% discount the customer should pay 50€ and the gift card should
be worth 100€. But the customer pays 50€ and the gift card is worth 50€.
Steps to reproduce:
- Create a gift card program
- Open a PoS session
- Sell a gift card of 100€ with a 50% discount
- Pay the order
- The value of the giftcard should be 100€ but it is 50€
opw-3221553
closesodoo/odoo#116746
X-original-commit: 1631ab332a6c9c7ca5e1f2451a51fb663534cb8e
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
This commit adds a button to the `CallActionList` to signal to the
other participants of the call that one is raising a hand.
This will add a hand icon to the `CallParticipantCard` of the people
with a raised hand and send a notification that is displayed in the
`Call` view (only when in discuss, not in chat windows).
task-3229507
closesodoo/odoo#116658
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit resets the width of boolean fields inside right-pane settings
which was set to 50% in most cases for general display purpose.
closesodoo/odoo#116653
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
This commit simply removes the res.company favicon field and every
related code because the feature is obsolete
closesodoo/odoo#116367
Related: odoo/upgrade#4469
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit moves the graph data the user got at the end
of the survey to the review answers section.
Task-2991360
closesodoo/odoo#114130
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Move the test because the field `optional_product_ids` is defined
in the module "product_configurator".
Therefore, if the test is in "website_sale"
and is run without the "product_configurator" module there is an error.
We move the test to the "bridge" module
between "website_sale" and "product_configurator".
opw-3140859
closesodoo/odoo#116742
X-original-commit: 4f4d6c1422b5b258fc5176a0f341b47c0fc1e963
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
A visitor could visit a web page having a lang in its context that is
not installed in the databased he is connected to. The problem is that
visitors are not logged-in thus it is not possible to determine their
lang via their `res.users` preferences. The lang used instead is the
lang set in the `Accept-Language` header of the incoming request, that
header is set by various browsers in accordance to the user system
preferences or browser settings.
The browser lang (`Request.best`) is only parsed according to the
`babel` database, it is a lang syntactically speaking but not necessary
a lang that is installed in the database.
At the moment the browser lang is set in the context (inside of
`Request._get_dbname_and_session`), it is not possible to verify it is
installed in the database as no connection to any database as been
established yet. Instead the lang is validated inside of
`ir.http._pre_dispatch` which is the method responsible to prepare/fix
various stuff on the request/session/context.
In regard to 93b684d3c7, we prefer to fallback on English, hence the
modification in `get_lang`.
closesodoo/odoo#116683
Reference-to: 93b684d3c7 ([FIX] base: lang should fallback on english instead of arab)
X-original-commit: 743e97667e44cdaab6db334d807cf3d409cea621
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Rewords and fix the typos in the mailing.mailing model notes.
Task-3240405
closesodoo/odoo#116756
X-original-commit: 156b901292b01e6bb6cd430caade3ae95742782b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the fiduciary mode is activated, we want to bypass the check of constrains on the date sequence.
Before this commit, fiduciary mode enabled to modify the name of a customer invoice but if the name resembled somewhat a normal sequence number, there still might be cases where Odoo will try to match a "Journal ID" and a "Year" in a manual sequence number that is provided.
For example, writing 23-31-070 as the new invoice name, Odoo mistakingly interpreted the following:
- 23 is the name of the journal
- 31 is the year
- 070 is the sequence number
closesodoo/odoo#116740
X-original-commit: f1b695d9ec8a551c93197b3aaad1b5504af8fdd6
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: hupo-odoo <hupo@odoo.com>
In previous commit, we just copy/move the files.
In this commit, delete the part of each file
that is not related to its model, and some style.
task-3244966
closesodoo/odoo#116256
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In this commit, we just copy/move the files.
In next commit, delete the part of each file
that is not related to its model.
task-3244966
Part-of: odoo/odoo#116256
Commit [1] fixed the editor not being able to start when clicking on a
link that triggers a download. This was caused by the
websiteRootInstance being undefined when a page is about to be
unloaded (beforeunload). Unfortunately, this event can be canceled.
This means that the websiteRootInstance had to be undefined when we are
certain that a navigation is going to happen within the iframe. However,
the condition introduced by [1] does not take into account multiple
factors, which lead to the websiteRootInstance being undefined during
edition.
This commit fixes that and introduces a test to make sure this behaviour
is not easily broken again.
Steps to reproduce:
- In edit mode, on the Home page, go in the footer and click on any link
(except "Contact Us") under "Useful Links" or on the house icon in the
Social Media snippet.
- Change the footer height with the Height option.
=> The option is applied correctly (because the link stays on the same
page).
- Click on "Contact Us" or another Social Media icon.
- Try to change the footer height again.
=> The preview works but when we leave it, we see that the option was
not applied.
- Drop a snippet and click on it.
=> Infinite loading.
[1]: https://github.com/odoo/odoo/commit/e47a9900e4a7842774d33a332b325e1f08c3ca45
opw-3196324
task-3212501
closesodoo/odoo#114366
X-original-commit: 15a17656b42442b40f4476efe8c985a9ba28ff93
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Co-authored-by: Soukéina Bojabza <sobo@odoo.com>
Before this commit, the ComponentAdapter would detach its dom before
calling the on_detach callback. This is not correct (even though it is
usually ok): we want the "unmount" code to be executed while the widget
is in the DOM, not after it has been detached. It is even more
problematic if the sub widget contains itself some owl components, since
this behaviour break Owl assumption that owl components are in the DOM
before being unmounted (so, for example, since owl 2.0.9, references
are null even if component is not in the DOM, even if the component is
still mounted).
The fix is quite simple: simply do the DOM removal after calling the
callback.
closesodoo/odoo#116752
X-original-commit: c56795d8715c9f1c85dec88d1c39e8becb4b1e62
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
Currently the profitability test assumes the project is in the USD currency.
However, if the companies default currency is something else, the asserts will fail.
Here we guarantee that the 0.00 amount will always be in the same currency as the
project to allow the tests to pass.
opw-3210514
closesodoo/odoo#116773
X-original-commit: 6ad9d1af8d8add56f2b7752632af55c3e66bd148
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
loyalty_delivery: the demo data updates the `tracking` field, which is a
stock-dependent field. As this module does not rely on stock anymore,
and since these lines only assign to the default value, the file is
removed.
website_sale_picking: the module dependency to stock has been forgotten
in the split of delivery from stock, and is added back to the manifest.
closesodoo/odoo#116747
X-original-commit: 9da0e43651070de2bf617035329ddc6a250398ff
Related: odoo/enterprise#38847
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Issue:
A user being in the group `group_hr_timesheet_approver`
will have a traceback if he goes to "Timesheets / Reporting / Timesheet/Attendance".
Cause:
The `project_id` field does not exist on the `hr.timesheet.attendance.report` model.
Solution:
It is acceptable for the `group_hr_timesheet_approver` group to have the same
access rights than the `group_timesheet_manager` group.
opw-3221963
closesodoo/odoo#116741
X-original-commit: 9d0bc00eff0f9290b401f648f865fd591ad5fca0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This error was caught by sentry.
Steps to produce:-
* Install eCommerce,loyalty module.
* Delete 'Top-up eWallet' product from eCommerce/product.
* Then create a new Gift card & eWallets from eCommerce/Gift card & eWallets.
* At this moment A trace back raise.
Because user deleted the product 'Top-up eWallet'.
Sentry:-3985154178
closesodoo/odoo#116738
X-original-commit: e5ae091a530de45741749e01d25f436af093a8a2
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
`Account.move.line` contains a stored related field called `parent_state` which relates to `move_id.state`. This allows for performance improvements by accessing that instead of `move_id.state`.
However, across odoo and enterprise `account.move.line` is domained against `move_id.state`.
This can produce an unnecessary left join on SQL queries for reports or other queries when instead it could use the stored field directly.
To accomplish this fix, we adjust domains to refer to 'parent_state' instead of `move_id.state`
While this PR will adjust multiple modules to fix this domain, it should improve SQL queries over large tables when a left join is no-longer necessary.
opw-3178866
closesodoo/odoo#116679
X-original-commit: c94d57edc002e499e317d04b2864d22acb5f40fa
Related: odoo/enterprise#38808
Signed-off-by: William André (wan) <wan@odoo.com>
before this commit, on enabling mass editing in payment and journals tree view, using studio throws exception saying field used in domain is missing in the view.
* install studio
* go to payment/journal tree view
* enable mass editing for the view using studio
* traceback is thrown
after this commit, no traceback on enabling mass editing
closesodoo/odoo#116127
X-original-commit: 3a53901aa4fce3080a42f9507de4afa5eb7cf7a4
Related: odoo/enterprise#38520
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The product `sale_timesheet.product_service_deliver_milestones` uses
`milestones` service_type but this is not available always.
Steps to reproduce issue:
1. Install sale_praject (with demo) in a clean DB
2. Unmark "Use milestones" in settings
3. Set invoice policy at delivery in settings
4. Try to install sale_timesheet
Demo data fails to install due to attempt to use milestores as service
type.
```
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 2720, in convert_to_cache
raise ValueError("Wrong value for %s: %r" % (self, value))
```
This issue blocks many upgrades.
closesodoo/odoo#116697
X-original-commit: 8ae7bf6c9a3af45353e5ef43d8b72f95c6731e5f
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Click on "Remove all" to remove all the images of the IG snippet.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).
When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.
When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.
To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.
task-3147271
closesodoo/odoo#116352
X-original-commit: 1c99ab2bc04f65999098f70d062d24ed1ac4a9c3
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
The web client has a mechanism to invalidate the action and the view
cache: in the basic model (and the relationalmodel), some code is
looking for updates to some specific models (such as ir.actions) and
trigger a `CLEAR-CACHE` event. This event is then listened by the action
and view services to properly clear the caches. This mechanism was also
used to reload the page after editing a company, or reloading the
currencies after editing some currency.
With this commit, we modify the orm service to trigger an event after
each rpc. This event can then be used by the action/view service, and
also by the currency/company services to perform their specific cleanup.
This work is one step in the future refactoring of the relational model.
closesodoo/odoo#115655
Related: odoo/enterprise#38814
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Yannick Tivisse