Before this commit, creating bills through uploading XMLs with alphabetic codes in SchemeID was causing an error. This happened because these codes were not allowed in partner peppol_eas selection field. This commit adds these alphabetic codes as indicated in this reference sheet: https://ec.europa.eu/digital-building-blocks/sites/download/attachments/467108974/Electronic%20Address%20Scheme%20Code%20list%20-%20version%205%20-%20published.xlsx?version=1&modificationDate=1639417211464&api=v2

Before this commit, creating bills through uploading XMLs with alphabetic codes in SchemeID was causing an error.
This happened because these codes were not allowed in partner peppol_eas selection field.
This commit adds these alphabetic codes as indicated in this reference sheet:
https://ec.europa.eu/digital-building-blocks/sites/download/attachments/467108974/Electronic%20Address%20Scheme%20Code%20list%20-%20version%205%20-%20published.xlsx?version=1&modificationDate=1639417211464&api=v2

task-4823915




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

Forward-Port-Of: odoo/odoo#213109
Forward-Port-Of: odoo/odoo#212114

If allowExpressions = false, the domain field is supposed to detect when expressions are used in the domain and notify the user that the domain is invalid. The current version of domainContainsExpressions do not allow detection of expressions in sub domains used in conjunction with the any operator. We fix that. Forward-Port-Of: odoo/odoo#212957

If allowExpressions = false, the domain field is supposed to detect when expressions are used in the domain and notify the user that the domain is invalid. The current version of domainContainsExpressions do not allow detection of expressions in sub domains used in conjunction with the any operator. We fix that.

Forward-Port-Of: odoo/odoo#212957

Currently in MX localization we allow updating existing bills when users upload a CFDI XML [1] However, we might change the bill source PO with a wrong one in case we have similar records Steps to reproduce: - With an MX Company setup - Create a PO [PO1] with [Partner] and a line and confirm it - Create an identical PO [PO2], confirm it, receive and create bill (Note: the bill is currently associated with PO2) - In the bill upload the corresponding xml bill Issue: After uploading the

Currently in MX localization we allow updating existing bills when users upload a CFDI XML [1]
However, we might change the bill source PO with a wrong one in case we have similar records

Steps to reproduce:
- With an MX Company setup
- Create a PO [PO1] with [Partner] and a line and confirm it
- Create an identical PO [PO2], confirm it, receive and create bill (Note: the bill is currently associated with PO2)
- In the bill upload the corresponding xml bill

Issue: After uploading the document, the bill will be associated to PO1

This occurs because in case of CFDI xml bills we process the attachment and update the bill even if some lines already exists. The system tries to find a PO not yet invoiced to associate with the bill, and finds PO1 which is identical to PO2 but not invoiced yet

A solution would be to avoid changing the source purchase order when we want to just extend the bill with an attachment

[1] https://github.com/odoo/odoo/commit/e05457c51e7a03115ba37a196e88a199b7682501

opw-4521106

Forward-Port-Of: odoo/odoo#212568
Forward-Port-Of: odoo/odoo#211252

Context: Migration keys in the context of Peppol are keys that are used to transfer a Peppol participant from one SMP (a service provider by simplification, like Odoo) to another. Problem: The error fixed in this commit is raised when we detect the Peppol Identification/Peppol Address is already on the Peppol Network. It mentions the migration key while it can also be raised when the identification is already used on our own SMP, which makes the migration mention irrelevant and confusing.

Context: Migration keys in the context of Peppol are keys that are used to transfer a Peppol participant from one SMP (a service provider by simplification, like Odoo) to another.

Problem: The error fixed in this commit is raised when we detect the Peppol Identification/Peppol Address is already on the Peppol Network. It mentions the migration key while it can also be raised when the identification is already used on our own SMP, which makes the migration mention irrelevant and confusing.

Moreover, migration keys are actually handled by very few provider. Generally, the way to go is to unregister from the SMP you want to leave, to be able to register on a new one.

task-no

Forward-Port-Of: odoo/odoo#212966
Forward-Port-Of: odoo/odoo#212706

Steps to reproduce: ------------------- 1. Create an event with a gloabl question, by checking the box "ask once per order", and mark it as mandatory. 2. In PoS, buy one ticket for this event, and leave this mandatory question unanswere. Observe the we're not blocked, we were able to keep the mandatory answer blank! Reason: ------- We are only validating that the mandatory questions on the registation level are valid, but not those on on the order level. Fix: ---- We do the same

Steps to reproduce:
-------------------
1. Create an event with a gloabl question, by checking the box "ask once per order", and mark it as mandatory.
2. In PoS, buy one ticket for this event, and leave this mandatory question unanswere.

Observe the we're not blocked, we were able to keep the mandatory answer blank!

Reason:
-------
We are only validating that the mandatory questions on the registation level are valid, but not those on on the order level.

Fix:
----
We do the same check for the global questions too.

opw-4793837

Forward-Port-Of: odoo/odoo#213039
Forward-Port-Of: odoo/odoo#211089

In the partner bank account selection, it was not possible to order accounts. This is a crucial feature because the first account was used by default in many parts of odoo. This commit solves this issue by adding access to banks list view, where the user can change banks as desired. task-4830220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212546

In the partner bank account selection, it was not possible to order accounts.
This is a crucial feature because the first account was used by default in many parts of odoo.
This commit solves this issue by adding access to banks list view, where the user can change banks as desired.

task-4830220




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

Forward-Port-Of: odoo/odoo#212546

Currently, when you try to settle a SO in POS which has sections/notes before the product line (producted tracked), a traceback will appear and the amount to settle will be set to 0. Steps to reproduce: ------------------- * Crete a product tracked by SN * Create a SO, the first line should be a section line and the second the product newly created * Open pos session * Try to settle the SO > Observation: Traceback, when closing the traceback, the line on the pos order has an amount of

Currently, when you try to settle a SO in POS which has sections/notes before the product line (producted tracked), a traceback will appear and the amount to settle will be set to 0.

Steps to reproduce:
-------------------
* Crete a product tracked by SN
* Create a SO, the first line should be a section line and the second the product newly created
* Open pos session
* Try to settle the SO
> Observation: Traceback, when closing the traceback, the line on the
pos order has an amount of 0.

Why the fix:
------------
This commit https://github.com/odoo/odoo/commit/4c0fdfe23c6302929bf05f2223f41b7ac5587e66 didn't take into account that `read_converted` could potentially return less data than the number of sale order lines (sections and notes).

Thus using a loop invariant to track the converted_line related to the SO line does not make sense. In our example above, `i=1` when reaching the product line but `converted_lines` only had one element. In this case, `sale_order.order_line[1]` is related to `converted_lines[0]`.

opw-4800339

Forward-Port-Of: odoo/odoo#212805
Forward-Port-Of: odoo/odoo#212494

If the selection property of a parent record is NULL, and the record is exported and then re-imported, a TypeError occurs. This is resolved by returning an empty dictionary during import whenever the selection property's value is NULL in the parent record. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: opw-4670210 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr For

If the selection property of a parent record is NULL, and the record is exported and then re-imported, a TypeError occurs.

This is resolved by returning an empty dictionary during import whenever the selection property's value is NULL in the parent record.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:


opw-4670210

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

Forward-Port-Of: odoo/odoo#212940
Forward-Port-Of: odoo/odoo#210690

Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during super.onWillStart. - Modified onWillStart to ensur

Steps to Reproduce:
- Open the Planning app.
- Click on the avatar of a resource.
- Refresh the page, then click on the avatar of a resource again.

Issue:
- A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete 
  loading.

Solution:
- Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction 
  during super.onWillStart.
- Modified onWillStart to ensure hr_access data is fetched without risking lifecycle conflicts.

task-4210513

Forward-Port-Of: odoo/odoo#207917
Forward-Port-Of: odoo/odoo#187171

Since expense reports removal (https://www.odoo.com/odoo/967/tasks/4481615), expenses paid by employee and made in foreign currency are posted using the expense currency instead of the company currency. This is an unwanted behavior. It makes sense for company paid expenses because payments are created: Having the same currency as the one used in the transaction is easier for the reconciliation. It's however unusual to keep the transaction currency for vendor bills representing debts towards th

Since expense reports removal
(https://www.odoo.com/odoo/967/tasks/4481615), expenses paid by employee and made in foreign currency are posted using the expense currency instead of the company currency.
This is an unwanted behavior. It makes sense for company paid expenses because payments are created: Having the same currency as the one used in the transaction is easier for the reconciliation. It's however unusual to keep the transaction currency for vendor bills representing debts towards the employees. In vast majority of cases employees are indeed reimbursed in company currency.

task-4708953

Forward-Port-Of: odoo/odoo#205970

*l10n_es_edi_sii,l10n_es_edi_tbai,l10n_es_edi_tbai_multi_refund Related to https://github.com/odoo/enterprise/pull/85966 Forward-Port-Of: odoo/odoo#212949 Forward-Port-Of: odoo/odoo#210804

*l10n_es_edi_sii,l10n_es_edi_tbai,l10n_es_edi_tbai_multi_refund

Related to https://github.com/odoo/enterprise/pull/85966

Forward-Port-Of: odoo/odoo#212949
Forward-Port-Of: odoo/odoo#210804

It regularly happens that badly written automated actions have a negative impact on performances. Unfortunately, there little to no logging which would help the investigation. In other words, there is no clear log of which action is being executed. We improve the logging by recording which automated action is executed on how many records. This will give better clues to fix performance issues. Technical note: the `sudo()` is necessary since the automations are searched as superuser, b

It regularly happens that badly written automated actions have a
negative impact on performances. Unfortunately, there little to no
logging which would help the investigation. In other words, there is no
clear log of which action is being executed.

We improve the logging by recording which automated action is executed
on how many records. This will give better clues to fix performance
issues.

Technical note: the `sudo()` is necessary since the automations are
searched as superuser, but returned with the current user which might
not have a read access. Test [2] is failing is no `sudo()` is set.

[1] https://github.com/odoo/odoo/blob/6a244922b3fac8f3258726301373273d60871c27/addons/base_automation/models/base_automation.py#L608-L609
[2] https://github.com/odoo/odoo/blob/6a244922b3fac8f3258726301373273d60871c27/addons/base_automation/tests/test_automation.py#L75

Forward-Port-Of: odoo/odoo#212324

- Avoid traceback when using name-based preset without module `pos_restaurant` installed. - Since we cannot change the name of a floating order in POS, move floating order name logic to `pos_restaurant` to prevent errors when using presets with `identification = name` in POS without the `pos_restaurant` module installed. - Adapt tests so in `point_of_sale` we test preset with `identification = address` (delivery) and in `pos_restaurant` we test preset with `identification = name` (take out).

- Avoid traceback when using name-based preset without module `pos_restaurant` installed.
- Since we cannot change the name of a floating order in POS, move floating order name logic to `pos_restaurant` to prevent errors when using presets with `identification = name` in POS without the `pos_restaurant` module installed.
- Adapt tests so in `point_of_sale` we test preset with `identification = address` (delivery) and in `pos_restaurant` we test preset with `identification = name` (take out).

Steps to reproduce:
- Install `point_of_sale` (without `pos_restaurant`).
- Enable presets in settings and create a preset with `identification = name`.
- Open a session in POS and create a new order.
- Select the preset in the order.
- => Traceback occurs.

task-id: 4794324


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

Forward-Port-Of: odoo/odoo#211677
Forward-Port-Of: odoo/odoo#210053

Before this commit, when loading missing products, the corresponding pricelist rules were loaded but not saved in indexedDB. As a result, after a page refresh, the product would remain available but its pricelist information would be missing, leading to incorrect pricing. opw-4848511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212899

Before this commit, when loading missing products, the corresponding pricelist rules were loaded but not saved in indexedDB. As a result, after a page refresh, the product would remain available but its pricelist information would be missing, leading to incorrect pricing.

opw-4848511

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

Forward-Port-Of: odoo/odoo#212899

Before this commit, non-manager cashiers were unable to modify product prices even when price control was not enabled, which was not the intended behavior. Additionally, when `pos_hr` was not installed, the `get_cashier` method returned the user object with a `role` attribute. However, when `pos_hr` was installed, the returned cashier used `_role`, leading to inconsistencies and broken functionality depending on the module's presence. opw-4726098 --- I confirm I have signed the CLA and

Before this commit, non-manager cashiers were unable to modify product prices even when price control was not enabled, which was not the intended behavior.

Additionally, when `pos_hr` was not installed, the `get_cashier` method returned the user object with a `role` attribute. However, when `pos_hr` was installed, the returned cashier used `_role`, leading to inconsistencies and broken functionality depending on the module's presence.

opw-4726098

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

Forward-Port-Of: odoo/odoo#208194
Forward-Port-Of: odoo/odoo#206650

Before this commit, scanning the barcode of a product with attributes set to never creation type, but with only one option available, would still trigger the product configuration popup. opw-4754801 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210353 Forward-Port-Of: odoo/odoo#208272

Before this commit, scanning the barcode of a product with attributes set to never creation type, but with only one option available, would still trigger the product configuration popup.

opw-4754801

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

Forward-Port-Of: odoo/odoo#210353
Forward-Port-Of: odoo/odoo#208272

…followers **Description of the issue/feature this PR addresses:** Currently all followers without portal access are able to see the button, in the email notification, that redirects to the portal (to see the quotation or sale order). This may be confusing and misleading, as the button will redirect them to the login page of the portal, to which they do not have access. This PR leaves the followers group options as default (button access disabled for followers) which ensures that only port

…followers

**Description of the issue/feature this PR addresses:**

Currently all followers without portal access are able to see the button, in the email notification, that redirects to the portal (to see the quotation or sale order). This may be confusing and misleading, as the button will redirect them to the login page of the portal, to which they do not have access. This PR leaves the followers group options as default (button access disabled for followers) which ensures that only portal users have access.

**Current behavior before PR:**
The 'follower' group in _notify_get_recipients_groups is being explicitly marked with 'has_button_access': True. Therefore followers without portal access are having access to the button.

**Steps to reproduce:**

1. Configure odoo to be able to send out emails.
2. Install sale_management.
3. Create a sale order for a customer and add as follower another partner that has no portal access. This follower needs to have an email you have access to.
4. Send a message to the follower.
5. Test in the received email that the "View Quotation/Order" button is shown and when clicked, the user is redirected to the login page.

**Desired behavior after PR is merged:**
Only followers with portal access will have access to the button.

Note that followers with portal access are directly categorized as 'portal_customer', so that is why it would make sense to simply remove the code where the followers without portal access are given access to the button.





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

Forward-Port-Of: odoo/odoo#212647
Forward-Port-Of: odoo/odoo#208402

### Description of the issue/feature this PR addresses: Given https://github.com/odoo/odoo/blob/c494ca48eecab80e7310bf1c4ca1381d61f37f86/addons/base_import/models/base_import.py#L84-L90 Then `test_import_product_demo_xls` incorrectly pairs .xls file extension with mime type `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` ### Current behavior before PR: Tests in the product module fail when openpyxl is installed. ``` 2025-05-19 15:08:32,243 1 ERROR odoo odoo.a

### Description of the issue/feature this PR addresses:

Given
https://github.com/odoo/odoo/blob/c494ca48eecab80e7310bf1c4ca1381d61f37f86/addons/base_import/models/base_import.py#L84-L90

Then `test_import_product_demo_xls` incorrectly pairs .xls file extension with mime type `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet`

### Current behavior before PR:

Tests in the product module fail when openpyxl is installed.

```
2025-05-19 15:08:32,243 1 ERROR odoo odoo.addons.product.tests.test_import_files: FAIL: Subtest TestImportFiles.test_import_product_demo_xls [product.supplierinfo]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/addons/product/tests/test_import_files.py", line 35, in test_import_product_demo_xls
    self.assertIsNone(result.get("error"))
AssertionError: "Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet')." is not None
 
2025-05-19 15:08:32,268 1 WARNING odoo odoo.addons.base_import.models.base_import: Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'). 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/addons/base_import/models/base_import.py", line 429, in _read_file
    return getattr(self, '_read_' + file_extension)(options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/odoo/addons/base_import/models/base_import.py", line 509, in _read_xlsx
    book = load_workbook(io.BytesIO(self.file or b''), data_only=True)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 344, in load_workbook
    reader = ExcelReader(filename, read_only, keep_vba,
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 123, in __init__
    self.archive = _validate_archive(fn)
                   ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/openpyxl/reader/excel.py", line 95, in _validate_archive
    archive = ZipFile(filename, 'r')
              ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/zipfile/__init__.py", line 1349, in __init__
    self._RealGetContents()
  File "/usr/lib/python3.12/zipfile/__init__.py", line 1416, in _RealGetContents
    raise BadZipFile("File is not a zip file")
zipfile.BadZipFile: File is not a zip file
2025-05-19 15:08:32,269 1 ERROR odoo odoo.addons.product.tests.test_import_files: FAIL: Subtest TestImportFiles.test_import_product_demo_xls [product.template]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/addons/product/tests/test_import_files.py", line 35, in test_import_product_demo_xls
    self.assertIsNone(result.get("error"))
AssertionError: "Unable to read file '<unknown>' as 'xlsx' (decided from user-provided mimetype 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet')." is not None
```

### Desired behavior after PR is merged:

Tests pass even when openpyxl is installed.

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

Forward-Port-Of: odoo/odoo#210623

Scenario: - add an URL rewrite (308) of a route with only GET method (eg. test_website route /get rewritten to /get_new) - add a link in any website page to the original route (eg. /get) - open that page as public or user without website editing right Issue: an error 500 is shown instead of the page Cause: since the introduction of URL rewritting in be8fc2296b3822baffe0bc68cb4b7efdfe53fa91 the url_for method only worked for rewrite of route that had a POST method. In a GET method t

Scenario:
- add an URL rewrite (308) of a route with only GET method (eg.
  test_website route /get rewritten to /get_new)
- add a link in any website page to the original route (eg. /get)
- open that page as public or user without website editing right

Issue: an error 500 is shown instead of the page

Cause: since the introduction of URL rewritting in
be8fc2296b3822baffe0bc68cb4b7efdfe53fa91 the url_for method only worked
for rewrite of route that had a POST method. In a GET method there was
no try/except to handle a rewrite.

Fix: handle GET method rewrite as it's done for POST method.

Note: the added test without the fix fails with a 500 status code
instead of the 200 expected.

opw-4817473

Forward-Port-Of: odoo/odoo#212969

Since 18.0, we don't store `nodeId` on a `Node` anymore. The error fixed by this commmit led to failure of the mechanism in charge of avoiding duplication of nodes during serialization of history steps. Steps to reproduce: - Open the same project task in two tabs, so that collaboration is enabled. - In one tab, type some text, select it, and make it bold. - Notice that in the other tab the typed text is duplicated. task-4825081 Forward-Port-Of: odoo/odoo#212072

Since 18.0, we don't store `nodeId` on a `Node` anymore. The error fixed by this commmit led to failure of the mechanism in charge of avoiding duplication of nodes during serialization of history steps.

Steps to reproduce:
- Open the same project task in two tabs, so that collaboration is enabled.
- In one tab, type some text, select it, and make it bold.
- Notice that in the other tab the typed text is duplicated.

task-4825081

Forward-Port-Of: odoo/odoo#212072

### Steps to reproduce: **Issue 1:** - Go to To-do. - Type any text and apply a gradient color. - Select the text and increase the font size. - The top part of the text became invisible. **Issue 2:** - Write and select some text . - Apply a gradient text/background color. - Click the 'Remove Format' button in the toolbar. - Gradient styles are removed, but the font size class remains. - Only on a second click, the font size class is removed. ### Description of the issue/feature

### Steps to reproduce:

**Issue 1:**
- Go to To-do.
- Type any text and apply a gradient color.
- Select the text and increase the font size.
- The top part of the text became invisible.

**Issue 2:**
- Write and select some text .
- Apply a gradient text/background color.
- Click the 'Remove Format' button in the toolbar.
- Gradient styles are removed, but the font size class remains.
- Only on a second click, the font size class is removed.

### Description of the issue/feature this PR addresses:

- When text or background color is applied using classes, applying a font size would nest the font-size <span> inside the <font> tag.
- Font size class was not removed when gradient styles were present, as the closest element after `removeFormat` contained the gradient styles, not the font size class.
- An extra history step from the align_plugin is causing issues with undo.

### Desired behavior after PR is merged:

- Font size is now applied outside the <font> tag even when it has color-related classes.
- `removeFormat` correctly removes both gradient styles and font size classes.
- A history step is now added only once after all formatting is removed.

task-4736914

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

Forward-Port-Of: odoo/odoo#207458

9674215 broke the on `onClick` of gauge/scorecard in dashboard. We removed the `onClick` of the figure component in favour of a chartJs plugin, but scorecard/gauge charts do not use chartJs. Task: [4826611](https://www.odoo.com/web#id=4826611&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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 a

9674215 broke the on `onClick` of gauge/scorecard in dashboard. We removed the `onClick` of the figure component in favour of a chartJs plugin, but scorecard/gauge charts do not use chartJs.

Task: [4826611](https://www.odoo.com/web#id=4826611&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

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#212721
Forward-Port-Of: odoo/odoo#211929

Versions -------- - 18.0+ Steps ----- 1. Set up a site in Dutch; 2. go to `/nl/robots.txt` Issue ----- File shows "Toestaan: /kaarten/", which is not a valid string for a robots.txt file. This section is also oddly indented. Cause ----- Inserting the additional text in a template override does not inherit the parent view's `t-translation="off"` setting. Solution -------- Add `t-translation="off"` to the template override, and ensure there's no indentation when generatin

Versions
--------
- 18.0+

Steps
-----
1. Set up a site in Dutch;
2. go to `/nl/robots.txt`

Issue
-----
File shows "Toestaan: /kaarten/", which is not a valid string for a robots.txt file.

This section is also oddly indented.

Cause
-----
Inserting the additional text in a template override does not inherit the parent view's `t-translation="off"` setting.

Solution
--------
Add `t-translation="off"` to the template override, and ensure there's no indentation when generating the file.

opw-4815818

Forward-Port-Of: odoo/odoo#212781

Scenario: - have "Editor and Designer" group and not "Administration/Settings" - go to the website, open editor and click on "Theme" > "Switch Theme" - click to install/update any theme Issue: an error is raised because we don't have the group "Administration/Settings" necessary to install a module. Fix: don't show the switch theme button if we don't have access to install it. opw-4782294 __pr note:__ for me the current behavior is ok but not very user friendly, lebl on the tick

Scenario:
- have "Editor and Designer" group and not "Administration/Settings"
- go to the website, open editor and click on "Theme" > "Switch Theme"
- click to install/update any theme

Issue: an error is raised because we don't have the group
"Administration/Settings" necessary to install a module.

Fix: don't show the switch theme button if we don't have access to
install it.

opw-4782294

__pr note:__ for me the current behavior is ok but not very user friendly, lebl on the ticket suggested that we could hide the "Switch Theme" button.

side note: in 18.0 we get a usual access error (no read access to ir.module.module.dependency), while in 16.0 we get a manual access check:

https://github.com/odoo/odoo/blob/097c9c928d88c10a01446131273fd2d10036f3dd/odoo/addons/base/models/ir_module.py#L70-L72

Forward-Port-Of: odoo/odoo#211289
Forward-Port-Of: odoo/odoo#211225

Currently all floats are formatted with the default of 2 in the chatter. Instead if "digits" is specified for the field we should display the field with that precision. Formatting tests were updated, which required adding the option to set the "digits" field value for fields on models that are fetched from back-end definitions. As that info is only stored in python and is not transmitted to the test framework, similarly to "default". task-4746268 Forward-Port-Of: odoo/odoo#212566 For

Currently all floats are formatted with the default of 2 in the chatter.
Instead if "digits" is specified for the field we should display the
field with that precision.

Formatting tests were updated, which required adding the option to set
the "digits" field value for fields on models that are fetched from
back-end definitions. As that info is only stored in python and is not
transmitted to the test framework, similarly to "default".

task-4746268

Forward-Port-Of: odoo/odoo#212566
Forward-Port-Of: odoo/odoo#206989

Before this commit, if a session included negative bank payments resulting in a negative total, the session report displayed incorrect counted amounts and mismatched values for the bank payment method. opw-4714251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207962

Before this commit, if a session included negative bank payments resulting in a negative total, the session report displayed incorrect counted amounts and mismatched values for the bank payment method.

opw-4714251

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

Forward-Port-Of: odoo/odoo#207962

Problem: When selecting multi-line highlighted text that includes inline SVGs, the `selectedBlocks` includes both the parent `<p>` and the inner `<svg>` elements. These SVGs are incorrectly considered the deepest blocks, which prevents the parent `<p>` from being used to apply text styles (since styles can't be applied on `<svg>` elements). Example: ``` <p> <span class="o_text_highlight"> <span class="o_text_highlight_item">text<svg></span> <span class="o_text_highli

Problem:
When selecting multi-line highlighted text that includes inline SVGs, the `selectedBlocks` includes both the parent `<p>` and the inner `<svg>` elements. These SVGs are incorrectly considered the deepest blocks, which prevents the parent `<p>` from being used to apply text styles (since styles can't be applied on `<svg>` elements).

Example:
```
<p>
    <span class="o_text_highlight">
        <span class="o_text_highlight_item">text<svg></span>
        <span class="o_text_highlight_item">text<svg></span>
    </span>
</p>
```

As a result, style changes (like font) on the selection do nothing.

Solution:
Filter out non-editable blocks (e.g., `<svg>`) from `selectedBlocks` to ensure valid blocks like `<p>` are correctly handled as the deepest block.

Steps to reproduce:
1. Go to Website.
2. Add a paragraph with multiple lines of text.
3. Select all text and apply highlight.
4. Try to change the text style on the same selection. → The style change has no effect.

opw-4438171

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

Forward-Port-Of: odoo/odoo#210305

…ivery **Problem:** When a product is added to a sale order from the delivery the cost is not computed **Steps to reproduce:** - Activate the "Margins" Settings - Open Sales/Products and create a product - In the product Type field, choose consumable and set a postive cost - Do the same for a second product - Navigate to Sales/Order and create a new quotation - Add your first product and Confirm - Click on the Delivery smart button and then on the Detailed Operations smart bu

…ivery

**Problem:**
When a product is added to a sale order from the delivery 
the cost is not computed

**Steps to reproduce:**
- Activate the "Margins" Settings
- Open Sales/Products and create a product
- In the product Type field, choose consumable 
and set a postive cost
- Do the same for a second product
- Navigate to Sales/Order and create a new quotation
- Add your first product and Confirm
- Click on the Delivery smart button and then on the 
Detailed Operations smart button
- Click on New, add your second product and set 
a quantity of 1
- Go back to the delivery and validate it
- Go back to the sale order

**Current behavior:**
A line has been added with the product but the Cost is zero 

**Expected behavior:**
The cost should be computed

**Cause of the issue:**

Because of the elif logic here 
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L17-L22
the cost of products added on delivery with a standard price 
will be computed using _compute_average_price
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L23
We should instead add the line to "line_ids_to_pass" so 
they're computed with the super method

**Fix:**

Changing the elif logic to make sure that if a product is added in 
delivery and has a non standard cost method it's cost is computed 
here 
https://github.com/odoo/odoo/blob/799761246820eee73492277ab18f327ba04b6b96/addons/sale_stock_margin/models/sale_order_line.py#L23
but if it's added in delivery and has a standard cost method,
we call the super method for this line

opw-4581531

Forward-Port-Of: odoo/odoo#212773
Forward-Port-Of: odoo/odoo#208176

Correct the double click selection at the end of a link to allow the new text input to be inside the link. task-4801000 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211031

Correct the double click selection at the end of a link to allow the new text input to be inside the link.

task-4801000


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

Forward-Port-Of: odoo/odoo#211031

Before this commit: --------------------- - Internal notes of order were printed on the customer receipt. After this commit: ----------------------------- - Internal notes are no longer printed; only customer notes appear on the receipt. Task:4789682 Related PR - https://github.com/odoo/enterprise/pull/85740 Forward-Port-Of: odoo/odoo#212472 Forward-Port-Of: odoo/odoo#209640

Before this commit:
---------------------
- Internal notes of  order were printed on the customer receipt.

After this commit:
-----------------------------
- Internal notes are no longer printed; only customer notes appear on the
  receipt.

Task:4789682

Related PR - https://github.com/odoo/enterprise/pull/85740

Forward-Port-Of: odoo/odoo#212472
Forward-Port-Of: odoo/odoo#209640

Steps to reproduce: - Create a dashboard with a pivot table with a date field and a global filter on it. Ensure that the date field is set to "Month" in the pivot table and at least a value for the month of December is present. - Open the dashboard - Click on the "December" value in the pivot => Only the year is selected in the global filter, not the month. Same thing happens when the date field is set to quarter and the value Q4 is selected. Task: 4844417 Description of the issue/fe

Steps to reproduce:
- Create a dashboard with a pivot table with a date field and a global filter on it. Ensure that the date field is set to "Month" in the pivot table and at least a value for the month of December is present.
- Open the dashboard
- Click on the "December" value in the pivot => Only the year is selected in the global filter, not the month.

Same thing happens when the date field is set to quarter and the value Q4 is selected.

Task: 4844417

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#213036
Forward-Port-Of: odoo/odoo#212677

<b>Steps to reproduce:</b> 1. Go to Invoices > Create new 2. Add a long string in Terms & Conditions > Click "Print" <b>Issue:</b> - In Invoices, a horizontal scrollbar appears in the Terms & Conditions section. <b>Cause:</b> - The class `overflow-auto` was applied to the container, which triggers scrollbar when content overflows. <b>Solution:</b> - Replace `overflow-auto` with `overflow-hidden` to avoid overflow. <b>opw-4776919</b> Image of issue: ![image](https://github.co

<b>Steps to reproduce:</b>
1. Go to Invoices > Create new 
2.  Add a long string in Terms & Conditions > Click "Print"

<b>Issue:</b>
- In Invoices, a horizontal scrollbar appears in the Terms & Conditions section.
<b>Cause:</b>
- The class `overflow-auto` was applied to the container, which triggers scrollbar when content overflows.

<b>Solution:</b>
- Replace `overflow-auto` with `overflow-hidden` to avoid overflow.

<b>opw-4776919</b>

Image of issue:
![image](https://github.com/user-attachments/assets/41df69b1-4078-406b-a0ed-8edc2521bbbc)
![image](https://github.com/user-attachments/assets/ab41d900-ac39-4916-ac61-5046d5ff0959)

Forward-Port-Of: odoo/odoo#210778

Before this commit, if a PoS had two pricelists and a product had pricelist rules in both, determining the applicable pricelist could result in infinite recursive calls. This commit resolves the issue by filtering rules based on the selected pricelist. opw-4840723 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212906

Before this commit, if a PoS had two pricelists and a product had pricelist rules in both, determining the applicable pricelist could result in infinite recursive calls. This commit resolves the issue by filtering rules based on the selected pricelist.

opw-4840723

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

Forward-Port-Of: odoo/odoo#212906

Steps to Reproduce: 1. Insert a video using the /video command. 2. Place the cursor on the new line below the video. 3. Press Backspace to delete the video. 4. Press Ctrl + Z to undo the deletion. 5. Observe that the `Type / for commands` hint and the magic buttons appear misaligned on different lines. Current behavior before PR: - After undoing video removal, the video block is remounted and at that time powerButtons position updates but iframe loads after that. - PowerButtons upd

Steps to Reproduce:

1. Insert a video using the /video command.
2. Place the cursor on the new line below the video.
3. Press Backspace to delete the video.
4. Press Ctrl + Z to undo the deletion.
5. Observe that the `Type / for commands` hint and the magic buttons appear misaligned on different lines.

Current behavior before PR:

- After undoing video removal, the video block is remounted and at that time powerButtons position updates but iframe loads after that.
- PowerButtons update runs too early when video height is zero, causing misalignment.

Desired behavior after PR is merged:

- Introduce `post_mount_component_handlers` dispatched after each component mount completes.
- PowerButtonsPlugin uses this to update positions after the video and iframe are fully ready.
- Ensures powerButtons and hint paragraph stay correctly aligned after undo restores video.

task-4832484

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

Forward-Port-Of: odoo/odoo#212325

Currently, an error is encountered when clicking on the publish button in the profile page in the website view. **Steps to Reproduce:** - Install `website_profile` module. - Navigate to the user's profile page.`(/profile/user/2)` - Click on the publish button in the editor view. **Note:** - The error is generic and could be generated via different website modules as well (e.g, website_forum). **Error:** AttributeError: The method `res.users.website_publish_button` does not ex

Currently, an error is encountered when clicking on the publish button in the 
profile page in the website view.

**Steps to Reproduce:**
- Install `website_profile` module.
- Navigate to the user's profile page.`(/profile/user/2)`
- Click on the publish button in the editor view.

**Note:**
- The error is generic and could be generated via different website modules as 
  well (e.g, website_forum).

**Error:**
AttributeError: The method `res.users.website_publish_button` does not exist.

**Root Cause:**
- since [1] we are using `website_publish_button` method to publish/unpublish
  records, however, `res.users` model **inherits** the publishing fields from its 
  `res.partner`, but not its related publishing methods

[1]- https://github.com/odoo/odoo/commit/97d00377de0c32e919587a98210679376e27ecc4

**Solution:**
- This commit ensures that the `res.users` model can handle publish/unpublish
  calls by adding the `website_publish_button` method to `res.users`.

sentry-6356507720

Forward-Port-Of: odoo/odoo#207470

This commit fixes an issue in the `_compute_valid` method of the `hr.leave.type` model. The `('allocation_type', '=', 'accrual')` was removed from the domain, as it limited the valid allocations to type `accrual` only, which is not the intended behavior --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212810 Forward-Port-Of: odoo/odoo#212548

This commit fixes an issue in the `_compute_valid` method of the `hr.leave.type` model. The `('allocation_type', '=', 'accrual')` was removed from the domain, as it limited the valid allocations to type `accrual` only, which is not the intended behavior

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

Forward-Port-Of: odoo/odoo#212810
Forward-Port-Of: odoo/odoo#212548

When the user opens the chatter and expands the sidebar, the chatter's topbar overlaps the sidebar. This overlap disrupts the layout and can be frustrating, as it may hide some article links. To fix this, we'll update the sidebar's z-index so it sits above regular elements but remains below modals. Task-4636494 Forward-Port-Of: odoo/enterprise#86462

When the user opens the chatter and expands the sidebar, the chatter's topbar overlaps the sidebar. This overlap disrupts the layout and can be frustrating, as it may hide some article links. To fix this, we'll update the sidebar's z-index so it sits above regular elements but remains below modals.

Task-4636494

Forward-Port-Of: odoo/enterprise#86462

Steps to Reproduce: - Open the Planning app. - Click on the avatar of a resource. - Refresh the page, then click on the avatar of a resource again. Issue: - A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading. Solution: - Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during `super.onWillStart`. - Modified `onWillStart` to ensure `h

Steps to Reproduce:
- Open the Planning app.
- Click on the avatar of a resource.
- Refresh the page, then click on the avatar of a resource again.

Issue:
- A traceback error occurs when clicking on the avatar after a page refresh, likely due to component destruction or incomplete loading.

Solution:
- Consolidated multiple RPC calls into a single method in the parent component to avoid issues with component destruction during `super.onWillStart`.
- Modified `onWillStart` to ensure `hr_access` data is fetched without risking lifecycle conflicts.

task-4210513

Forward-Port-Of: odoo/enterprise#84401
Forward-Port-Of: odoo/enterprise#75121

*l10n_es_real_estates,l10n_es_reports,l10n_es_reports_2024 Related to https://github.com/odoo/odoo/pull/210804 Forward-Port-Of: odoo/enterprise#86995 Forward-Port-Of: odoo/enterprise#85966

*l10n_es_real_estates,l10n_es_reports,l10n_es_reports_2024

Related to https://github.com/odoo/odoo/pull/210804

Forward-Port-Of: odoo/enterprise#86995
Forward-Port-Of: odoo/enterprise#85966

Steps to reproduce: - With an ES company setup - Create and confirm invoice with: - partner: EU partner - Invoice Date: 01 Dec 2024 - Accounting Date: 01 Jan 2025 - Amount: 1000 - Confirm and create the credit note dated 02 Jan 2025 - Check Mod 349 Tax Report for Jan 2025 Issue: In the Invoices section we can see the full invoice amount (1000) but nothing about the refund This occurs because we use the invoice date to decide if we consider the move amount for the current se

Steps to reproduce:
- With an ES company setup
- Create and confirm invoice with:
  - partner: EU partner
  - Invoice Date: 01 Dec 2024
  - Accounting Date: 01 Jan 2025
  - Amount: 1000
- Confirm and create the credit note dated 02 Jan 2025
- Check Mod 349 Tax Report for Jan 2025

Issue: In the Invoices section we can see the full invoice amount (1000) but nothing about the refund

This occurs because we use the invoice date to decide if we consider the move amount for the current section and not the accounting date

opw-4718611

Forward-Port-Of: odoo/enterprise#86839
Forward-Port-Of: odoo/enterprise#85479

Before this commit, when several achievements were done on the same period for the same record, they would share the same id and therefore could not be properly processed in the interface. In order to fix this, we decide to use the achievement date to compute the id. As a result, for achievement based on MRR (subscription), if two sale.order.log corresponds to the same order, on the same date, we will end up with a duplicated id too. It happens because the related_res_model and related_res_i

Before this commit, when several achievements were done on the same period for the same record, they would share the same id and therefore could not be properly processed in the interface.

In order to fix this, we decide to use the achievement date to compute the id. As a result, for achievement based on MRR (subscription), if two sale.order.log corresponds to the same order, on the same date, we will end up with a duplicated id too.
It happens because the related_res_model and related_res_id of achievement based on MRR is the order linked to the sale.order.log.

To avoid this issue, we introduce another source of entropy in the computation of the achievement's id: the write date of the record. In that case, we are free to use the write_date of the sale.order.log and therefore they should be different.
Same apply for sale.order and account.move for other kind of achievements because of the UNION ALL.

 taskid: 4845096

Forward-Port-Of: odoo/enterprise#86644

If account and account_accountant are installed but not accountant the test test_change_payment_state_valid will fail This occurs because the valid payment states for batch payments change when accountant is installed runbot-226305 Forward-Port-Of: odoo/enterprise#86821

If account and account_accountant are installed but not accountant
the test test_change_payment_state_valid will fail
This occurs because the valid payment states for batch payments change
when accountant is installed

runbot-226305

Forward-Port-Of: odoo/enterprise#86821

The XML already reports **PesoBrutoVehicular** in metric tonnes, as required by the Carta Porte complement. However, the PDF layout labelled the value as **kg**. * Updated QWeb template to display the unit `t`. Legal basis ----------- * Complemento Carta Porte 3.1 – Instructivo de llenado: “Peso Bruto Vehicular… atributo requerido para indicar **en toneladas** el peso bruto vehicular permitido… de acuerdo con la NOM-SCT-012-2017”. :contentReference[oaicite:0]{index=0} Forward-Port-Of:

The XML already reports **PesoBrutoVehicular** in metric tonnes, as required by the Carta Porte complement.
However, the PDF layout labelled the value as **kg**.

* Updated QWeb template to display the unit `t`.

Legal basis
-----------
* Complemento Carta Porte 3.1 – Instructivo de llenado: “Peso Bruto Vehicular… atributo requerido para indicar **en toneladas** el peso bruto vehicular permitido… de acuerdo con la NOM-SCT-012-2017”. :contentReference[oaicite:0]{index=0}

Forward-Port-Of: odoo/enterprise#85798

The recognition entry for corporate tax was incorrect as it was crediting the expense while debiting the liability. This fixes the entry to: Debit: Tax Report Counter Part Account Credit: Liabilities Account for Tax Report Task ID: 4808001 Forward-Port-Of: odoo/enterprise#86315

The recognition entry for corporate tax was incorrect as it was crediting the expense while debiting the liability. This fixes the entry to:

Debit: Tax Report Counter Part Account
Credit: Liabilities Account for Tax Report

Task ID: 4808001

Forward-Port-Of: odoo/enterprise#86315

Issue: In Barcode, editing the qty_done of a move line and then reseting it to 0 will update the demand. ### Steps to reproduce: - Create a storable product. Put 5 units in stock. - Create a delivery order for 5 units and mark as to do. - Go to the barcode app and edit your delivery order. - Click on the pencil and set a qty of 1 > Confirm - Click back on the pencil and reset the quantity to 0 > confirm #### > On the picking, the demand of the line was edited from 5 to 1. ### Cause

Issue: In Barcode, editing the qty_done of a move line and then reseting it to 0 will update the demand.

### Steps to reproduce:

- Create a storable product. Put 5 units in stock.
- Create a delivery order for 5 units and mark as to do.
- Go to the barcode app and edit your delivery order.
- Click on the pencil and set a qty of 1 > Confirm
- Click back on the pencil and reset the quantity to 0 > confirm
#### > On the picking, the demand of the line was edited from 5 to 1.

### Cause of the issue:

Editing the quantity of a move line from the barcode actually updates the qty_done of the move line which updates both the quantity and the picked status of the move line in the backend via the `_inverse_qty_done`: https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/models/stock_move_line.py#L58-L62 Initially, the quantity of the move line was 5 and hence the demand of the line in the barcode was displayed as 5:
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L119-L121 The first time you edit the line, you will actually change its quantity to 1 and set it as picked. Once the line state refreshes in the barcode it will then keep the same demand of 5 as it will then be based on the previous demand of the line (since the qty of the move line is set and the qty done is positive):
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045 However, the next time you update the line the `_inverse_qty_done` will leave the quantity of the move line at 1 but will also unpick it. Then, and since the `qty_done` was set to 0, it will update the demand of the barcode line because of these same lines:
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045

### Fix:

Prior to Commit 3af3e00aabecde8b811ac2cbab397f982721f164 the quantity was updated as well as the picked state even when the qty_done was set to 0, so that this issue would not occur as the null quantity would make us keep the demand of barcode line after edition. However, the problem was that this would update the reserved quantity of the move and hence the barcode app demand once you leave the barcode app because of the `split_uncompleted_moves`. However, in the present use case, that same method can save us because if the move is picked and its quantity is null when you exit the barcode app, it will be rereversed.

opw-4700996

Forward-Port-Of: odoo/enterprise#86334
Forward-Port-Of: odoo/enterprise#83623

Before this commit: ------------------ - The preparation ticket displayed DUPLICATA on every print, regardless of whether it was a reprint or not. After this commit: -------------------- - DUPLICATA is now printed only when the preparation ticket is a reprint, avoiding confusion during regular printing. Task: 4789682 Related PR - https://github.com/odoo/odoo/pull/209640 Forward-Port-Of: odoo/enterprise#86735 Forward-Port-Of: odoo/enterprise#85740

Before this commit:
------------------
- The preparation ticket displayed DUPLICATA on every print, regardless of whether it was a reprint or not.

After this commit:
--------------------
- DUPLICATA is now printed only when the preparation ticket is a reprint, avoiding confusion during regular printing.

Task: 4789682

Related PR - https://github.com/odoo/odoo/pull/209640

Forward-Port-Of: odoo/enterprise#86735
Forward-Port-Of: odoo/enterprise#85740