Methods from l10n_cl_edi has been moved from l10n_cl_edi (enterprise) as part of https://github.com/odoo/enterprise/pull/46593. This includes _l10n_cl_get_amounts and _float_repr_float_round on the account move model, as well as the method _l10n_cl_get_line_amounts on the account move line model. They can therefore be removed in this commit. The VAT section for the electronic ticket document is also being transferred in the same manner, and can thus be removed in the template here. As par

Methods from l10n_cl_edi has been moved from l10n_cl_edi (enterprise) as part of https://github.com/odoo/enterprise/pull/46593. This includes
_l10n_cl_get_amounts and _float_repr_float_round on the account move model, as well as the method _l10n_cl_get_line_amounts on the account move line model. They can therefore be removed in this commit.

The VAT section for the electronic ticket document is also being transferred in the same manner, and can thus be removed in the template here.

As part of the same refactor, methods _l10n_cl_get_invoice_totals_for_report and _l10n_cl_prices_and_taxes had been deprecated, and additionally there is a new exclusive qweb totals widget for chilean invoices. This will allow showing in PDF reports, invoices that had been generated in a foreign currencies or in UF index.

X-original-commit: 7d22eaaf135e20b5c94e8419b8b6418483f1a139

[FIX] l10n_cl: replace t-esc with t-out

(cherry picked from commit 27f592e49b381cf3344b808db8358c677a528489)

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#164062
Forward-Port-Of: odoo/odoo#162147

Since [1] cover images are implicitly converted to webp. Those converted images were stored related to their record (e.g. a given blog post). Because of this, the created attachment was not made public, and therefore not available for visitors. This commit fixes this by linking the cover image to the general concept of `ir.ui.view` - as it was the case before images were converted. Doing this makes the image attachments public. Steps to reproduce: - Upload a JPG image as a published blog

Since [1] cover images are implicitly converted to webp. Those converted images were stored related to their record (e.g. a given blog post). Because of this, the created attachment was not made public, and therefore not available for visitors.

This commit fixes this by linking the cover image to the general concept of `ir.ui.view` - as it was the case before images were converted. Doing this makes the image attachments public.

Steps to reproduce:
- Upload a JPG image as a published blog post cover.
- Save => a WEBP version of the image is uploaded.

=> Visitors could not see the image when viewing the blog post.

[1]: https://github.com/odoo/odoo/commit/068dcc27e417d52b51d274c44497f4388fed780a

opw-4009916

Forward-Port-Of: odoo/odoo#170849

Ensure that _setup_main_restaurant_defaults is only called when the main restaurant does not have an active session. This prevents potential errors that could occur if the method is called while a session is active. E.g: https://runbot.odoo.com/runbot/build/64372543 opw-3937178 Forward-Port-Of: odoo/odoo#170507

Ensure that _setup_main_restaurant_defaults is only called when the main restaurant does not have an active session. This prevents potential errors that could occur if the method is called while a session is active. E.g: https://runbot.odoo.com/runbot/build/64372543

opw-3937178

Forward-Port-Of: odoo/odoo#170507

Steps to reproduce the bug: - Go to the "/partners" page. - Click on the first partner to go to their page. - Enter "edit mode". - Drag and drop a "Dynamic products" snippet into the right column of the page. - Save the page. - Bug: the "Dynamic products" snippet is not visible on the page. The problem is not specific to the "Dynamic products" snippet. The issue occurs with all snippets. When the "website description" field is saved, all HTML attributes are removed (except the "cla

Steps to reproduce the bug:

- Go to the "/partners" page.
- Click on the first partner to go to their page.
- Enter "edit mode".
- Drag and drop a "Dynamic products" snippet into the right column of
the page.
- Save the page.
- Bug: the "Dynamic products" snippet is not visible on the page.

The problem is not specific to the "Dynamic products" snippet. The issue
occurs with all snippets. When the "website description" field is saved,
all HTML attributes are removed (except the "class" attribute). This
causes many bugs, which vary depending on the snippets dropped into the
field.

This commit adds the parameter "sanitize_overridable=True" to the
"website_description" field of "website_partner". It means that the
description can now be properly edited as an user with enough rights,
while keeping the same level of protection for other users editing this
field. Still buggy, below version 15.0, for a restricted editor editing
that description but should be rare.

opw-3908218

Forward-Port-Of: odoo/odoo#165482

In Switzerland's demo data, the BIC is from a Belgian bank which is wrong. Removing BIC in this case as it's useless. task-3961609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167726

In Switzerland's demo data, the BIC is from a Belgian bank which is wrong. Removing BIC in this case as it's useless.

task-3961609

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

Forward-Port-Of: odoo/odoo#167726

In 76d328624fecaed5167b0e4fc1210014309d59a9, the underscore methods were removed. Following this change, a traceback occurs because concat is supposed to be used on an Array. When no element is in existing tags, addedTags is null, and if there is a single tag, it is not an array but an object. In order to fix this, we format properly the addedTags to have an array, allowing the use of the concat method. Task-3527175 Forward-Port-Of: odoo/odoo#170856

In 76d328624fecaed5167b0e4fc1210014309d59a9, the underscore methods were removed. Following this change, a traceback occurs because concat is supposed to be used on an Array. When no element is in existing tags, addedTags is null, and if there is a single tag, it is not an array but an object.

In order to fix this, we format properly the addedTags to have an array, allowing the use of the concat method.

Task-3527175

Forward-Port-Of: odoo/odoo#170856

The keyboard shortcut for the `Check Sending` action was the same as the one used to create a new record. Ticket [link](https://www.odoo.com/web#model=project.task&id=3970056) opw-3970056 Forward-Port-Of: odoo/odoo#168160

The keyboard shortcut for the `Check Sending` action
was the same as the one used to create a new record.

Ticket [link](https://www.odoo.com/web#model=project.task&id=3970056)
opw-3970056

Forward-Port-Of: odoo/odoo#168160

Prior to this PR, if the words inside the grid were too long (ex: german), they were overflowing under the other elements of the grid. In worst cases scenario, words may be truncated. task-3815487 **Before**  **After**  --- I confir

Prior to this PR, if the words inside the grid were too long (ex: german), they were overflowing under the other elements of the grid.
In worst cases scenario, words may be truncated.

task-3815487

**Before**  
 
![Screenshot 2024-05-28 at 17 19 58](https://github.com/odoo/odoo/assets/108661430/ad6c82b5-7ac7-4393-9081-55146d07ec98)

**After** 
![Screenshot 2024-05-29 at 10 01 19](https://github.com/odoo/odoo/assets/108661430/27f0ad9f-5999-4335-a45a-4492e79bdeb5)




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

Forward-Port-Of: odoo/odoo#158066

**Cause:** In version 17.0, new fields (repeat_unit, repeat_type, repeat_until) [ref](https://github.com/odoo/odoo/blob/d7cfef9c51461a595f3f46c7b91e5c56241d4af3/addons/maintenance/models/maintenance.py#L265) were introduced in the maintenance module. These fields are set as required in the view 'maintenance.hr_equipment_request_view_form', but they are only visible if the request is a recurrent maintenance request, which causes a validation error when changing the status. **Solution:** Change

**Cause:** In version 17.0, new fields (repeat_unit, repeat_type, repeat_until) [ref](https://github.com/odoo/odoo/blob/d7cfef9c51461a595f3f46c7b91e5c56241d4af3/addons/maintenance/models/maintenance.py#L265) were introduced in the maintenance module. These fields are set as required in the view 'maintenance.hr_equipment_request_view_form', but they are only visible if the request is a recurrent maintenance request, which causes a validation error when changing the status.

**Solution:** Change the required condition 'True' to recurring_maintenance == True, as the field is only visible for recurring maintenance requests. Making it required for all cases is not feasible.

**Note:** This is not a bug in the general version of 17.0; it is introduced after an upgrade from version 16.0 to 17.0.

for more detail:  odoo/upgrade#6147

**opw-3983692**

**Current behavior before PR:**
 when migrating from 16.0 to 17.0, getting validation error on changing the state of maintenance request
![image](https://github.com/odoo/odoo/assets/145324071/5af78939-933e-41a6-8ab5-f4ba5f69984d)


**Desired behavior after PR is merged:**
able to change the state of maintenance request
![image](https://github.com/odoo/odoo/assets/145324071/e72de3f3-6787-4761-9151-3f7f2fdbd78b)


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

Forward-Port-Of: odoo/odoo#169169

With restriction imposed by Colombian EDI, the PoS is not 100% compatible and usable as such features are not adapted for such restrictions. --- Description of the issue this commit addresses: When trying to issue a credit note via the POS (refund with invoice) and the colombian EDI module is installed, a traceback shows up as it is required to have a description code on the the credit note invoice but nothing in the UI makes it possible to add such data. --- Steps to reproduce:

With restriction imposed by Colombian EDI, the PoS is not 100% compatible and usable as such features are not adapted for such restrictions.

---

Description of the issue this commit addresses:

When trying to issue a credit note via the POS (refund with invoice) and the colombian EDI module is installed, a traceback shows up as it is required to have a description code on the the credit note invoice but nothing in the UI makes it possible to add such data.

---

Steps to reproduce:

1-Install l10n_co_pos and l10n_co_edi
2-Setup all the fun stuff for the edi to work (credentials, VAT, journals, ...) 3-Go in the POS and post an order
4-Now refund that order and make sure to make an invoice with that refund, post 5-An error message shows up to inform that some data is missing.

---

Desired behavior after the commit is merged:

This commit makes it so that when a credit note is created from the PoS, if it is linked to Colombia, the description code is set to 1 if no code is already set.

---

Note on the fix:

It is currently not possible to already have a description code when the invoice is created so the default could be replaced by an assignation but I figured that if we add the possibility in the future, it would be great not to override it.

---

task-3977188

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

Forward-Port-Of: odoo/odoo#170867
Forward-Port-Of: odoo/odoo#170739

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#170459

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#170459

This data is possible to be modified by users. Marking it as noupdate also avoids possible errors during upgrades, as if some values get updated (eg: product.product.type) it can [trigger validation errors](https://github.com/odoo/odoo/blob/16.0/addons/stock/models/product.py#L890). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169623

This data is possible to be modified by users.
Marking it as noupdate also avoids possible errors during upgrades, as if some values get updated (eg: product.product.type) it can [trigger validation errors](https://github.com/odoo/odoo/blob/16.0/addons/stock/models/product.py#L890).




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

Forward-Port-Of: odoo/odoo#169623

Before this commit, when is_gcc_country was false, a colon followed by a number would appear in the receipt, which was confusing. This commit removes this misleading information for receipts in non-GCC countries. opw-3992612 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170620

Before this commit, when is_gcc_country was false, a colon followed by a number would appear in the receipt, which was confusing. This commit removes this misleading information for receipts in non-GCC countries.

opw-3992612

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

Forward-Port-Of: odoo/odoo#170620

Duplicate emails were being sent out to employees because employees were being searched from user ids for each company, but each search was not filtered by the company. So if there was a user that had multiple employee records, all of their employee records on every company would be pulled up for every company on their database that had timesheet notifications on. For example if there were 4 companies and the employee had an employee record for each of them they would receive 16 emails in total.

Duplicate emails were being sent out to employees because employees were being searched from user ids for each company, but each search was not filtered by the company. So if there was a user that had multiple employee records, all of their employee records on every company would be pulled up for every company on their database that had timesheet notifications on. For example if there were 4 companies and the employee had an employee record for each of them they would receive 16 emails in total. 4 for each employee record.

Adding to the search domain to only look for employees on the current company defined by the for loop avoids these duplicate emails. This is similar to a fix that was done on the manager notification emails here: https://github.com/odoo/enterprise/pull/52808

opw-3748426

Forward-Port-Of: odoo/enterprise#64291

With an MX company Enable QR on POS ticket receipt Open POS session Make 2 orders without customer or invoice (save qr of a receipt) Close POS Session Go to Orders, select the 2 orders Click Actions > Create Global Invoice (After a few days) Open QR link and validate invoice Issue: Credit note CFDI validation will fail In this flow the system first issue a global invoice, then when a customer ask the invoice a credit note for the global invoice needs to be generated with the new invoi

With an MX company
Enable QR on POS ticket receipt
Open POS session
Make 2 orders without customer or invoice (save qr of a receipt) Close POS Session
Go to Orders, select the 2 orders
Click Actions > Create Global Invoice
(After a few days)
Open QR link and validate invoice

Issue: Credit note CFDI validation will fail
In this flow the system first issue a global invoice, then when a customer ask the invoice a credit note for the global invoice needs to be generated with the new invoice.
Currently the system uses the original pos order date as credit note date and this will fail validation if the order has been created before 72 hours ago

Forward-Port-Of: odoo/enterprise#65451

Methods from l10n_cl_edi are being moved to l10n_cl as part of https://github.com/odoo/odoo/pull/133695. This includes _l10n_cl_get_amounts and _float_repr_float_round on the account move model, as well as the method _l10n_cl_get_line_amounts on the account move line model. They can therefore be removed in this commit. The VAT section for the electronic ticket document is also being transferred in the same manner, and can thus be removed in the template here. This will allow to show the PD

Methods from l10n_cl_edi are being moved to l10n_cl as part of https://github.com/odoo/odoo/pull/133695. This includes _l10n_cl_get_amounts and _float_repr_float_round on the account move model, as well as the method _l10n_cl_get_line_amounts on the account move line model. They can therefore be removed in this commit.

The VAT section for the electronic ticket document is also being transferred in the same manner, and can thus be removed in the template here.

This will allow to show the PDFs of invoices generated in other currency in a correct way.

X-original-commit: 135a9bee298fe77217548d2fe86ae2558878e5b7 (cherry picked from commit 6ac7ebd00f0e63d4927e05f85ee45b96c7def4e3)

Forward-Port-Of: odoo/enterprise#61796
Forward-Port-Of: odoo/enterprise#60890

The issue: Our code generally assumes that strings are uppercase, which is typically true. However, in some cases, such as the one described in this ticket, the input string is only capitalized (the first character in uppercase). The Fix: convert the keys to uppercase before retrieving their values from the array, and use the get method instead of the bracket notation for safer access. opw-3979945 Forward-Port-Of: odoo/enterprise#64887

The issue:
Our code generally assumes that strings are uppercase, which is typically true. However, in some cases, such as the one described in this ticket, the input string is only capitalized (the first character in uppercase).

The Fix:
convert the keys to uppercase before retrieving their values from the array, and use the get method instead of the bracket notation for safer access.

opw-3979945

Forward-Port-Of: odoo/enterprise#64887

Steps to reproduce: ------------------- - Install `Documents` and `Inventory` (for test purpose) modules - Go to Settings and enable `Centralize files attached to products` - Go to Inventory > Products > Choose any product - Add an attachment to the Product - Go to Documents, then select the `Products` workspace - Select document related to product just uploaded - `Replace` the attachment with a new one (old one should be added to `History`) Issue: ------ The new attachment, and

Steps to reproduce:
-------------------

- Install `Documents` and `Inventory` (for test purpose) modules
- Go to Settings and enable `Centralize files attached to products`
- Go to Inventory > Products > Choose any product
- Add an attachment to the Product
- Go to Documents, then select the `Products` workspace
- Select document related to product just uploaded
- `Replace` the attachment with a new one (old one should be added to `History`)

Issue:
------

The new attachment, and therefore the document, is not related to the product anymore.

Cause:
------

When uploading a new attachment, we link the attachment to the document, and we don't keep the related record.

Solution:
---------

Keep the related record on the new attachment and remove it from the old attachment to not have all versions of the attachments displayed on the attachments of the products.

opw-3932497

Forward-Port-Of: odoo/enterprise#64530

Forward-Port-Of: odoo/enterprise#65413

Forward-Port-Of: odoo/enterprise#65413

Prior to this PR, the padding (introduced in commit b857e39666a1f3decf67aab48c3629f2d9723d17) of `o_form_nosheet` was triggered globally if barcode was installed. It causes issues in other places (like `account_accountant` reconciliation). task-3951200 --- | Before | After | |--------|--------| |  | ![Capture d’écran 2024-06-10 à 08 48 48](https://github.

Prior to this PR, the padding (introduced in commit b857e39666a1f3decf67aab48c3629f2d9723d17) of `o_form_nosheet` was triggered globally if barcode was installed.
It causes issues in other places (like `account_accountant` reconciliation).

task-3951200

---
| Before | After |
|--------|--------|
| ![Capture d’écran 2024-06-10 à 08 49 00](https://github.com/odoo/enterprise/assets/80679690/e3e26452-59d4-4630-a016-4f98d0ab6000) | ![Capture d’écran 2024-06-10 à 08 48 48](https://github.com/odoo/enterprise/assets/80679690/45430e47-a154-4982-a148-4fed32c7f034) |

Forward-Port-Of: odoo/enterprise#63271

**Steps to reproduce:** - Install Accounting, Sales and account_avatax_sale - Configure AvaTax in Accounting settings - Create a product with an AvaTax Category (e.g. [D00000000] Digital goods) - Create a SO: * Customer: [US customer] (e.g. Azure Interior) * Product: [the created product] * Unit Price: [any] (e.g. $ 200.00) * Fiscal Position (Other Info tab): Automatic Tax Mapping (AvaTax) - Confirm the SO => The taxes will be recomputed with AvaTax (e.g. $ 20.50) - Create a d

**Steps to reproduce:**
- Install Accounting, Sales and account_avatax_sale
- Configure AvaTax in Accounting settings
- Create a product with an AvaTax Category (e.g. [D00000000] Digital goods)
- Create a SO:
  * Customer: [US customer] (e.g. Azure Interior)
  * Product: [the created product]
  * Unit Price: [any] (e.g. $ 200.00)
  * Fiscal Position (Other Info tab): Automatic Tax Mapping (AvaTax)
- Confirm the SO => The taxes will be recomputed with AvaTax (e.g.  $ 20.50)
- Create a down payment from SO (via "Create Invoice" button):
  * Create Invoice: Down payment (percentage)
  * Down Payment Amount: 50%

**Issues:**
1) There is no tax on the down payment
2) When confirming the down payment, AvaTax taxes are computed from the Down payment product.
It should not because the Down payment product may have a different AvaTax category than the product on the SO, which may lead to different computed taxes.
The taxes on the down payment should be the same than the ones on the SO.

**Cause:**
1) In "sale_external_tax" module, the "tax_ids" field is removed when preparing the invoice line (in "_prepare_invoice_line" method). Even though "account_avatax_sale" module depends on "sale_external_tax", we want to keep "tax_ids" when using AvaTax.

**Solution:**
1) Create a method checking if taxes should be removed in "sale_external_tax" and override it in "account_avatax_sale" module to keep them.
2) Exclude down payments from external taxes recomputation.

opw-3971513

Forward-Port-Of: odoo/enterprise#64900

When exporting tax report to xml, a comment tag is added in the xml even when empty or set to False. Per https://finances.belgium.be/fr/E-services/Intervat/comment-utiliser-intervat/deposer-declaration-periodique#q5 tags cannot be empty Steps to reproduce: 1.In a belgian company > accounting > Reporting > Tax Report 2.Export in xml 3.Do not fill information in the pop up > Export XML 4.Notice how the <comment> tag is present yet empty cause: comment is being added to the xml format

When exporting tax report to xml, a comment tag is added in the xml even when empty or set to False. 
Per https://finances.belgium.be/fr/E-services/Intervat/comment-utiliser-intervat/deposer-declaration-periodique#q5
tags cannot be empty

Steps to reproduce:
1.In a belgian company > accounting > Reporting > Tax Report
2.Export in xml
3.Do not fill information in the pop up > Export XML
4.Notice how the <comment> tag is present yet empty

cause:
comment is being added to the xml formatting even when empty

Solution:
add comment when not empty

opw-3980954

Forward-Port-Of: odoo/enterprise#64798