In the xml we sent, we have to specify the unit code, there is mapping for that on the documentation: https://developer.nilvera.com/en/code-lists#birim-kodlari This commit will extend what has been done in the base edi module with the UOM_TO_UNECE_CODE dictionary. We added some new unit of measure and each unit of measure will be linked to a code. The default value is C62. task-4457115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forw

In the xml we sent, we have to specify the unit code, there is mapping for that on the documentation: https://developer.nilvera.com/en/code-lists#birim-kodlari

This commit will extend what has been done in the base edi module with the UOM_TO_UNECE_CODE dictionary. We added some new unit of measure and each unit of measure will be linked to a code.
The default value is C62.

task-4457115




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

Forward-Port-Of: odoo/odoo#193030

Description of the issue/feature this PR addresses: This PR is to avoid making unnecessary format validations on manual documents, as well as to improve the error message shown when the validation is done and the user had entered an invalid document number. A use case for these changes is when the user wants to register an invoice from a foreign supplier that does not have the Uruguayan format, and at the moment of filling the “Document Number” field, an error message appears saying that it do

Description of the issue/feature this PR addresses:
This PR is to avoid making unnecessary format validations on manual documents, as well as to improve the error message shown when the validation is done and the user had entered an invalid document number.
A use case for these changes is when the user wants to register an invoice from a foreign supplier that does not have the Uruguayan format, and at the moment of filling the “Document Number” field, an error message appears saying that it does not comply with the Uruguayan number validations.

Current behavior before PR:
Either electronic or manual document numbers format were validated against the electronic documents format.

Desired behavior after PR is merged:
Only electronic document numbers are validated to check if they have the proper format.

Steps to reproduce the error:
1) Install l10n_uy
2) Create an invoice using a manual journal.
3) Set a random document number (for example '1234')
4) Check that a pop up is raised, saying that the format is invalid.

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

Forward-Port-Of: odoo/odoo#198216

When viewing sale report for POS orders, the gross weight number will be off by a factor of how much larger/smaller the UOM ratio is compared to the base. For example, if we sell 1 qty of product with a weight of 25kg and a UOM of 25kg (25 * 1kg), the gross weight field will be 1 * 25kg * 25kg or 625kg instead of the expected 1 * 25kg or 25kg. This fix removes the UOM factor from being taken into account when calculating gross weight for POS orders. This is a valid solution because if we

When viewing sale report for POS orders, the gross weight number will
be off by a factor of how much larger/smaller the UOM ratio is
compared to the base. For example, if we sell 1 qty of product with a
weight of 25kg and a UOM of 25kg (25 * 1kg), the gross weight field
will be 1 * 25kg * 25kg or 625kg instead of the expected 1 * 25kg or
25kg. This fix removes the UOM factor from being taken into account
when calculating gross weight for POS orders. This is a valid solution
because if we treat 'SUM(p.weight * l.product_uom_qty / u.factor *
u2.factor)' as the ground truth from sale report for sale orders, the
'/ u.factor * u2.factor' portion of the calculation will cancel out
to 1 for POS orders. This is because the only time 'u2.factor/u.factor'
is not 1 for sale orders is when the product template's UOM factor is
different from the sale order line's UOM factor. Since we can not
change the UOM of pos order lines, the pos order line's factor will
always be the same as the product template's therefore
'u2.factor / u.factor' for pos orders will always be 1 and can be
ignored.

To reproduce error on blank DB:
1) For a product, change its UOM to a UOM with a ratio not equal to 1
2) For the same product, change its weight in the inventory tab to
a number not equal to 0
3) In POS make a sale with this product and confirm the order
4) Check the gross weight of the product just sold through POS by
going to sales->reporting->list view and adding gross weight to the
view through studio

opw-4452892

Forward-Port-Of: odoo/odoo#203849
Forward-Port-Of: odoo/odoo#203144

Added condition on check that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the app

Added condition on check that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable.

Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users.

opw-3841495

Forward-Port-Of: odoo/odoo#204350
Forward-Port-Of: odoo/odoo#178142

Steps to reproduce: - Activate developer mode - Install website Google Maps module - Navigate to Website in edit mode - Drop the google maps snippet - Enter a correct API key - The dialog closes but the snippet is removed This is due to a promise not resolved when confirming the API key. Forward-Port-Of: odoo/odoo#204139

Steps to reproduce:

- Activate developer mode
- Install website Google Maps module
- Navigate to Website in edit mode
- Drop the google maps snippet
- Enter a correct API key
- The dialog closes but the snippet is removed

This is due to a promise not resolved when confirming the API key.

Forward-Port-Of: odoo/odoo#204139

**Problem**: File boxes contain elements with `contenteditable=true`. Once saved, portal users can edit them even when the editor is disabled. **Solution**: Use the new mechanism introduced in [69fb021](https://github.com/odoo/odoo/pull/201139/commits/69fb0216dee2bbea407ca6f3c3ef9f1cc71a2f6b), by adding `o-contenteditable-true` and `o-contenteditable-false` classes to file banners. **Steps to reproduce**: 1. Navigate to **Sales > Product**. 2. Open any product. 3. In the **Sales** ta

**Problem**:
File boxes contain elements with `contenteditable=true`. Once saved, portal users can edit them even when the editor is disabled.

**Solution**:
Use the new mechanism introduced in
[69fb021](https://github.com/odoo/odoo/pull/201139/commits/69fb0216dee2bbea407ca6f3c3ef9f1cc71a2f6b), by adding `o-contenteditable-true` and `o-contenteditable-false` classes to file banners.

**Steps to reproduce**:
1. Navigate to **Sales > Product**.
2. Open any product.
3. In the **Sales** tab, add a **banner** to "Ecommerce Description".
4. Save and click **Go to Website**.
   - **Issue**: The banner remains editable, even when the editor is disabled.

**opw-4597744**

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

Forward-Port-Of: odoo/odoo#204750

**Problem**: If the selection does not include unsplittable nodes but the `commonAncestorContainer` contains one, the AI/Translation button will be disabled. **Solution**: Instead of relying on `commonAncestorContainer`, check only the traversed nodes to determine if the selection is valid. **Steps to reproduce**: 1. Open Full Composer with a signature. 2. Add text. 3. Select only the text you added. - **Issue**: The AI/Translation button is disabled. **opw-4649819** --- I

**Problem**:
If the selection does not include unsplittable nodes but the `commonAncestorContainer` contains one, the AI/Translation button will be disabled.

**Solution**:
Instead of relying on `commonAncestorContainer`, check only the traversed nodes to determine if the selection is valid.

**Steps to reproduce**:
1. Open Full Composer with a signature.
2. Add text.
3. Select only the text you added.
   - **Issue**: The AI/Translation button is disabled.

**opw-4649819**

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

Forward-Port-Of: odoo/odoo#204628

**Problem**: Commit [f523cb8](https://github.com/odoo/odoo/commit/f523cb85174687856d2c93fbc3c2f52a307f6761) did not properly handle background images, leading to issues when retrieving the correct attachment source. **Solution**: Use `el.dataset.bgSrc` to get the correct attachment source for background images. **Steps to reproduce**: 1. Add a "Banner" block. 2. Update the image. 3. Save. - **Issue**: image lost. **opw-4686236** --- I confirm I have signed the CLA and read

**Problem**:
Commit [f523cb8](https://github.com/odoo/odoo/commit/f523cb85174687856d2c93fbc3c2f52a307f6761) did not properly handle background images, leading to issues when retrieving the correct attachment source.

**Solution**:
Use `el.dataset.bgSrc` to get the correct attachment source for background images.

**Steps to reproduce**:
1. Add a "Banner" block.
2. Update the image.
3. Save.
   - **Issue**: image lost.

**opw-4686236**

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

Forward-Port-Of: odoo/odoo#204812
Forward-Port-Of: odoo/odoo#204662

**Current behavior before PR:** - When clicking on a dynamic field, both the qweb overlay and the toolbar would appear simultaneously, causing an overlap. **Desired behavior after PR is merged:** - The qweb overlay will now only be shown when the selection is collapsed, ensuring that it does not overlap with the toolbar when it is visible. task:4243987 Forward-Port-Of: odoo/odoo#195436

**Current behavior before PR:**

- When clicking on a dynamic field, both the qweb overlay and the toolbar would appear simultaneously, causing an overlap.

**Desired behavior after PR is merged:**

- The qweb overlay will now only be shown when the selection is collapsed, ensuring that it does not overlap with the toolbar when it is visible.

task:4243987

Forward-Port-Of: odoo/odoo#195436

Since `purchase_price` depends on their `move_ids.picking_id.state`, we risk overwriting manual edits to the field at various points in an ordinary processing of a sale, here specifically during order confirmation. Prior to commit: e24d922 standard cost method product lines would not have their `purchase_price` recomputed, while non-standard product would (meaning manual edits will only be saved for standard cost lines). This is a partial revert of that commit to bring back the beha

Since `purchase_price` depends on their
`move_ids.picking_id.state`, we risk overwriting manual edits to
the field at various points in an ordinary processing of a sale,
here specifically during order confirmation.

Prior to commit: e24d922 standard cost method product lines
would not have their `purchase_price` recomputed, while
non-standard product would (meaning manual edits will only be
saved for standard cost lines).

This is a partial revert of that commit to bring back the
behavior of non recomputed standard cost lines' `purchase_price`

Additionally, we re-fix the use-case from the aforementioned
commit by allowing `purchase_price` recomputation (and
overwrites) when a line has no product qty but does have
delivered qty (indicating it was added from the delivery rather
than directly on the sale order itself.

Forward-Port-Of: odoo/odoo#202854

Steps to reproduce ================== - Go to the project app - Open any project - zoom / dezoom a few times => At some point, the top border on the first kanban card will disappear. Cause of the issue ================== This is due to a negative margin on the bottom of kanban cards. This is made in order to have no duplicated border between cards. Solution ======== We can set a top margin for the first card. opw-4668595 Forward-Port-Of: odoo/odoo#204567

Steps to reproduce
==================

- Go to the project app
- Open any project
- zoom / dezoom a few times => At some point, the top border on the first kanban card will
   disappear.

Cause of the issue
==================

This is due to a negative margin on the bottom of kanban cards. This is made in order to have no duplicated border between cards.

Solution
========

We can set a top margin for the first card.

opw-4668595

Forward-Port-Of: odoo/odoo#204567

Steps to reproduce ================== - Use a mobile viewport - Go to any list/kanban view - Open a record - Use the pager to switch to the next record => "1 / x" is displayed where x is the total amount of records - Click next => "2 / x" is displayed - Click previous => "3 / x" is displayed The pager is displaying the values before the switch has been made. Cause of the issue ================== When sending `this.value` on the `PAGER_UPDATED_EVENT` bus, the props have not bee

Steps to reproduce
==================

- Use a mobile viewport
- Go to any list/kanban view
- Open a record
- Use the pager to switch to the next record => "1 / x" is displayed where x is the total amount of records
- Click next => "2 / x" is displayed
- Click previous => "3 / x" is displayed

The pager is displaying the values before the switch has been made.

Cause of the issue
==================

When sending `this.value` on the `PAGER_UPDATED_EVENT` bus, the props have not been updated yet. This means that we send the previous value.

Solution
========

We send the event once either the offset, limit or total props have been
updated.

opw-4666878

Forward-Port-Of: odoo/odoo#204168

Steps to reproduce the issue: - Enter Website edit mode. - Click on the "Theme" tab. - Pick a black color for the website background (4th color button). - Click on a link in the website navbar to make the link popover appear. - Bug: The popover background is black, and its buttons are not visible as they are also black. Bug introduced by this commit [1], where popover colors were updated to match the website's theme. The goal was to align popovers, such as the one for the e-commerce ca

Steps to reproduce the issue:

- Enter Website edit mode.
- Click on the "Theme" tab.
- Pick a black color for the website background (4th color button).
- Click on a link in the website navbar to make the link popover appear.
- Bug: The popover background is black, and its buttons are not visible as they are also black.

Bug introduced by this commit [1], where popover colors were updated to match the website's theme. The goal was to align popovers, such as the one for the e-commerce cart button, with the theme colors. However, the change unfortunately also affected the link editing popover, which should remain neutral as it is part of the interface elements.

[1]: https://github.com/odoo/odoo/commit/0d96be06faf8aad1a92183bd2b6371253980c7e6

task-4422810

| Before  | After |
| ------------- | ------------- |
| ![image](https://github.com/user-attachments/assets/a217c886-9521-4347-a0db-7d6cd7b6029b)  | ![image](https://github.com/user-attachments/assets/f06e4618-e896-430c-8063-bbe3dd534055)  |

Forward-Port-Of: odoo/odoo#203958

**Steps to reproduce:** - Install Contacts, Accounting and l10n_be - Switch to a Belgian company (e.g. BE Company CoA) - In Accounting settings, activate "SEPA Direct Debit (SDD)" - Create a contact: * Country: Belgium * Bank Account: [a Belgian IBAN] - Go to "Accounting / Customers / Direct Debit Mandates" - Create a mandate for the created contact - Validate the mandate - Create an invoice for the created contact as customer - Confirm the invoice - Pay the invoice with "SEPA Di

**Steps to reproduce:**
- Install Contacts, Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings, activate "SEPA Direct Debit (SDD)"
- Create a contact:
  * Country: Belgium
  * Bank Account: [a Belgian IBAN]
- Go to "Accounting / Customers / Direct Debit Mandates"
- Create a mandate for the created contact
- Validate the mandate
- Create an invoice for the created contact as customer
- Confirm the invoice
- Pay the invoice with "SEPA Direct Debit"
- Print the invoice

**Issue:**
The information explaining that the invoice has been paid using direct debit and that the invoice should not be paid manually is not printed on the invoice.

**Cause:**
This information is printed if "sdd_mandate_id" field of the invoice is set.
"sdd_mandate_id" is a related field to "origin_payment_id.sdd_mandate_id" field.
However, since the refactoring on "account.payment", "origin_payment_id" is not set on an invoice anymore.
It is just set on the journal entry linked to a payment.
Therefore, we cannot rely on that field anymore to print the SDD mandate payment information.

**Solution:**
The "matched_payment_ids" field can be used instead.
It's a Many2many field referring all payments linked to the invoice.
If one of these payments has "sdd_mandate_id" set, the SDD mandate payment information is printed on the invoice.

opw-4672191

Forward-Port-Of: odoo/enterprise#82823

This is more an UX problem rather than a bug. In the reconciliation tool, when you reconciled all the transactions of the current filter, rainbow mans appears. Then, all the background behind the rainbow overlay is disabled, you can no longer edit the filters in the search for instance, and the only buttons available become "All transactions" and "Back to dashboard". Both buttons will make you loose your search filters: - You loose the "Not Matched" filter which is set automatically when

This is more an UX problem rather than a bug.

In the reconciliation tool, when you reconciled all the transactions of the current filter, rainbow mans appears.

Then, all the background behind the rainbow overlay is disabled, you can no longer edit the filters in the search for instance, and the only buttons available become "All transactions" and "Back to dashboard". Both buttons will make you loose your search filters:
- You loose the "Not Matched" filter which is set automatically when you hit the "x to reconcile" button in the accounting dashboard, and hence you see the already reconciled transactions, while you were actually interested only in the non-reconciled transactions
- If you made a complicated filter, you loose them all and you are good to redo them all.

This revision offers the possibility to have the background behind the rainbow overlay clickable, so you would be able to change the filters, for instance only the last filter, in order to continue your reconciliation where you were, instead of being completely reset.

Before:


https://github.com/user-attachments/assets/4ed7cf41-1fa0-4efe-92a0-171011b4713a


After:

https://github.com/user-attachments/assets/e4f2d580-9dca-4331-9e66-89efeb00edef

Forward-Port-Of: odoo/enterprise#82562

Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this

Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable.

Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users.

This change adds the necessary override in enterprise. See change in community here: https://github.com/odoo/odoo/pull/178142

opw-3841495

Forward-Port-Of: odoo/enterprise#82691
Forward-Port-Of: odoo/enterprise#69036

Description ------------ Fix a performance issue in the partner search functionality used in the sharing widget. The problem was related to the PostgreSQL query planner choosing a suboptimal execution plan when using a limit of 4 records. With a very low limit of 4, PostgreSQL would choose to perform an index scan on the `complete_name` index instead of using the more efficient trigram indexes. This resulted in high I/O operations as it traversed the index from A until finding matches, caus

Description
------------
Fix a performance issue in the partner search functionality used in the sharing widget. The problem was related to the PostgreSQL query planner choosing a suboptimal execution plan when using a limit of 4 records.

With a very low limit of 4, PostgreSQL would choose to perform an index scan on the `complete_name` index instead of using the more efficient trigram indexes. This resulted in high I/O operations as it traversed the index from A until finding matches, causing significant performance degradation.

The fix simply increases the limit to 8, consistent with other `name_search` operations, ensuring the query planner consistently chooses the trigram index path regardless of the search term.

Benchmark
----------
On a database with over 8 digits count of partners, a non selective search of a partner (5 chars) took:

| Before | After | Speedup |
|--------|-------|---------|
| 27.4s  | 42ms  | 652x    |

Reference
---------
task-4686893

Forward-Port-Of: odoo/enterprise#82680

Fixing the tour that has been introduce here https://github.com/odoo/enterprise/pull/75658/commits/c2d18cea5db278b5a3203c4d3646411fc9bbd450 runbot-110627 Forward-Port-Of: odoo/enterprise#81776

Fixing the tour that has been introduce here https://github.com/odoo/enterprise/pull/75658/commits/c2d18cea5db278b5a3203c4d3646411fc9bbd450

runbot-110627

Forward-Port-Of: odoo/enterprise#81776