Before PR #187439, the field DescripcionFactura defaulted to `manual` when the origin was False. That PR removed the fallback and moved the default assignment to `_l10n_es_tbai_get_invoice_values` in `l10n_es_edi_tbai` module, but forgot to apply the same logic in `_l10n_es_tbai_get_values`. Steps to reproduce: - Create a new TBAI POS order - Try to submit it - You’ll get an error: ```cvc-complex-type.2.4.a: Invalid content was found starting with element 'DetallesFactura'. One of '{F

Before PR #187439, the field DescripcionFactura defaulted to `manual` when the origin was False.

That PR removed the fallback and moved the default assignment to `_l10n_es_tbai_get_invoice_values` in `l10n_es_edi_tbai` module, but forgot to apply the same logic in `_l10n_es_tbai_get_values`.

Steps to reproduce:
- Create a new TBAI POS order
- Try to submit it
- You’ll get an error:
```cvc-complex-type.2.4.a: Invalid content was found starting
with element 'DetallesFactura'. One of '{FechaOperacion,
DescripcionFactura}' is expected.
```

This fix restores the fallback value 'manual' for POS invoices
to ensure schema compliance.

opw-4834333

Forward-Port-Of: odoo/odoo#215157

Problem: When copying content that includes an image with a `src` in base64 format, the origin is incorrectly prepended to the `src`, resulting in a broken image on subsequent paste. Cause: The logic that prepends the origin doesn't exclude base64 images, causing the final `src` to be invalid. Solution: Skip appending the origin if the `img.src` is already in base64 format. Steps to reproduce: 1. Copy an image (with base64 `src`) into the editor. 2. Copy the image again from within

Problem:
When copying content that includes an image with a `src` in base64 format, the origin is incorrectly prepended to the `src`, resulting in a broken image on subsequent paste.

Cause:
The logic that prepends the origin doesn't exclude base64 images, causing the final `src` to be invalid.

Solution:
Skip appending the origin if the `img.src` is already in base64 format.

Steps to reproduce:
1. Copy an image (with base64 `src`) into the editor.
2. Copy the image again from within the editor.
3. Paste the image. → The image is not shown due to incorrect `src`.

opw-4872676


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

Forward-Port-Of: odoo/odoo#214367

A global rule for base.group_user is missing for the event.answer.model. This commit adds it. A test has been added to check that internal users have all the permissions required to register for events. Reproduce: The administrator must create a new user and let empty the permissions for sales and for events. When trying to register for an event that has questions with options, this new user will trigger a 500 error. task- Forward-Port-Of: odoo/odoo#215444

A global rule for base.group_user is missing for the event.answer.model. This commit adds it.

A test has been added to check that internal users have all the permissions required to register for events.

Reproduce:
The administrator must create a new user and let empty the permissions for sales and for events. When trying to register for an event that has questions with options, this new user will trigger a 500 error.

task-

Forward-Port-Of: odoo/odoo#215444

Restore the "New Content" ribbon (activated via page options) which should be displayed on the course card when a new published content has been added during the last 7 days. The ribbon isn't displayed because it's declared in a "t-field" element which replaces its content to display the field at rendering. Task-4852463 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213788

Restore the "New Content" ribbon (activated via page options) which
should be displayed on the course card when a new published content
has been added during the last 7 days.

The ribbon isn't displayed because it's declared in a "t-field" element
which replaces its content to display the field at rendering.

Task-4852463

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

Forward-Port-Of: odoo/odoo#213788

To adapt to the merge of `hw_drivers` and `hw_posbox_homepage` into `iot_drivers`, we need to update the `odoo.conf` file to change the modules to load. Task: 4860513 Forward-Port-Of: odoo/odoo#215536

To adapt to the merge of `hw_drivers` and `hw_posbox_homepage` into `iot_drivers`, we need to update the `odoo.conf` file to change the modules to load.

Task: 4860513

Forward-Port-Of: odoo/odoo#215536

<b>Steps to reproduce:</b> 1) Install the Project module and enable debug mode. 2) Go to Configuration > Task Stages in the Project app 3) Try to create a new task stage in form view <b>Issue:</b> The Project field is not visible when creating a new task stage in the form view. <b>Cause:</b> The form view only shows the `project_id` field if the `user_id` is not set. https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/views/project_task_type_v

<b>Steps to reproduce:</b>

1) Install the Project module and enable debug mode.
2) Go to Configuration > Task Stages in the Project app
3) Try to create a new task stage in form view

<b>Issue:</b>
The Project field is not visible when creating a new task stage in the form view.

<b>Cause:</b>

The form view only shows the `project_id` field if the `user_id` is not set. https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/views/project_task_type_views.xml#L46-L48

However, the action context includes `default_project_id=False`, 
which causes the defaulting logic to compute a `default_user_id` (based on the falsy project). 
As a result, `user_id` is set, hiding the project_id field from the form.

https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/views/project_task_type_views.xml#L143 https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/models/project_task_type.py#L19-L20

<b>Fix:</b>
Add a key in the context to make the user_id as False when creating a new task stage from the Form view.

opw-4767251

Forward-Port-Of: odoo/odoo#210355

Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031 This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. --- I co

Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed.

The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031

This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views.

We will removes the unnecessary invisible fields in master.



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

Forward-Port-Of: odoo/odoo#210363
Forward-Port-Of: odoo/odoo#206026

Due to historical error, the key mapped for cancel remarks seems to be incorrect. Due to which while cancelling the E-waybill we receive the error code `[659] Remark is mandatory`. In this commit, we make sure the keys are mapped correctly as per https://docs.ewaybillgst.gov.in/apidocs/version1.03/cancel-eway-bill.html Though as per the schema validation the remark is not mandatory after receiving the ticket it doesn't seems like that :) opw-4882071 --- I confirm I have signed th

Due to historical error, the key mapped for cancel remarks seems to be incorrect. Due to which while
cancelling the E-waybill we receive the error code `[659] Remark is mandatory`. In this commit,
we make sure the keys are mapped correctly as
per https://docs.ewaybillgst.gov.in/apidocs/version1.03/cancel-eway-bill.html

Though as per the schema validation the remark is
not mandatory after receiving the ticket it doesn't seems like that :)

opw-4882071


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

Forward-Port-Of: odoo/odoo#215523

Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a multi-company environment, we cannot access the warehouse of a different company. In the sale_order model, the `_init_column` method populates the warehouse value for existing sales orders before stock is installed. It uses self.env.company to set the warehouse, but `_init_colum

Steps to reproduce:
   - Install sales
   - Create a new company (CMP2)
   - Switch to CMP2
   - Create a sales order
   - Install stock
   - Go to the SO created, update it and save

The problem is that in a multi-company environment, we cannot access
the warehouse of a different company. In the sale_order model, the
`_init_column` method populates the warehouse value for existing sales
orders before stock is installed. It uses self.env.company to set
the warehouse, but `_init_column` is called with superuser privileges,
which lack user context. This causes warehouses to always be linked to
the superuser's company (id=1). As a result, modifying sales orders
from different companies becomes impossible.

opw-4735086

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#212057
Forward-Port-Of: odoo/odoo#207792

Following this commit: 9448836cb0307161d829f28bda0bdb5bf50f3a10 This commit adds a test to ensure that the booking and release table functionality works correctly in the POS Restaurant module. The test verifies that when a table is booked the order is correctly sent to the server. Forward-Port-Of: odoo/odoo#215529

Following this commit: 9448836cb0307161d829f28bda0bdb5bf50f3a10

This commit adds a test to ensure that the booking and release table functionality works correctly in the POS Restaurant module. The test verifies that when a table is booked the order is correctly sent to the server.

Forward-Port-Of: odoo/odoo#215529

This PR has following commit- - **[FIX] l10n_in_ewaybill_stock:cancel remarks mandatory** (Already managed by https://github.com/odoo/odoo/pull/215523) Since it would more much better to handle the fw-port with different version this commit will be removed in saas-18.1 fw-port and will be surpassed by the above mention PR - **[FIX] l10n_in_ewaybill_stock: Allow cancelation of E-waybill** When canceling E-waybill if error `312` occurred it means the E-waybill is already been cancelled b

This PR has following commit-
- **[FIX] l10n_in_ewaybill_stock:cancel remarks mandatory** (Already managed by https://github.com/odoo/odoo/pull/215523)
 Since it would more much better to handle the fw-port with different version this commit will be removed in saas-18.1 fw-port and will be surpassed by the above mention PR

- **[FIX] l10n_in_ewaybill_stock: Allow cancelation of E-waybill**

When canceling E-waybill if error `312` occurred it means
the E-waybill is already been cancelled but in that case
we raise warning while E-waybill stays in the state of
`Generated`.

In this commit we handle error `312`, we receive it,
we will log it on the E-waybill and cancel the E-waybill
as it is already being cancelled

opw-4882071

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

Forward-Port-Of: odoo/odoo#215556

The `s_numbers_charts` snippet had two main issues: - The progress bar within `s_numbers_charts` visually appeared as 45% on initial rendering, despite its actual configured value being 25%. This was due to a mismatch between its `aria-valuenow` attribute and its style `width` property. The display would correct itself when the user manually changed the value. - A crash would occur when attempting to select the "Label" option after dropping the `s_numbers_charts` snippet. This happe

The `s_numbers_charts` snippet had two main issues:
- The progress bar within `s_numbers_charts` visually appeared as 45% on
  initial rendering, despite its actual configured value being 25%. This
was due to a mismatch between its `aria-valuenow` attribute and its
style `width` property. The display would correct itself when the user
manually changed the value.

- A crash would occur when attempting to select the "Label" option after
  dropping the `s_numbers_charts` snippet. This happened because
`s_progress_bar_text` was forgotten during the initial implementation of
`s_numbers_charts` [1].

This commit addresses these problems by:
- Adding the missing `s_progress_bar_text` to the `s_numbers_charts` template.
- Including `s_progress_bar_text` in `_computeSnippetTemplates` to
  ensure that existing databases also receive this fix, as snippets are
stored in the database.
- Adding a check in the `progress` option to prevent the aforementioned crash.

Steps to reproduce the crash:
- Drop the `s_numbers_charts` snippet.
- Click on a progress bar within the snippet.
- Select the option `Label`.
- Hover over "Hide" without any other prior interactions.
- A crash will occur.

[1]: https://github.com/odoo/odoo/commit/6c94fd66c1db75d74588ce670fb6cf1e960cf8bd

Forward-Port-Of: odoo/odoo#214318

Before this commit, when plain text (e.g., "Some tax") was imported from a CSV file into the HTML field `description`, the system wrapped it in a `<p>` tag during normalization via `html_normalize`, since plain text is not valid HTML. After this commit, we add a check before record creation: - If the value is plain text without any HTML, we wrap it in a `<div>` to make it valid HTML. - If it already contains HTML, we leave it untouched. This avoids unintended `<p>` wrapping by `html_n

Before this commit, when plain text (e.g., "Some tax") was imported from a CSV
file into the HTML field `description`, the system wrapped it in a `<p>` tag
during normalization via `html_normalize`, since plain text is not valid HTML.

After this commit, we add a check before record creation:
- If the value is plain text without any HTML, we wrap it in a `<div>` to make it
valid HTML.
- If it already contains HTML, we leave it untouched.

This avoids unintended `<p>` wrapping by `html_normalize`.

Note: if content is wrapped in a `<div>`, `html_normalize` will strip it out.
This ensures consistent HTML formatting for the description field during
create/write operations and prevents unexpected automatic wrapping by
the system.

task-4862728

Forward-Port-Of: odoo/odoo#214113

Updated XML files to include the noupdate attribute for the data in project_data.xml. This change ensures that the records are not updated during module upgrades, preserving customizations. 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#214275

Updated XML files to include the noupdate attribute for the data in project_data.xml. This change ensures that the records are not updated during module upgrades, preserving customizations.

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

Modifies a test to check the tax disclaimer added by 4ec8d2198a1a0 (and fixed by 3d4027b6ab115) to prevent regression. opw-4454112 Forward-Port-Of: odoo/odoo#215572

Modifies a test to check the tax disclaimer added by 4ec8d2198a1a0 (and fixed by 3d4027b6ab115) to prevent regression.

opw-4454112

Forward-Port-Of: odoo/odoo#215572

Before this commit, release table wasn't calling the correct method (deleteOrders) it was just changing the state of the order and waiting for calling syncAllOrders method to update the order on the server. But if the order didn't have any line it was never synched. Now the release table button calls the deleteOrders method directly and the order is removed from the server. Forward-Port-Of: odoo/odoo#215406

Before this commit, release table wasn't calling the correct method (deleteOrders) it was just changing the state of the order and waiting for calling syncAllOrders method to update the order on the server.

But if the order didn't have any line it was never synched.

Now the release table button calls the deleteOrders method directly and the order is removed from the server.

Forward-Port-Of: odoo/odoo#215406

Steps: - Open Calendar app without group_system access right Actual result: - Access error due to microsoft_calendar_token field Expected result - No error opw-4850523 Caused-by: https://github.com/odoo/odoo/pull/150186 Forward-Port-Of: odoo/odoo#214328

Steps:
- Open Calendar app without group_system access right

Actual result:
- Access error due to microsoft_calendar_token field

Expected result
- No error

opw-4850523

Caused-by: https://github.com/odoo/odoo/pull/150186

Forward-Port-Of: odoo/odoo#214328

<b>Steps to Reproduce:</b> 1. Navigate to Inventory → Configuration 2. Search for packages and check 3. Products → Packages 4. Click or create a Package (With at least 15-20 Char). 5. Print > Package Barcode (PDF) <b>Issue:</b> - Package names containing dashes (e.g., A101-101-110-1910) or spaces (e.g., A192 2932 2039) were breaking, affecting alignment and readability. <b>Solution:</b> - Applied `white-space: nowrap` style to the text span to prevent line wrapping and ensure con

<b>Steps to Reproduce:</b>
1. Navigate to Inventory → Configuration
2. Search for packages and check
3. Products → Packages
4. Click or create a Package (With at least 15-20 Char).
5. Print > Package Barcode (PDF)

<b>Issue:</b>
- Package names containing dashes (e.g., A101-101-110-1910) or spaces 
(e.g., A192 2932 2039) were breaking, affecting alignment and readability.

<b>Solution:</b>
- Applied `white-space: nowrap` style to the text span to prevent line wrapping
and ensure consistent alignment across all package name formats.


<b>opw-4872595</b>

Before FIX:
![image](https://github.com/user-attachments/assets/510fb131-90a5-4975-a75b-3e6bab247c3e)
After FIX :
![image](https://github.com/user-attachments/assets/acb96e4d-d7e7-4fe1-8ad0-6fee8de3dda6)

Forward-Port-Of: odoo/odoo#215354

**Error:** `ValueError: Wrong value for whatsapp.template.lang_code: 'es_CO'` **Before:** Some language codes that are officially supported by WhatsApp were missing from the module's language list, leads to an error during template synchronization. **After:** This commit adds missing language codes, which are supported by WhatsApp to prevent errors during synchronization. Reference: https://developers.facebook.com/docs/whatsapp/business-management-api/message-templates/supported-la

**Error:**
`ValueError: Wrong value for whatsapp.template.lang_code: 'es_CO'`

**Before:**
Some language codes that are officially supported by WhatsApp were missing from
the module's language list, leads to an error during template synchronization.

**After:**
This commit adds missing language codes, which are supported by WhatsApp
to prevent errors during synchronization.

Reference: https://developers.facebook.com/docs/whatsapp/business-management-api/message-templates/supported-languages

Sentry – 6704097351

Forward-Port-Of: odoo/enterprise#88329

when clicking the next button in the pager of the tour, it was causing issues with the report editor not being ready yet with the updated page. so added a delay after clicking n next button in the pager of the tour to avoid issues with the report editor not being ready with the updated page. build_error-163405 Forward-Port-Of: odoo/enterprise#87302

when clicking the next button in the pager of the tour, it was causing issues with the report editor not being ready yet with the updated page.

so added a delay after clicking n next button in the pager of the tour to avoid issues with the report editor not being ready with the updated page.

build_error-163405

Forward-Port-Of: odoo/enterprise#87302

The current code of `_recompute_shifts_in_leave_periods` explicitely calls the compute method `_compute_allocated_hours` of planning.slot to recompute the allocated hours according to modifications done to the public holidays. Calling the method directly like that is far from ideal as we are missing proper batching, fields protection, etc.. that the ORM usually does for computed fields. This commit replaces the explicit call by an `add_to_compute`. This essentially marks the field as "to be r

The current code of `_recompute_shifts_in_leave_periods` explicitely calls the compute method `_compute_allocated_hours` of planning.slot to recompute the allocated hours according to modifications done to the public holidays. Calling the method directly like that is far from ideal as we are missing proper batching, fields protection, etc.. that the ORM usually does for computed fields.

This commit replaces the explicit call by an `add_to_compute`. This essentially marks the field as "to be recomputed". This recomputation then happens at the next flush_model/recompute_model call and can applies the proper ORM optimizations of batching by `PREFETCH_MAX` size, protecting fields to avoid triggering loops of recomputations. This speeds up the import of new Public Holidays in an already populated database.

#### speedup

In a customer database with 50K planning.slots, 1300 of which needs to recompute their allocated_hours, the import timing Before PR vs After PR is the following:
- 40 min -> 4 min

opw-4782452

Forward-Port-Of: odoo/enterprise#88351

**Issue:** - In sale order, first select the quotation template with a recurring plan, then, change the quotation template to without a recurring plan. After changing the quotation template, the 'Recurring Plan' (`plan_id`) field still shows the value from the previously selected template. This happens because the `plan_id` is not reset when the new template has no recurring plan. - In version 17, this case was handled in the else part and set [default value](https://github.com/odoo/enterp

**Issue:**

- In sale order, first select the quotation template with a recurring plan, then, change the quotation template to without a recurring plan. After changing the quotation template, the 'Recurring Plan' (`plan_id`) field still shows the value from the previously selected template. This happens because the `plan_id` is not reset when the new template has no recurring plan.

- In version 17, this case was handled in the else part and set [default value](https://github.com/odoo/enterprise/blob/17.0/sale_subscription/models/sale_order.py#L490) (company_id.subscription_default_plan_id), but in version 18.0, the field was [removed](https://github.com/odoo/enterprise/pull/55355/files).

**Steps to reproduce:**

- Install the Sales and Subscriptions modules.
- Create two quotation templates — one with a recurring plan and one without.
- Create a Sale Order and first select the quotation template 'with a recurring plan'. 
- Then, change the quotation template to 'without a recurring plan'.

**Solution:**

- Reset `plan_id` to `None` before computing the new value to ensure accurate computation. If the selected quotation template has a recurring plan, it will be assigned; otherwise, the plan_id field will remain empty.

**Runbot v18.0 (without fix)**

![Quotation-Templates-06-17-2025_11_46_AM](https://github.com/user-attachments/assets/ce47c352-8b0e-4c85-99c9-143aaa7dab61)

![S-06-17-2025_11_45_AM](https://github.com/user-attachments/assets/e2ec4d4c-5cf1-4c1f-9035-add7bd79d897)

OPW: [4845478](https://www.odoo.com/odoo/70/tasks/4845478)

Forward-Port-Of: odoo/enterprise#87821

### Issue: The tour test_add_component_from_shop_foor_in_multi_step_manufacturing makes an assert on the value of an input before waiting for this input to be updated. runbot-build-error-226734 Forward-Port-Of: odoo/enterprise#88241

### Issue:

The tour test_add_component_from_shop_foor_in_multi_step_manufacturing makes an assert on the value of an input before waiting for this input to be updated.

runbot-build-error-226734

Forward-Port-Of: odoo/enterprise#88241

Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031 This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. Forward-Port-Of

Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed.

The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031

This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views.

We will removes the unnecessary invisible fields in master.

Forward-Port-Of: odoo/enterprise#85750
Forward-Port-Of: odoo/enterprise#83421

To reproduce the issue, on a Belgian company: 1) Create and post an entry impacting line "Other Appropriations of the Year", typically by using an account prefixed 69 in it. 2) Enable totals below sections in the settings 3) Open the Belgian BS at a date including the move created in 1). 4) Enable 'unfold all' in the report ===> "Other Appropriations of the Year" displays no amount This happens because this line is considered as having sublines by the engine (has_sublines is Tr

To reproduce the issue, on a Belgian company:

1) Create and post an entry impacting line "Other Appropriations of the Year", typically by using an account prefixed 69 in it.

2) Enable totals below sections in the settings

3) Open the Belgian BS at a date including the move created in 1).

4) Enable 'unfold all' in the report

===> "Other Appropriations of the Year" displays no amount

This happens because this line is considered as having sublines by the engine (has_sublines is True), since it considered a non-zero number of move lines in its computation. The condition that was there before makes it so that in that case, when using unfold_all, the line would have the 'unfolded' key set to True, even though, here, the line has no means of generating any subline (no child lines, nor groupby value). Therefore, the "totals below sections" feature hid the amount of the line, since it was supposed to be displayed in the total line. The total line, however was never added, since no expand function was ever called.

Note that we could avoid doing 'groupby or has_children' in the condition here, to only use 'has_children'. We do that because that's the former behavior, and some engines (custom or standard) don't return any value for has_sublines in some cases, relying on the presence of the groupby field to properly trigger the unfold. This has changed a little in 18.1, with the introduction of a custom engine for the Trial Balance. We'll see what can be done when forward-porting, and if it's not possible, will probably do something in master later on. has_sublines should probably be mandatory everywhere.

opw-4640606

Forward-Port-Of: odoo/enterprise#88359

This commit automatically enables the 'Units of Measure' setting when the user auto-fixes their settings to make their POS scale certified. While this is not a strict requirement, it helps the users to then quickly set the correct units for their products (e.g. kg) task-4885681 Forward-Port-Of: odoo/enterprise#88134

This commit automatically enables the 'Units of Measure' setting when the user auto-fixes their settings to make their POS scale certified. While this is not a strict requirement, it helps the users to then quickly set the correct units for their products (e.g. kg)

task-4885681

Forward-Port-Of: odoo/enterprise#88134

This mostly benefits `test_balance_sheet_balanced` as it mass activates reports on every `_set_up_localization` (so before rendering each report, something it does ~200 times). Forward-Port-Of: odoo/enterprise#88115

This mostly benefits `test_balance_sheet_balanced` as it mass activates reports on every `_set_up_localization` (so before rendering each report, something it does ~200 times).

Forward-Port-Of: odoo/enterprise#88115