<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

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

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

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#215708
Forward-Port-Of: odoo/odoo#215556

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

This commit reverts odoo/odoo#208302, odoo/odoo#188848 and odoo/odoo#192876. Issues have been found on the synchronization with Google related to the duplication of events for synchronized users. As it is an urgent matter and these two fixes were merged too close to prior of the first problem report, we're dropping them for additional investigation. task-4873605 Forward-Port-Of: odoo/odoo#215510 Forward-Port-Of: odoo/odoo#215449

This commit reverts odoo/odoo#208302, odoo/odoo#188848 and odoo/odoo#192876.

Issues have been found on the synchronization with Google related to the duplication of events for synchronized users. As it is an urgent matter and these two fixes were merged too close to prior of the first problem report, we're dropping them for additional investigation.

task-4873605

Forward-Port-Of: odoo/odoo#215510
Forward-Port-Of: odoo/odoo#215449

<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

We added a function in the ticket screen in order to override it in the modules `pos_urban_piper` and `pos_blackbox_be`. task-id: 4781945 enterprise PR: https://github.com/odoo/enterprise/pull/87989 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214861

We added a function in the ticket screen in order to override it in the modules `pos_urban_piper` and `pos_blackbox_be`.

task-id: 4781945

enterprise PR: https://github.com/odoo/enterprise/pull/87989




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

Forward-Port-Of: odoo/odoo#214861

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

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

Fixed an issue where, when canceling a payment that originated the third-party check, the check remained in "In Hand" status when it shouldn't. Now, when the payment is canceled, the check status is properly updated to reflect its cancellation, ensuring consistency in the workflow. **Description of the issue/feature this PR addresses:** This PR addresses an issue where a third-party check remains in the "In Hand" status even after the origin payment is canceled. **Current behavior b

Fixed an issue where, when canceling a payment that originated the third-party check, the check remained in "In Hand" status when it shouldn't. 
Now, when the payment is canceled, the check status is properly updated to reflect its cancellation, ensuring consistency in the workflow.


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

This PR addresses an issue where a third-party check remains in the "In Hand" status even after the origin payment is canceled.

**Current behavior before PR:**

A customer payment is created with a third-party check.

The payment is confirmed, then moved to draft and canceled.

After cancellation, the third-party check remains in the "In Hand" status in the third-party checks menu, even though the origin payment has been canceled.

**Desired behavior after PR is merged:**

When the payment is canceled, the check will no longer remain in "In Hand" status in the third-party checks menu after the payment is canceled.



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

Forward-Port-Of: odoo/odoo#215506
Forward-Port-Of: odoo/odoo#214071

**Step to reproduce:** 1. Install `l10n_iq` and `res_partner`. 2. Create a contact with Iraq as the country and assign any state. 3. Create an invoice for that customer. **Observation:** - State codes appear as numbers (e.g., 01, 02, 03...) which are not ISO-compliant. **Issue:** - State codes in the CSV file were defined as simple numbers instead of proper ISO codes. **Solution:** - Updated all state codes to match the official ISO 3166-2:IQ codes. (Reference: https://www.iso.org

**Step to reproduce:**
1. Install `l10n_iq` and `res_partner`.
2. Create a contact with Iraq as the country and assign any state.
3. Create an invoice for that customer.

**Observation:**
- State codes appear as numbers (e.g., 01, 02, 03...) which are not ISO-compliant.

**Issue:**
- State codes in the CSV file were defined as simple numbers instead of proper ISO codes.

**Solution:**
- Updated all state codes to match the official ISO 3166-2:IQ codes. (Reference: https://www.iso.org/obp/ui/#iso:code:3166:IQ)
- For Arabic names, appended `-AR` to the code (e.g., IQ-BG-AR) for Arabic-specific entries.

opw-4808778

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

Forward-Port-Of: odoo/odoo#214396
Forward-Port-Of: odoo/odoo#213972

We store the server url in `store.base`, which was made unreactive by using owl `toRaw` method. This made the `disconnect from current` button not being displayed right after connecting to a database, without reloading the page. We removed this call to fix this behavior. We also called `waitRestart` before calling the disconnect method from the back end, in order to remove the delay before displaying the loader. Forward-Port-Of: odoo/odoo#215560

We store the server url in `store.base`, which was made unreactive by using owl `toRaw` method. This made the `disconnect from current` button not being displayed right after connecting to a database, without reloading the page.

We removed this call to fix this behavior.

We also called `waitRestart` before calling the disconnect method from the back end, in order to remove the delay before displaying the loader.

Forward-Port-Of: odoo/odoo#215560

This commit fixes a UI bug in chart trendlines by ensuring 'AxisType' is properly passed from Odoo charts to the spreadsheet. Task: [4743602](https://www.odoo.com/odoo/2328/tasks/4743602) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214724

This commit fixes a UI bug in chart trendlines by ensuring 'AxisType' is
properly passed from Odoo charts to the spreadsheet.

Task: [4743602](https://www.odoo.com/odoo/2328/tasks/4743602)

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

Forward-Port-Of: odoo/odoo#214724

We add a button to ease logs downloading from the IoT Box http 502 error page. We also update the design to match the homepage's one. This commit also sets the configuration param `list_db = False` to avoid displaying the form when the user is redirected to `/web/database/selector` (which should not happen). Forward-Port-Of: odoo/odoo#215555

We add a button to ease logs downloading from the IoT Box http 502 error page. We also update the design to match the homepage's one.

This commit also sets the configuration param `list_db = False` to avoid displaying the form when the user is redirected to `/web/database/selector` (which should not happen).

Forward-Port-Of: odoo/odoo#215555

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

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

Whenever there is a fault in the ZATCA onboarding steps (like missing Certificate Signing Request (CSR) information etc.), a traceback is returned to the user instead of a clear error message. This behavior was introduced by the following PR: https://github.com/odoo/odoo/pull/205671 which changed the return format of the `_l10n_sa_call_api` function in case of failures. Steps to reproduce: - Configure a Saudi Arabia company - Switch ZATCA environment to Simulation (or Production) - At

Whenever there is a fault in the ZATCA onboarding steps (like missing
Certificate Signing Request (CSR) information etc.), a traceback is
returned to the user instead of a clear error message.
This behavior was introduced by the following PR: https://github.com/odoo/odoo/pull/205671
which changed the return format of the `_l10n_sa_call_api` function in
case of failures.

Steps to reproduce:
- Configure a Saudi Arabia company
- Switch ZATCA environment to Simulation (or Production)
- Attempt to onboard a journal using an incorrect OTP code
- A traceback is triggered instead of a clear user-facing error

Traceback example:
```
File "/home/odoo/src/odoo/17.0/addons/l10n_sa_edi/models/account_journal.py", line 200, in _l10n_sa_compute_production_csid_validity
journal.l10n_sa_production_csid_validity = self._l10n_sa_get_pcsid_validity(
File "/home/odoo/src/odoo/17.0/addons/l10n_sa_edi/models/account_journal.py", line 516, in _l10n_sa_get_pcsid_validity
b64_decoded_pcsid = b64decode(PCSID_data['binarySecurityToken'])
File "/usr/lib/python3.10/base64.py", line 80, in b64decode
s = _bytes_from_decode_data(s)
File "/usr/lib/python3.10/base64.py", line 45, in _bytes_from_decode_data
raise TypeError("argument should be a bytes-like object or ASCII "
TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType'
```

This is due to the check in `_l10n_sa_get_compliance_CSID` for an 'error'
key, not present in the response when an OTP is invalid because in these
case, the `_l10n_sa_call_api` return the response_data directly.

This fix improves the behavior by displaying a user-friendly alert
message with the error returned by ZATCA, instead of a traceback.

This ensures a better experience and compliance with CCSID onboarding flows.

opw-4838542

Forward-Port-Of: odoo/odoo#215131
Forward-Port-Of: odoo/odoo#214391

In certain cases, the unit price value on a partial credit note does not match the unit price on the corresponding invoice This commit solves this issue by using a more precise price subtotal in XML numbers calculations task-4877278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215483 Forward-Port-Of: odoo/odoo#214844

In certain cases, the unit price value on a partial credit note does not match the unit price on the corresponding invoice
This commit solves this issue by using a more precise price subtotal in XML numbers calculations

task-4877278




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

Forward-Port-Of: odoo/odoo#215483
Forward-Port-Of: odoo/odoo#214844

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

In the Datev standard export, sales with foreign currency and currency indicator are exported to the wrong column. Steps to reproduce: - With a DE Company - Open Accounting / Reporting / Audit Reports / General Ledger - Click "Datev Data (ZIP)" - Open EXTF_accounting_entries.csv According to the documentation https://apps.datev.de/help-center/documents/1003221 Chapter 3. when a journal entry is in a foreign currency: - The amount in foreign currency should go into Column B - The c

In the Datev standard export, sales with foreign currency and currency indicator are exported to the wrong column.

Steps to reproduce:
- With a DE Company
- Open Accounting / Reporting / Audit Reports / General Ledger
- Click "Datev Data (ZIP)"
- Open EXTF_accounting_entries.csv

According to the documentation
https://apps.datev.de/help-center/documents/1003221 Chapter 3. when a journal entry is in a foreign currency:

- The amount in foreign currency should go into Column B
- The currency code should go into Column C
- The base currency amount (i.e. the company's local currency) should be shown in Columns E and F

opw-4701001

Forward-Port-Of: odoo/enterprise#87786
Forward-Port-Of: odoo/enterprise#87002

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

Currently when using Fiskaly, the receipt gets printed with the technical names of the tss values. Steps to reproduce: ------------------- * Set up the db to use fiskaly * Open restaurant * Place and pay an order > Observation: On the receipt screen the name of the tss values are shown as: transaction_number, signature_algorithm, client_serial_number, .... Why the fix: ------------ Beore this commit https://github.com/odoo/enterprise/commit/d1a94147060083da54f9423f8c379676fbb7db66#

Currently when using Fiskaly, the receipt gets printed with the technical names of the tss values.

Steps to reproduce:
-------------------
* Set up the db to use fiskaly
* Open restaurant
* Place and pay an order
> Observation: On the receipt screen the name of the tss values are shown as:
transaction_number, signature_algorithm, client_serial_number, ....

Why the fix:
------------
Beore this commit https://github.com/odoo/enterprise/commit/d1a94147060083da54f9423f8c379676fbb7db66#diff-960ffa6839618d084dd5de6e29458ef68766a31250fc7d296512ec5358f04056 we were using a dictionnary `name, value` when using tss information, cf `_initTssInformation()` in `l10n_de_pos_cert/static/src/overrides/models/models.js`.

We re-introduce this behavior and revert the following commit https://github.com/odoo-dev/enterprise/commit/9f75e3fe092bd838fffb11a35a8d854afff71869 to use the official names instead of the technical ones.

opw-4822342

Forward-Port-Of: odoo/enterprise#88179
Forward-Port-Of: odoo/enterprise#87717

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

Steps to reproduce: - Install payroll, l10n_mx_hr_payroll (mexican localisation) - Install l10n_mx_hr_payroll_account - Switch to a Mexican Company - Create a payslip for a mexican employee with amount < 4000 - Compute the sheet for the payslip Error message appears, this error message is not a descriptive to the user or not telling what could have gone wrong. This happens because the mexican pay structure has some salary rules that has to be computed, one of these rules is `Retiremen

Steps to reproduce:
- Install payroll, l10n_mx_hr_payroll (mexican localisation)
- Install l10n_mx_hr_payroll_account
- Switch to a Mexican Company
- Create a payslip for a mexican employee with amount < 4000
- Compute the sheet for the payslip

Error message appears, this error message is not a descriptive to the
user or not telling what could have gone wrong. This happens because
the mexican pay structure has some salary rules that has to be
computed, one of these rules is `Retirement, assault in elderly and
old age (CEAV) IMSS (Employer)` that has mode of code. This mode means
calling safe_eval on the code raw text of it written in the xml file
on the data folder. This rule aims to find the suitable taxation level
to be applied on the salary. It reads the limits of each level and
check if the `integrated_daily_wage` of the employee falls in this
level and applies that taxation level. There is no upper limit on the
salary, But there is a min level, hence if the integrated_daily_wage
< mdw (minimum daily wage) the function returns None that used as
index in the taxation table leading to an unreadable Exception from
the safe_eval call.

https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/l10n_mx_hr_payroll/data/salary_rules/hr_salary_rule_regular_pay_data.xml#L1111-L1120

opw-4576482

Forward-Port-Of: odoo/enterprise#87502
Forward-Port-Of: odoo/enterprise#83364

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

The default_get method of the 'l10n_uk.hmrc.send.wizard' model assumed the presence of 'client_data' in the context, leading to a KeyError during test_display_name_new_record. This fix checks for the presence of 'client_data' before attempting to call import_vat_obligations. If 'client_data' is not present, it avoids calling import_vat_obligations and raises a UserError, thus preventing the KeyError. build_error-115767 Forward-Port-Of: odoo/enterprise#88297 Forward-Port-Of: odoo/enter

The default_get method of the 'l10n_uk.hmrc.send.wizard' model assumed
the presence of 'client_data' in the context, leading to a KeyError
during test_display_name_new_record.

This fix checks for the presence of 'client_data' before attempting to
call import_vat_obligations. If 'client_data' is not present, it avoids
calling import_vat_obligations and raises a UserError, thus preventing the KeyError.

build_error-115767

Forward-Port-Of: odoo/enterprise#88297
Forward-Port-Of: odoo/enterprise#84327

- We authorize to make payments for orders coming from Urban Piper. - After updating the order as paid, we send it to the pos_blackbox_be. task-id: 4781945 community PR: https://github.com/odoo/odoo/pull/214861 Forward-Port-Of: odoo/enterprise#87989

- We authorize to make payments for orders coming from Urban Piper.
- After updating the order as paid, we send it to the pos_blackbox_be.

task-id: 4781945

community PR: https://github.com/odoo/odoo/pull/214861

Forward-Port-Of: odoo/enterprise#87989

This commit resolves a UI bug in chart trendlines by ensuring AxisType is properly passed from the web client to Odoo charts. Task: [4743602](https://www.odoo.com/odoo/2328/tasks/4743602) Forward-Port-Of: odoo/enterprise#87936

This commit resolves a UI bug in chart trendlines by ensuring AxisType is
properly passed from the web client to Odoo charts.

Task: [4743602](https://www.odoo.com/odoo/2328/tasks/4743602)

Forward-Port-Of: odoo/enterprise#87936

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

Before this PR: - Fields `l10n_in_exception`, `l10n_in_gst_return_period_id`, and `l10n_in_gstr2b_reconciliation_status` were copied when duplicating records. - The field label for GSTR-2B status was shown as just "Status", which could be ambiguous. After this PR: - Added `copy=False` to all three fields to prevent unintended data duplication. - Updated the label "Status" to "GSTR-2B Status" in `l10n_in.gst.return.period` to make the purpose clear. OPW: 4882698 Forward-Port-Of: odoo/e

Before this PR:
- Fields `l10n_in_exception`, `l10n_in_gst_return_period_id`, and `l10n_in_gstr2b_reconciliation_status` were copied when duplicating records.
- The field label for GSTR-2B status was shown as just "Status", which could be ambiguous.

After this PR:
- Added `copy=False` to all three fields to prevent unintended data duplication.
- Updated the label "Status" to "GSTR-2B Status" in `l10n_in.gst.return.period` to make the purpose clear.

OPW: 4882698

Forward-Port-Of: odoo/enterprise#88336
Forward-Port-Of: odoo/enterprise#88110