Steps to reprodue:
- Create a dropshipped product
- Sell the product to a client with a different language set
- Print the delivery slip

Bug:
delivery slip is currently being printed in the vendor's language

Fix:
Print the delivery slip in the client language when possible

opw-3193015

closes odoo/odoo#122706

X-original-commit: 832b4145
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

When moving a package, the quant at source location is not
automatically removed

To reproduce the issue:
1. In Settings, enable
   - Packages
   - Storage Locations
2. Create a storable product P
3. Update the on hand quantity
   - 1 x P at WH/Stock in package PK
4. Create a planned delivery D with 1 x P
5. Confirm and reserve D
   - PK should be reserved
6. Validate
7. Open the package
   - Its location is "Partner Locations/Customers", which make sense
8. Inventory > Configuration > ... > Locations, open WH/Stock
9. Current Stock

Error: There is a line with PK. The quantity is 0 but still, it
create some confusion for the user who could believe that the package
is still in WH/Stock

This issue does not occur if the user goes through the product form
and click on the on hand quantity. The "incorrect" quant will not be
there. This is because, when loading the action, we call
`_quant_tasks`:
https://github.com/odoo/odoo/blob/05a7f5c04804423cfc3a833a1b3f0b5eec3fc147/addons/stock/models/stock_quant.py#L296-L300
This method will clean the quants (merge & unlink)

However, in the above case (step 9), the action is defined on XML side:
https://github.com/odoo/odoo/blob/7d4dfeb0e26b387dee312897264a68963f90267f/addons/stock/views/stock_location_views.xml#L24-L26
https://github.com/odoo/odoo/blob/d956e719d43c68abe6210e3136db576aaa6f60b8/addons/stock/views/stock_quant_views.xml#L190-L196


So, we can't make it behave as it does from the product form,
unfortunatly.

As alternative, we can try to call `_unlink_zero_quants` when we are
moving a package (and not `_quant_tasks` for perf matters as, so far,
we will not have any quant to merge)

OPW-3292238

closes odoo/odoo#122673

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to reproduce the bug:
- Drop the "Form" snippet on the website.
- Add a new field.
- Replace the field label by two quotation marks (`""`).
=> Traceback appears.

Since [1], it is possible for the user to create forms whose fields can
have a conditional visibility, meaning that the field is only visible if
another field in the form meets certain conditions. Due to that, there
is a mechanism that verifies if a condition on a field should be updated
when the user modifies the label of a field. To do so, a `querySelector`
is searching for an element that has a `data-visibility-dependency` set
to the previous field name by doing a querySelector of type
`querySelectorAll('.s_website_form_field[data-visibility-dependency="${previousInputName}"]')`.
Because `previousInputName` is set to `"`, it is not considered as a
character and an error is thrown.
To resolve this problem, strings that are stored in `name`, `data-name`
and `data-visibility-dependency` are encoded: All the occurrences of `"`
are replaced by `"`, all the occurrences of `'` are replaced by
`'` and all the occurrences of ``` ` ``` are replaced by `‘`.

[1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce



opw-3246341

closes odoo/odoo#117632

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

The goal of this commit is to be able to use the `addCustomField`
function with a `type` argument that is different of `checkbox`,
`radio` or `select`.

opw-3246341

Part-of: odoo/odoo#117632

Group the res_partners in self by placeholder_path value before
calling __setitem__ on each group. Because placeholders are
independent from the recordset, we can set the value
of res_partner[avatar_field] to a placeholder for a recordset
of partners. When self contains lots of partners without
image_field value, this speeds up the _compute_avatar function
noticeably. This in turn speeds up stuff like loading
the Contacts KanbanView (search_read on res_partner).

Example speedup: In a database without any image for the partners,
search_read for avatar_128 with limit=80: 609ms -> 64ms.

opw-3128771

closes odoo/odoo#113756

Signed-off-by: Rémy Voet <ryv@odoo.com>

Before this commit, the widget value was updated (based on the current
state) prior to updating the snippet UI. As a result, the widget value
reflected used the non-updated UI labels.

task-3112890

closes odoo/odoo#122279

X-original-commit: b2daf688
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Divyesh Vyas (divy) <divy@odoo.com>

When processing several SMLs at once, the 'same product' policy of a
storage category is not respected

To reproduce the issue:
1. In Settings, enable:
   - Multi-Step Routes
   - Storage Categories
   - Packages
2. Create a Storage Category SC:
   - Allow New Product: same
3. Create two locations L1, L2:
   - Parent: WH/Stock
   - Type: Internal
   - Storage Category: SC
4. Create a putaway rule:
   - When in: WH/Stock
   - Package type: Pallet
   - Store to: WH/Stock
   - Having Category: SC
5. Edit the warehouse:
   - Incoming Shipments: 2 steps
6. Create two products P01, P02:
   - Type: Storable
7. Create a planned receipt R:
   - To: WH/Input
   - Operations:
     - 1 x P01
     - 1 x P02
8. Mark R as Todo
9. Create two packages:
   - 1 x P01 in PK01 (! PK01 must be a Pallet)
   - 1 x P02 in PK02 (! PK02 must be a Pallet)
10. Validate R
11. Open the related internal transfer

Error: Both packages are redirected to L1. Considering the product
policy of SC, one line should be redirected to L1 and the second one
to L2

To apply the product policy, the code looks at the quants of each
location. But it does not consider the incoming SMLs. Therefore, when
applying the putaway rule to the first SML, it selects L1 (which
makes sense). Then, for the second SML, because it does not see the
first one, it considers that L1 is empty and can be selected, hence
the error.

OPW-3204924

closes odoo/odoo#122616

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to reproduce:

- Install industry_fsm_report, website
- Create Project P, add column/stage PC.
- Edit stage, Email Template = Task: Intervention Schduled.
- Edit the template > Advanced Settings > Optional report to print and
  attach = Worksheet Report (PDF). Save everything.
- Go to website, "contact us" page > Edit the form, Action = Create a
  task, Project = P > Save

Issue:

When you first submit the form, it will fail, but the task will be
created and visible in project P. By instinct, the user will submit the
form again, so the task will be duplicated. The second form submit will
return a success message.

When submitting a form, we first generate a savepoint (added in
commit [1]).
Since this is the first interaction with the report system, during the
handling of the form, the assetsbundle will be generated (see keyword
'commit_assetsbundle'), which will cause a commit.
Finally, assuming no other error is raised, we try to delete the
savepoint.
However, since a commit was executed, then the savepoint will no longer
exist, which will cause an error status to be returned.

Solution:

When submitting a form, pass `commit_assetsbundle=False` to the record
creation, which prevents the commit from happening.

This solution has a downside; creating the record also sends an email
and the report attached to that email will have broken styling. This is
still an improvement to the current behaviour, which doesn't send the
first email at all.

[1]: https://github.com/odoo-dev/odoo/commit/5a499ecf113f08c11d2b33b47680dd00ec1b297b



opw-3183912

closes odoo/odoo#122571

X-original-commit: a3249673
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

A raw query is not necessary to produce the desired result, found
activities need to be kept only if the corresponding record can be found
with standard search (which includes multi-company check).

Part of task-3266643

closes odoo/odoo#122557

X-original-commit: 03c3d440
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Failing use case: While having purchase_stock installed, create and confirm a request for quotation, received some products but no bill for it. Now select the PO is the list, click on 'Action > Accrued Expense Entry'. Make sure the wizard will effectively create an accrued expense entry (it should be the case if you have some product received and not billed).
Upon confirmation of the wizard, the system will recompute the received quantity on the original PO, logging notes that pollutes, confuses and spams its followers.

The reason is that we use a new record to compute the difference between the received and billed quantities at a given date in the past, and even if track_qty_received is called on a newid, it will find back the original PO where doing line.order_id.

The solution is to check in the context if we're in such use case before logging, because we know that calling the accrued expense entry wizard aims not to change the received quantity in any wase

closes odoo/odoo#122448

Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

Steps to reproduce the bug (before the commits of this PR):
- Drop a Cover snippet on the website.
- Change the parallax to "None".
- Save and edit.
- Modify an option (for example, add a filter) to add the
`o_modified_image_to_save` class to the image.
- Change the parallax to "Fixed".
- Save.
- Inspect the Cover snippet.
=> The `span` element has the attributes `data-snippet="s_cover"` and
`data-name="Cover"`. Note that this could lead to problem during the
migration process.

Let's analyze the process  in order to better understand the problem:
- At the change of the parallax to "None", there is a change of the
target thanks to the call to `setTarget()`. The new target is now the
`section` element.
- At the save and edit, there is a call to `_loadImageInfo()`. All the
dataset (including `data-snippet` and `data-name`) of the new target is
copied in `this.img`.
- At the modify of an option, the `o_modified_image_to_save` class is
added to `this.img`.
- At the change of the parallax to "Fixed", there is a change of the
target thanks to the call to `setTarget()`. The new target is now the
`span` element.
- At the save, `cleanForSave()` is called and because there is the
`o_modified_image_to_save` on `this.img`, all the dataset of `this.img`
(including `data-snippet` and `data-name`) is copied on the new target
(the `span` element).

Note that this problem is resolved by the second commit of this PR.
Indeed, the dataset of the target is first filtered by
`_whiteListAttributes` before being copied into `this.img`. However,
databases that already have the problem will not be fixed by. The goal
of this commit is to remove the `data-snippet="s_cover"` and the
`data-name="Cover"` from the `span` elements in those existing
databases.

task-3287330

closes odoo/odoo#121682

X-original-commit: https://github.com/odoo/odoo/commit/9e48950e0c1268cfb2f5855861e7e95fd7a4abcd


Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>

*: web_editor, website

Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Put a "Blur" filter on the background image.
- Save.
- Change the parallax from "Fixed" to "None".
- Save and edit.
=> The "Filter" option displays "None" but should display "Blur".

When changing the parallax, `setTarget()` is called. The goal of this
function is to transfer the `background-image` from the old target to
the new one. The commit modifies this function by adding the transfer of
the dataset information relative to the background image from the old
target to the new one. It also transfers the `o_modified_image_to_save`
class from the old target to the new one if needed.

task-3287330

X-original-commit: https://github.com/odoo/odoo/commit/c06f39e3b6b44ffb433e17a457bd719a52842fa0
Part-of: odoo/odoo#121682

For background images, modifying options such as "Filter" does not
directly lead to the modification of their corresponding data attributes
in the DOM as those modifications are done at the save request. This
should not be the case. The goal of this commit is to, as for regular
images, modify their corresponding DOM data attributes at the option
update.

Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Replace the background image by one of your own.
- Add a filter to the background image.
- Inspect the Cover snippet.
=> The `data-gl-filter` attribute has not been added in the DOM and you
have to click on "Save" for it to be actually added.

task-3287330

X-original-commit: https://github.com/odoo/odoo/commit/597c9bb9fc9cff5c2276862faaa99c4546e29a90
Part-of: odoo/odoo#121682

Steps to reproduce the bug:
- Add a cover snippet on the website.
- Change the background image with one of your own.
- Save and edit again.
=> Options such as "Filter", "Width" and "Quality" do not appear
anymore.

The problem is that the `src` attribute of the background image is not
correctly updated when initializing the image. This is because the
target used to recover the URL of the background image is the snippet
and not the image itself. This problem is resolved by ensuring that the
argument of the function `getBgImageURL` is the background image. Now
that the `src` attribute is correctly updated, the `computeVisibility`
function of the the `BackgroundOptimize` option works properly and the
options "Filter", "Width" and "Quality" are displayed as wanted.

Note that now, the dataset of the target is filtered with a "white list"
(BACKGROUND_IMAGE_ATTRIBUTES) before being copied in the dataset of
`this.img`. Indeed, if the parallax is set to "None" for example, we do
not want data attributes such as `data-snippet` to be copied in the
dataset of `this.img`.

task-3287330

X-original-commit: https://github.com/odoo/odoo/commit/31ba9060723f365d16d51d3de0acf42c5e95f63b
Part-of: odoo/odoo#121682

Steps to reproduce:
In an account move, if the partner_id is changed to one that does not have a value assigned in the property_purchase_currency_id field and with a value in the context for default_currency_id,
when passing through the _onchange_partner_id function of the purchase module,

Cause:
the variable currency_id will take the value in the context as second option causing an error when trying to get the value in currency_id.id because currency_id will be an integer and not a record.

issue-121232

closes odoo/odoo#121921

X-original-commit: e04d4a0b
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

Steps to reproduce:
1. Create a BoM for a product tracked by serial number
2. Create a Qualty Control point for that product
3. Create a MO with Quantity: 2 Units
4. Confirm the MO
5. Click on Mass Produce
6. Generate the 2 Serial Numbers and apply

Bug:
quality check not registered on the backorder

Fix:
adding a function to be overloaded in Entreprise
back port of this fix[1]

[1]:https://github.com/odoo/odoo/pull/95982



opw-3210242

closes odoo/odoo#121169

Related: odoo/enterprise#40951
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

closes odoo/odoo#122442

X-original-commit: fa2cb330
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Steps to reproduce the bug :

- Add the same google font twice with the font family selector in the
option tab of the editor panel.
- The font will be displayed only once in the font selector menu but 2
trash icons will be added, one for the added font and one for the font
that was already there.

This commit fix this and allows now the user to add the same font twice,
but only to replace a served font by a local font. The opposite does not
make sense, but if the user really wants to replace a local font with a
served, it is always possible by deleting the locale beforehand.

In addition, this commit adds a cloud icon next to the default fonts of
the theme. Since these fonts are served by Google, it is logical to have
the cloud icon. This is consistent with the cloud icon that is present
when the user adds a font served by Google.

task-2998689

closes odoo/odoo#122359

X-original-commit: be503205
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

After commit 9bf54f09, we assumed that
the date field of a move was never empty. On the form view, it can be
(temporarily) empty though (before save), causing an error when trying
to read it.

We now don't try to recompute the name when the date is empty, thus
preventing the date field to be read in that method.

task-3326834

closes odoo/odoo#122297

X-original-commit: 5a3a8d0b
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>

The uom should be editable on new lines, independently of their state.
With this commit, users will be able to change the uom on new lines of locked/cancelled/confirmed orders.

closes odoo/odoo#122246

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

When creating an downpayment invoice for a SO with a incoterm different than the default one, this invoices ignores the incoterm you defined and uses the default value.

This issue is happening because in the _prepare_invoice_values is not passing the value of correct value of the incoterm and the default value is being used.

How to reproduce:
1. Active "incoterms" and choose a default incoterms in settings
2. Create a SO with a incoterm different than the default one
3. Create a downpayment invoice
4. In the new created invoice the incoterm is set as the default incoterm instead of the previously defined

closes odoo/odoo#120823

Opw: 3284556
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

as Adyen sends the same notification data for POS and online payments
that can not be distiguished, the webhook controller logs a stacktrace
for every POS payment. If the payment_adyen is installed it generates
noise in logs as the POS transaction can not be found in online
payments. To clear the log we make missing transaction as warning to
not log the stacktrace.

task-2960381

closes odoo/odoo#120625

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Steps to reproduce:
Without being logged in,
complete the purchase flow on the ecommerce,
taking care to have a different billing
and shipping address.
If you change the delivery address,
you will get an access error.

Cause:
In some cases, we do not have access to
the `name` field of the `partner` record.

Solution:
Add `sudo` to be able to read the fields.

opw-3276877

closes odoo/odoo#122258

X-original-commit: 1d6ae6bb
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>

When user enters empty space in name field instead of entering an
actual name and confirm their billing, shipping address then when
they click on paynow to confirm order they will face the issue
'list index out of range'.

Note : Do the paypal configuration before following below steps.

Steps to produce:
1) Vist the website as a public user.
2) Create a sale order by adding some products to the cart.
3) While entering shipping and billing address, in the name field enter
some space.
4) Click on next button.
5) Now a sale order is created.
6) Go to orders through 'website' module.
7) Open the order created and generate a payment link.
8) Paste that payment link in another tab or browser .
9) Click on pay
10) By following above steps you will encounter the error.

This commit will prevent the above error.

sentry - 4177783431

closes odoo/odoo#122229

Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>

1.

Infinite loop may happen on using `parent_of`\`child_of` when there is a
recursion in the tree (e.g. a record is marked as a parent of itself). Fix it by
excluding seen records from the next iteration.

2.

Another problem with `child_of` is `parent_id` that references to another model.
For example, the `parent_id` may come from inherited model. It's the case with
`res.users` and `res.partner` models. It may lead to a random search results.
Avoid that by raising exception in case of wrong usage of the `child_of`
operator.

STEPS:

In demo data, there is a partner called "Wood Corner" that is `res.partner(9,)`
that has 3 sub-contacts. If we give Portal access to two of them, we end up with
a database, where we have a `res.users(9,)` record that has a partner, which has a
`parent_id` to "Wood corner". So this way, the user id is the same as the user's
partner's parent contact id.

After that open a shell and type:

```
env['res.partner'].search([["user_ids", "child_of", 9]])
```

BEFORE: infinite loop (without change n.1) or random search results (when change
n.1 is applied)
AFTER: ValueError exception

---

opw-2729740

closes odoo/odoo#122080

X-original-commit: 3c9b3457
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>

This reverts commit 12355a80042c70d.

Following of the next steps https://www.odoo.com/web#id=3338017&cids=1&model=project.task&view_type=form



Initial opw-2992106

closes odoo/odoo#122431

Signed-off-by: William André (wan) <wan@odoo.com>

When duplicating the reco model, we want to counterpart entry lines to be copied as well.

closes odoo/odoo#122332

X-original-commit: c5d5f4db
Signed-off-by: William André (wan) <wan@odoo.com>

The selection function get_selection_class for the field classname has
obviously been thought to be overridable by subclasses in order to add
new selection classes if need be.

However, before this commit the method was passed directly to the
Selection constructor, which used the callable object directly. If it
was overridden by a subclass, the Selection object would still use the
same non-overridden callable instance.

With this commit, we give the name of the method instead of the
callable, which makes that the method is resolved after all overrides,
and therefore the resulting selection will be the overridden one.

closes odoo/odoo#122341

X-original-commit: 91bea596
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Paul Morelle (pmo) <pmo@odoo.com>

Before this PR, when multi vat was activated and a foreign vat number was set on
 a fiscal position it was not printed on the invoice for the following layout:
 Striped, light and boxed. The Bold layout is not impacted since it does not use
 company details.

 This PR adds the foreign vat on the invoice when it's necessary.

closes odoo/odoo#118782

Task-id: 3248767
Signed-off-by: John Laterre (jol) <jol@odoo.com>

If applied, this commit will solve the min-max issues for efaktur.

- invalid literal for int() with base 10: when we enter all characters
string in the min or max it will raise an error like this.

- Error is also raised when the min or max is blank and try to save the
record.

So, I have update the value as 0 if the min value or max value not
generated.

see - https://tinyurl.com/2lx9j2kr



Sentry - 3936020226

closes odoo/odoo#122278

X-original-commit: 78ecfd66
Signed-off-by: William André (wan) <wan@odoo.com>

closes odoo/odoo#122232

X-original-commit: b061cf71
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

False

closes odoo/odoo#122021

Signed-off-by: William André (wan) <wan@odoo.com>

User was not able to go through onboarding if they switched company.
By default it tried to edit default payment provider that was conected
to the main company, so other companies were recieving Access Error.

opw-3298326

closes odoo/odoo#121619

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

qty_received_method is not recomputed if the product type change, and can lead to issues on existing purchases when trying to generate a Vendor Bill.

# HOW TO REPRODUCE:
- Create product P, type: Service, Control Policy: 'On Received Qty'
- Create PO for 1 unit of P (do not confirm)
- Update type of P to Storable
- Confirm PO, Receive Products
=> Qty Received is 0, not able to generate Bill

closes odoo/odoo#122199

X-original-commit: 193f1d8c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

ZeroDivsionError: float division to Zero is generated because for assigning
value to 'factor' of uom in method '_set_ratio', it tries to divide value by
Zero for uom_type 'Bigger'.

Steps to reproduce:
1) Install 'Inventory' module.
2) Click on 'Configuration' > 'Settings'.
3) Activate 'Units of Measure' > click on 'Units of Measure' button under it.
4) Click on 'Create' button to create new uom category.
5) Give any name > in 'Units of Measure' page, click on 'Add a line'.
6) Enter name and select type as 'Reference unit of measure for this category'.
7) Now, add another line and select type as 'Bigger than the the Reference unit
   of measure' and set the 'ratio' value to Zero, Error will be generated.

By applying this,it will check for the value of 'ratio' to prevent division by 0

sentry - 4174584503

closes odoo/odoo#121409

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

closes odoo/odoo#120219

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

*website

Steps to reproduce the bug:
- Add a Cover and a Picture snippet on the website.
- Change their visibility to "Conditionally".
- Change the order of the two snippets on the page either with the drag
and drop tool or with the "move up" or "move down" option.
=> Their order on the "Invisible Elements" panel has not been updated.

The problem is fixed by calling `_updateInvisibleDOM()` at the end of
`moveSnippet()` and `_onSnippetDragAndDropStop()`. Note that before this
commit, all the snippets with a conditional visibility were hidden at
the call of `_onSnippetDragAndDropStop()`. This is due to the call of
`cleanForSave()` from `_destroyEditors()`. `_onSnippetDragAndDropStop()`
has been adapted in order to, as for the "move" option, do not change
the visibility of those elements.

task-3203914

closes odoo/odoo#113549

Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>

*web_editor, website

Steps to reproduce the bug:
- Add a Text-Image snippet.
- Change its visibility to "Conditionally".
- Save.
- Edit again.
=> The eye icon indicates that the snippet is not visible but the
snippet is displayed.

Note that [1] introduced a mechanism to solve this problem (the
`cleanForSave()` of the `ConditionalVisibility` option) but the code was
not working correctly since [2].

Let's first remember that when calling `toggleTargetVisibility()`, two
main actions are performed:
- The addition or suppression of the `data-invisible` attribute from the
dataset of an invisible element. This attribute is responsible for the
crossed or not of the eye icon in the "Invisible Elements" panel.
- The call to `onTargetHide()` or `onTargetShow()` that performs among
other things the addition or the suppression of the
`o_conditional_hidden` class on an invisible element. This class is
responsible for the visibility of the element on the page in edit mode.

This being said, here is what happened at the "Save" before this commit:
- `cleanForSave()` of `snippetEditor` is called. If the related element
has the `o_snippet_invisible` class, `toggleTargetVisibility(false)` is
called (meaning that the `o_conditional_hidden` class and the
`data-invisible` attribute are added to the element).

- `cleanForSave()` of the `ConditionalVisibility` option is called and
before [2], the `data-invisible` attribute was removed from the
corresponding element.

- At the `DOMContentLoaded`, the `o_conditional_hidden` class is removed
from all the elements that have a conditional visibility. The visibility
of those elements on the page now depends on the rule set by the user.

The goal of this commit is to restore the mechansim of the remove of the
`data-invisible` attribute from the conditionnal elements at the
`cleanForSave()`.

[1]: https://github.com/odoo/odoo/commit/1c442782f887a8c16bae05a43fae13a310ac05df
[2]: https://github.com/odoo/odoo/commit/de3c29fab2bc5349da8a9418f9d0086d76e6f7de

task-3203914

Part-of: odoo/odoo#113549

Steps to reproduce the bug:
- Add a form snippet on the footer of the website page.
- Change the visibility of the form snippet to "conditionally".
- On the footer settings, deactivate the "Page Visibility".
=> The form snippet is still present on the "Invisible Elements" panel
but clicking on it has no effects. Indeed, it is inside the footer which
is hidden.

The goal of this commit is to reorganize the "Invisible Elements" panel
in order to better visualize the hierarchy between the different
invisible elements. To do so, the list of the invisible snippet elements
(`[...$invisibleSnippets]`) is scanned. Each invisible snippet that is
the descendant of another is discarded of the list (to only keep the
"root" ones) and a map is created with its `keys` set to invisible
snippets that have invisible descendants. The `value` corresponding to
an invisible snippet element is a list filled with all its descendant
invisible snippets except those that have a closer invisible snippet
ancestor. The list of the root snippets is then scanned. Each root
snippet is inserted in the DOM as well as their descendant snippets
found thanks to the newly created map.

Note that thanks to this commit, another problem is solved:
- Add a cookie bar on the website.
- Add a Text-Image snippet and change its visibility to "conditionally".
- Save and edit again. Note that the "Cookies Bar" is above the "Text-
Image" on the "Invisible Elements" panel.
- Click to display the cookie bar.
=> The order of the "Cookies Bar" and the "Text-Image" is switched on
the "Invisible Elements" panel.
Indeed, before this commit, the order of the snippets was influenced by
the order of their snippet editor creation. Because this order was not
always the same from one call to `_updateInvisibleDOM()` to another, a
glitch could happen when toggling a snippet visibility.
This is now fixed as the order of the invisible snippets in the
"Invisible Elements" panel is determined either by their order in the
list `rootInvisibleSnippetEls` or their order in the lists contained as
value in the map `descendantPerSnippet`.

task-3203914

Part-of: odoo/odoo#113549

Previously, it was not possible to apply the Global Discount in cases
where there was a fiscal position with tax included in the price. This
was because of using in the `get_taxes` function, which do not return
taxes after fiscal position.

opw-3267243

closes odoo/odoo#118837

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>