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

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

<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

**Current behaviour before PR:** Steps to reproduce: - Have a long content so that editable content becomes scrollable. - Scroll to the bottom of content. - Select the last line of text. - Try extending selection by scrolling through mouse. - Selection is not extending and it flickers. The issue happens because `scrollToSelection` function is invoked on selectionchange and forcefully scrolls to the selected content. As result, selection is not extending when scrolling. **Desired

**Current behaviour before PR:**

Steps to reproduce:

- Have a long content so that editable content becomes scrollable.
- Scroll to the bottom of content.
- Select the last line of text.
- Try extending selection by scrolling through mouse.
- Selection is not extending and it flickers.

The issue happens because `scrollToSelection` function is invoked on selectionchange and forcefully scrolls to the selected content. As result, selection is not extending when scrolling.

**Desired behaviour after PR is merged:**

Now, `scrollToSelection` doesn't scroll to the selection if selection range is is within visible viewport area. As result, selection
can be extended by scrolling.

task-4756869



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

Forward-Port-Of: odoo/odoo#209650

Before this commit, if a POS session was open on two devices and the session was removed from one device, attempting to proceed with the opening control on the other device would result in a missing error. Steps to reproduce: 1. Open a POS session on device 1 and 2 (both at the opening control) 2. On device 1, remove the session by clicking on backend 3. On device 2, attempt to set the opening control After this commit, the system properly handles the case where the session has been rem

Before this commit, if a POS session was open on two devices and the session was removed from one device, attempting to proceed with the opening control on the other device would result in a missing error.

Steps to reproduce:
1. Open a POS session on device 1 and 2 (both at the opening control)
2. On device 1, remove the session by clicking on backend
3. On device 2, attempt to set the opening control

After this commit, the system properly handles the case where the session has been removed, preventing the missing error and improving user experience.

opw-4775255

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

Forward-Port-Of: odoo/odoo#208593

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

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#212832
Forward-Port-Of: odoo/odoo#212706

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

Steps to reproduce: 1. install website, add a link into an editing area in Todo app 2. at the url input, we don't have the internal link suggestion (fuzzy search) when typing The PR target to 18.0 because fuzzy page search is considered as a basic function when website is installed. It's a functional fix for the html_editor In this PR, we've updated the linkpopover component of the html_editor to add a fuzzy page search feature to the URL input. Before 18.0, we created another OWL ap

Steps to reproduce:
1. install website, add a link into an editing area in Todo app
2. at the url input, we don't have the internal link suggestion (fuzzy search)
when typing

The PR target to 18.0 because fuzzy page search is considered as a basic
function when website is installed. It's a functional fix for the html_editor

In this PR, we've updated the linkpopover component of the html_editor
to add a fuzzy page search feature to the URL input. Before 18.0, we
created another OWL app to load the page anchors. Here we do it by using
autocomplete component, users can now see and select from a dropdown of
relevant Odoo page anchors as they type in the URL input field.

To achieve this, we modified the popover template to include an
autocomplete field specifically designed for the link popover. In the
AutoCompleteInLinkpopover component, two new props were introduced:

1. inputClass: Allows customization of the input field's styling.
2. updateValue: Enables updating of the link popover's URL state when an
option is selected from the autocomplete dropdown.

We also remove the redundant linkpreview reload when clicking on apply,
cause the loadAsyncLinkPreview is already called at onMounted.

A unit test using hoot is added for testing the fuzzy page search in the
linkpopover.

task-4222657


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

Forward-Port-Of: odoo/odoo#187091

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

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

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

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

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

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

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

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

**Current behavior:** Using the return & exchange functionality when the product to exchange is a kit's component will not correctly update the SOL `qty_delivered` field upon validation of the exchange (out) picking. **Expected behavior:** accurate `qty_delivered` **Steps to reproduce:** 1. Create a product w/ kit bom like: * 2 units componentA * 1 units componentB 2. Sell 1 unit of the kit product, validate delivery 3. Create a return for the 1 unit of componentB and select the

**Current behavior:**
Using the return & exchange functionality when the product to exchange is a kit's component will not correctly update the SOL `qty_delivered` field upon validation of the exchange (out) picking.

**Expected behavior:**
accurate `qty_delivered`

**Steps to reproduce:**
1. Create a product w/ kit bom like:
* 2 units componentA
* 1 units componentB

2. Sell 1 unit of the kit product, validate delivery

3. Create a return for the 1 unit of componentB and select the exchange option on the wizard

4. Validate the return, then validate the exchange

5. Look at the sale order line `qty_delivered` -> it's 0

**Cause of the issue:**
The exchange picking move doesn't get a `bom_line_id` and thus is not properly aggregated in the computation of qty_delivered when incoming and outgoing quantities are being calculated (wherein these quantities must offset, but can't in this situation).

**Fix:**
When the procurement occurs to create the exchanging move, find the `bom_line_id` by looking at the original sale line's moves' bom's bom lines.

opw-4676609

Forward-Port-Of: odoo/odoo#207955

The commits in this PR address two points: 1. An account move created from a Purchase Order or Sales Order with an Analytic Distribution only has the analytical distribution from the PO/SO. The invoice/vendor bill does not add the Analytic Accounts expected from matching Analytic Distribution Models. 2. When confirming a SO with a product that creates a project, the Analytic Distribution of the line is filled with the Analytic Account of the project. But this does not happen if there is alre

The commits in this PR address two points:

1. An account move created from a Purchase Order or Sales Order with an Analytic Distribution only has the analytical distribution from the PO/SO. The invoice/vendor bill does not add the Analytic Accounts expected from matching Analytic Distribution Models.
2. When confirming a SO with a product that creates a project, the Analytic Distribution of the line is filled with the Analytic Account of the project. But this does not happen if there is already another AA in the line before confirming the SO. Another AA may be there because it was added manually or because of an existing distribution model set on the partner or the product.

More information on each can be found in the commit messages.

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

Forward-Port-Of: odoo/odoo#199763

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

…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

In our [previous commit][1], there were still a few missing bits: - We forgot to check for the `reconcile` option on the accounts set on a tax group. - The Bolivian localization had its receivable and payable accounts mixed for the tax groups. We reversed them and created a new one. - The 0% tax group for Spain had its receivable and payable accounts reversed. We changed them as well. [1]: https://github.com/odoo/odoo/commit/925f8cbe6aebad20de5423814b43e4c07644e9e1 [task-3763030](https:

In our [previous commit][1], there were still a few missing bits:
- We forgot to check for the `reconcile` option on the accounts set on a tax group.
- The Bolivian localization had its receivable and payable accounts mixed for the tax groups. We reversed them and created a new one.
- The 0% tax group for Spain had its receivable and payable accounts reversed. We changed them as well.

[1]: https://github.com/odoo/odoo/commit/925f8cbe6aebad20de5423814b43e4c07644e9e1

[task-3763030](https://www.odoo.com/odoo/project.task/3763030)

Issues noticed in https://github.com/odoo/upgrade/pull/7787

Forward-Port-Of: odoo/odoo#212785

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

Before this commit, when defining a `fields.Many()` in JS models with an inverse as `fields.One()`, assign a new record on index of the `Many()` field leads to erroneously record deletion. This happens because when record list changes, it should sync the inverse relation by deleting the old record from the record list. In the internal code of JS models, all relational fields are stored as recordList, and the removal of a record from a relational field is made with recordList.delete(). In b

Before this commit, when defining a `fields.Many()` in JS models with an inverse as `fields.One()`, assign a new record on index of the `Many()` field leads to erroneously record deletion.

This happens because when record list changes, it should sync the inverse relation by deleting the old record from the record list. In the internal code of JS models, all relational fields are stored as recordList, and the removal of a record from a relational field is made with recordList.delete().

In business code, Many fields values are returned as recordList, but One fields are returned as record or undefined. The recordList is not exposed. When the inner-code has to retrieve the record list of the relational field, it should make sure to use raw accessors rather than proxy accessors.

Due to a typo in internal code of JS models, it retrieved the record rather than the record list of the One relational field, and thus called `record.delete()` instead of `recordList.delete()`, which lead the bug at hand.

This commit fixes the issue by ensuring proper access to relational field to retrieve the record list even with One relational fields. The `toRaw()._raw` is to "remove" the proxy layer so we retrieve the raw object of relation which is always the record list for all relational fields.

Forward-Port-Of: odoo/odoo#212963

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

## Pull Request HOOT (PRHOOT) 32 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/85562 --- I confirm I have s

## Pull Request HOOT (PRHOOT) 32

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

Enterprise: https://github.com/odoo/enterprise/pull/85562

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

Forward-Port-Of: odoo/odoo#210041

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

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

## Pull Request HOOT (PRHOOT) 32 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/210041 --- I confirm I have signed

## Pull Request HOOT (PRHOOT) 32

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

Community: https://github.com/odoo/odoo/pull/210041

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

Forward-Port-Of: odoo/enterprise#85562

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

Before this commit, selecting a contact of type "company" on the payment screen would result in the following error: `TypeError: Cannot read properties of undefined (reading 'name')` This occurred because selecting a company contact automatically set the order to be invoiced, even if the required fields were not filled in. To prevent this error, the process now checks that all necessary fields are completed before setting the order to invoice. opw-4773831 Forward-Port-Of: odoo/en

Before this commit, selecting a contact of type "company" on the
payment screen would result in the following error:

`TypeError: Cannot read properties of undefined (reading 'name')`

This occurred because selecting a company contact automatically set the
order to be invoiced, even if the required fields were not filled in.

To prevent this error, the process now checks that all necessary fields
are completed before setting the order to invoice.

opw-4773831

Forward-Port-Of: odoo/enterprise#85123

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

Before this commit, closing a session containing a customer account payment would attempt to reconcile all move lines related to the customer with the same account. However, some of these lines could belong to cancelled journal entries, leading to an error. opw-4843923 Forward-Port-Of: odoo/enterprise#86873

Before this commit, closing a session containing a customer account payment would attempt to reconcile all move lines related to the customer with the same account. However, some of these lines could belong to cancelled journal entries, leading to an error.

opw-4843923

Forward-Port-Of: odoo/enterprise#86873

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