In the website builder, when pasting a youtube url, we can transform it to an iframe in the editor through the Powerbox. Adding the iframe did not remove the text in the website builder. Now it properly remove the text in note and the website builder. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78375

In the website builder, when pasting a youtube url,
we can transform it to an iframe in the editor through the
Powerbox.
Adding the iframe did not remove the text in the website builder.
Now it properly remove the text in note and the website builder.




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#78375

Before this commit, the editor hint were not properly removed because the queryselector was made on the wrong document. Task-2678410 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79089

Before this commit, the editor hint were not properly
removed because the queryselector was made on
the wrong document.

Task-2678410




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#79089

When starting the editor in a web page, if there is no content, the oe_structure is not editable. Adding snippet at that moment will trigger `idSet` on the node with isUnbreakable returning `false` for the node that is unbreakable because of the check `!node.isContentEditable` in `isUnbreakable`. When setting the ouid for the first time with `idSet`, `getOuid` is called with `optimize` to `true`. So all the ancestor of a node that should be unbreakable will have the wrong ouid. Perfo

When starting the editor in a web page, if there is no content, the
oe_structure is not editable. Adding snippet at that moment will
trigger `idSet` on the node with isUnbreakable returning `false` for
the node that is unbreakable because of the check
`!node.isContentEditable` in `isUnbreakable`.

When setting the ouid for the first time with `idSet`, `getOuid` is
called with `optimize` to `true`. So all the ancestor of a node that
should be unbreakable will have the wrong ouid.

Performing any command to a node with a wrong ouid is suceptible to
wrongly be reverted.

By removing `!node.isContentEditable`, the node will have the proper
ouid in case an ancestor is not editable.

task-2633368

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#78897

### Latam Task 295 - Add a generic common module for tests in l10n_ar and related modules (l10n_ar_reports, l10n_ar_edi and l10n_ar_website_sale) - Move part of the initialization, helpers, and generic unit test from l10n_ar_edi to l10n_ar - Create all data used in the test on the fly, replicating what we have already in demo data. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78477 Forward-Port-Of: odoo/odoo#75223

### Latam Task 295

- Add a generic common module for tests in l10n_ar and related modules (l10n_ar_reports, l10n_ar_edi and l10n_ar_website_sale)
- Move part of the initialization, helpers, and generic unit test from l10n_ar_edi to l10n_ar
- Create all data used in the test on the fly, replicating what we have already in demo data.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#78477
Forward-Port-Of: odoo/odoo#75223

`s_map` snippet is calling maps.google.com which might be the reason this tour experience some race condition when trying to drag and drop the `s_newsletter_subscribe_form` (which happen after the `s_map` snippet was dropped). When the race condition happen, we can see on the screenshot that the snippet was drag & dropped into the footer instead of the `s_text_image` inside the `#wrap` as it should be (see comment on first step of the test). The reason the snippet is not dropped where i

`s_map` snippet is calling maps.google.com which might be the reason this tour
experience some race condition when trying to drag and drop the
`s_newsletter_subscribe_form` (which happen after the `s_map` snippet was
dropped).

When the race condition happen, we can see on the screenshot that the snippet
was drag & dropped into the footer instead of the `s_text_image` inside the
`#wrap` as it should be (see comment on first step of the test).
The reason the snippet is not dropped where it should be is because the `s_map`
was not removed as it should have been (seeing the screenshot), so the page was
scrolled and the footer became the first available and visible `o_editable`.

The `s_map` snippet is probably still in the DOM (despite a step is in charge
of removing it) because it is recreated after the google maps server reply,
which sometimes is probably taking an unexpected long time.

Anyway, external services should never be called during tests, removing the
snippet from the tour is an "easy" first step to try to fix the race
condition.

Forward-Port-Of: odoo/odoo#79102

This commit fixes the 'You need to supply a Lot/Serial Number...' message when validating a receipt with backorder for subcontracted tracked products. task: 2604664 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79107 Forward-Port-Of: odoo/odoo#78062

This commit fixes the 'You need to supply a Lot/Serial Number...' message
when validating a receipt with backorder for subcontracted tracked products.

task: 2604664

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#79107
Forward-Port-Of: odoo/odoo#78062

Steps to reproduce: * Create PO * Confirm Receipt Date * Cancel PO * Draft and Confirm again Current behavior: * Button for Confirm Receipt Date is not visible Expected behavior: * Button for Confirm Receipt Date should be visible This is happening as we are not resetting the value of `mail_reminder_confirmed` on cancelling PO. With this commit, we reset value of `mail_reminder_confirmed` so use can Confirm Receipt Date again. Description of the issue/feature this

Steps to reproduce:

* Create PO
* Confirm Receipt Date
* Cancel PO
* Draft and Confirm again

Current behavior:

* Button for Confirm Receipt Date is not visible


Expected behavior:

* Button for Confirm Receipt Date should be visible


This is happening as we are not resetting the value of `mail_reminder_confirmed` on cancelling PO.

With this commit, we reset value of `mail_reminder_confirmed` so use can Confirm Receipt Date again.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#59674

This reverts commit 2e58d23e760313dbf58ce6a90f26b7160db460d8. Actually the fleet officers want to be notified. The correct way to handle the original issue is to ping the employees via their documents, instead of on the fleet.vehicle, to avoid setting them as followers of the car. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.

This reverts commit 2e58d23e760313dbf58ce6a90f26b7160db460d8.

Actually the fleet officers want to be notified.

The correct way to handle the original issue is to ping the employees
via their documents, instead of on the fleet.vehicle, to avoid setting
them as followers of the car.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#78695

Issue: When returning a product sold that is only made of kits and validating the return, the delivered quantities of the sales order was set back to the full amount delivered Steps to reproduce : 1) Install MRP and Sales 2) Create a BoM Kit for a new product [Nested Kit] that has one or more consumable or storable product as component 3) Create a BoM Kit for a new product [Main Kit] that has [Nested Kit] as component 4) Create a SO for [Main Kit], confirm, validate de

Issue: When returning a product sold that is only made of kits and
validating the return, the delivered quantities of the sales order was
set back to the full amount delivered

Steps to reproduce :
  1) Install MRP and Sales
  2) Create a BoM Kit for a new product [Nested Kit] that has one or
    more consumable or storable product as component
  3) Create a BoM Kit for a new product [Main Kit] that has
    [Nested Kit] as component
  4) Create a SO for [Main Kit], confirm, validate delivery
  5) Check SO, 1 product is delivered (correct)
  6) Go back to the Delivery, create a return for the delivery
    (don't validate)
  7) Check SO, 0 product is delivered (correct)
  8) Now validate the return for the delivery
  -> Check SO, 1 product is delivered (bug)

Why is that a bug:
 Since the Main Kit was returned, the delivered should be 0 and not
 the full amount initially delivered. It was set back to 1 because we
 didn't look at the type of picking, when computing the quantity
 delivered, the fall back considered that if all the moves were done,
 everything was delivered, but it is the opposite when returning

opw-2542337

Forward-Port-Of: odoo/odoo#78838
Forward-Port-Of: odoo/odoo#75256

Before this commit, the router didn't considered as equal an integer value given as an integer or as a string (e.g. "1" or 1), whereas form the url point of view, it's exactly the same, and the information is lost anyway. As a consequence, pushing something like { id: "1" } in the url that already contained id=1 created a new entry in the history, which isn't what we want as the url is the same. This commit fixes the issue by converting string values into numbers when it is possible.

Before this commit, the router didn't considered as equal an
integer value given as an integer or as a string (e.g. "1" or 1),
whereas form the url point of view, it's exactly the same, and the
information is lost anyway.

As a consequence, pushing something like { id: "1" } in the url
that already contained id=1 created a new entry in the history,
which isn't what we want as the url is the same.

This commit fixes the issue by converting string values into
numbers when it is possible.

This commit also changes the way the action service pushes the id
and active_id in the url, as there's no need to pass string values
anymore (this was the case in the early days of the wowl branch).

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#79029

Avoids the ambiguity of the department_id column in hr_attendance_report.py by specifying the table in the SELECT clause. While upgrading to Odoo 15.0, if the database contains a module that adds the column department_id to the table hr_attendance_overtime, the following error occurs: ``` Traceback (most recent call last): File "/home/odoo/src/odoo/15.0/odoo/service/server.py", line 1246, in preload_registries registry = Registry.new(dbname, update_module=update_module) File

Avoids the ambiguity of the department_id column in
hr_attendance_report.py by specifying the table in the SELECT clause.

While upgrading to Odoo 15.0, if the database contains
a module that adds the column department_id to
the table hr_attendance_overtime, the following error occurs:

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/15.0/odoo/service/server.py", line 1246, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/15.0/odoo/modules/registry.py", line 87, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/15.0/odoo/modules/loading.py", line 472, in load_modules
    force, status, report, loaded_modules, update_module, models_to_check)
  File "/home/odoo/src/odoo/15.0/odoo/modules/loading.py", line 365, in load_marked_modules
    perform_checks=perform_checks, models_to_check=models_to_check
  File "/home/odoo/src/odoo/15.0/odoo/modules/loading.py", line 199, in load_module_graph
    registry.init_models(cr, model_names, {'module': package.name}, new_install)
  File "/home/odoo/src/odoo/15.0/odoo/modules/registry.py", line 425, in init_models
    model.init()
  File "/home/odoo/src/odoo/15.0/addons/hr_attendance/report/hr_attendance_report.py", line 50, in init
    """ % (self._table))
  File "<decorator-gen-3>", line 2, in execute
  File "/home/odoo/src/odoo/15.0/odoo/sql_db.py", line 89, in check
    return f(self, *args, **kwargs)
  File "/home/odoo/src/odoo/15.0/odoo/sql_db.py", line 310, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "department_id" is ambiguous
LINE 6:                         department_id,
                                ^
```
upg-42212

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#78524

Since commit `37eb0dfbb54` it was no longer possible to create Expense Products. The field `detailed_type` was not present in the view hence it didn't get its default value of 'service'. TaskID: 2678961 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79115

Since commit `37eb0dfbb54` it was no longer possible to create Expense
Products. The field `detailed_type` was not present in the view hence it
didn't get its default value of 'service'.

TaskID: 2678961

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#79115

Under account.document_tax_totals template the subtotal and total were using the float amounts for printing. There was the formatted currency returned from _compute_tax_totals_json but not printed. This commit uses the formatted_amount and formatted_amount_total keys to display the amount with currency on PDF and portal view. closes #77996 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#79064

Under account.document_tax_totals template the subtotal and total were using the float amounts for printing.

There was the formatted currency returned from _compute_tax_totals_json but not printed.
This commit uses the formatted_amount and formatted_amount_total keys to display the amount with currency on PDF and portal view.

closes #77996




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#79064

Since the addition of <a> tag with `href='#'` added in https://github.com/odoo/enterprise/pull/16579 the default behaviour of the click was to go back to `rootUrl/web#` which was closing the documents app and therefore the PDF splitter. This commit fixes this issue. opw-2668807 Forward-Port-Of: odoo/enterprise#21967

Since the addition of <a> tag with `href='#'` added in
https://github.com/odoo/enterprise/pull/16579 the default behaviour
of the click was to go back to `rootUrl/web#` which was closing the
documents app and therefore the PDF splitter.

This commit fixes this issue.

opw-2668807

Forward-Port-Of: odoo/enterprise#21967

**The SEPA direct debit mandate report always uses the company header of the first company in the DB rather than that of the mandate beneficiary. ** Impacted versions: 13.0, 14.0, 15.0 Steps to reproduce: 1. Create a DB and install the `account_sepa_direct_debit` module. Set up the DB with at least 2 companies and configure the document layout for the companies to display their address (so that you can easily spot the difference) 2. Select a company other than the company with index 1

**The SEPA direct debit mandate report always uses the company header of the first company in the DB rather than that of the mandate beneficiary. **

Impacted versions: 13.0, 14.0, 15.0
 
Steps to reproduce:
 1. Create a DB and install the `account_sepa_direct_debit` module. Set up the DB with at least 2 companies and configure the document layout for the companies to display their address (so that you can easily spot the difference)
 2. Select a company other than the company with index 1 in res_company. 
 3. Go to Accounting/SEPA Direct Debit Mandates/Create
 4. Select any client and enter IBAN details - if you need dummy data, these are from Amy-Caroline's tutorial:
        BE81 8979 6289 4224
        ING – BBRUBEBB
 5. Select a journal, e.g. 'Bank' and enter IBAN details - here's some more dummy data from the tutorial:
        BE44 7359 2299 9545
        BNP Paribas - GEBABEBB
 6. Click 'Save'
 7. Click 'Print'
 
Current behavior:
 - The header does not correspond to the company issuing the mandate, but rather to the first company in the DB. 
 
Expected behavior:
 - The header should be that of the company issuing the mandate. 

Code analysis:
 - The code responsible for setting the correct header and document format is at [empty_mandate_report.xml:24](https://github.com/odoo/enterprise/blob/master/account_sepa_direct_debit/report/empty_mandate_report.xml#L24) which calls the `external_layout` template defined at [report_templates.xml:471](https://github.com/odoo/odoo/blob/master/addons/web/views/report_templates.xml#L471). 
- The `external_layout` template expects a `o` or `doc` object to exist, corresponding to the object for which the report will be generated. As can be seen from other reports, e.g. [report_invoice.xml:252](https://github.com/odoo/odoo/blob/master/addons/account/views/report_invoice.xml#L252), the `o` object is usually set, which enables the `external_layout` template to retrieve the correct company at [report_templates.xml:480](https://github.com/odoo/odoo/blob/master/addons/web/views/report_templates.xml#L480). 
- However, in [empty_mandate_report.xml:17](https://github.com/odoo/enterprise/blob/master/account_sepa_direct_debit/report/empty_mandate_report.xml#L17) the object for which the report is to be generated is named not `o` or `doc` but rather `mandate`. 
- As a result, [report_templates.xml:480](https://github.com/odoo/odoo/blob/master/addons/web/views/report_templates.xml#L480), which should have retrieved the correct company, does not execute; and instead [report_templates.xml:483](https://github.com/odoo/odoo/blob/master/addons/web/views/report_templates.xml#L483) executes, which simply selects the database's first company. 

Solution:
- Rename `mandate` to `o` in [empty_mandate_report.xml:17](https://github.com/odoo/enterprise/blob/master/account_sepa_direct_debit/report/empty_mandate_report.xml#L17), propagating the change. 

Fixes Support Ticket no. 2663561

Merci à @oco-odoo pour ton intérêt pour ce fix :smile:

Forward-Port-Of: odoo/enterprise#21899

This commit is the counterpart of [1], where we no longer push the state in the url if it hasn't changed. In the updated test, we relied on that faulty behavior. [1] https://github.com/odoo/odoo/pull/79029 Forward-Port-Of: odoo/enterprise#21929

This commit is the counterpart of [1], where we no longer push the
state in the url if it hasn't changed. In the updated test, we
relied on that faulty behavior.

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

Forward-Port-Of: odoo/enterprise#21929

Autofill a header cell such that the autofilled cell will become a "Total" formula: the tooltip is an empty square. Task 2627495 Forward-Port-Of: odoo/enterprise#21927 Forward-Port-Of: odoo/enterprise#20944

Autofill a header cell such that the autofilled cell will become a "Total"
formula: the tooltip is an empty square.

Task 2627495

Forward-Port-Of: odoo/enterprise#21927
Forward-Port-Of: odoo/enterprise#20944

### Latam Task 295 Adapt l10n_ar_edi tests to account tests, inheriting from the class defined in l10n_ar where we are creating the data on the fly. --- Forward-Port-Of: odoo/enterprise#21734 Forward-Port-Of: odoo/enterprise#20298

### Latam Task 295

Adapt l10n_ar_edi tests to account tests, inheriting from the class defined in l10n_ar where we are creating the data on the fly.

---

Forward-Port-Of: odoo/enterprise#21734
Forward-Port-Of: odoo/enterprise#20298