A new automated check verifies that website rental periods are calculated correctly from selected dates. This helps prevent customers from seeing or being charged for the wrong rental duration, such as a two-day rental being counted incorrectly.

Adds a tour that ensure date-based rental durations are set correctly, i.e. renting from 2025-01-01 to 2025-01-02 should result in a rental period of 2 days.

This should prevent commits like 574e111 (reverted by 5982e11) from introducing faulty logic.

This fix makes the Web Studio report editor test flow wait until the page is ready before checking results. It reduces random test failures, helping keep development and release validation more stable.

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

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

When there is invalid characters in the field, sending may lead to unexpected behaviour. normalize and keep only the first one Task-id: 4894083 Forward-Port-Of: odoo/odoo#215679 Forward-Port-Of: odoo/odoo#215580

When there is invalid characters in the field, sending may lead to unexpected behaviour.
normalize and keep only the first one

Task-id: 4894083

Forward-Port-Of: odoo/odoo#215679
Forward-Port-Of: odoo/odoo#215580

<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

Steps to reproduce: 1. Set company warehouse to two-step manufacturing. 2. Create products: X, A, B, C. 3. Add on-hand quantities: A = 10, C = 5. 4. Create a BOM for X with A and B as components. 5. Create and confirm a MO for X in the two-step warehouse. 6. Check product B's forecast report → shows -1. 7. Add a reordering rule for B → forecast shows -1. 8. Edit X’s BOM: remove B and add C instead. 9. Update the MO using the `update_bom` button. 10. Check MO components. 11. Check WH/P

Steps to reproduce:
1. Set company warehouse to two-step manufacturing.
2. Create products: X, A, B, C.
3. Add on-hand quantities: A = 10, C = 5.
4. Create a BOM for X with A and B as components.
5. Create and confirm a MO for X in the two-step warehouse.
6. Check product B's forecast report → shows -1.
7. Add a reordering rule for B → forecast shows -1.
8. Edit X’s BOM: remove B and add C instead.
9. Update the MO using the `update_bom` button.
10. Check MO components.
11. Check WH/Preprod transfer → B is still there.
12. Re-check steps 6 and 7.

**Issue**:
In two-step manufacturing, two stock moves are created:
- move1: WH/Stock → WH/Preprod
- move2: WH/Preprod → Virtual/Production

The forecast report uses the company warehouse (WH) as the
location domain and includes move2. It calculates:
  forecast = qty_available - demand = 0 - 1 = -1

The reordering rule uses WH/Stock (its default location) and
includes move1, resulting in the same forecast: -1.

After updating the BOM to remove B:
- move2 is deleted correctly.
- move1 remains on the pre-production transfer.

This causes an inconsistency:
- Forecast report (based on move2) → shows 0
- Reordering rule (based on move1) → still shows -1

We set the product_uom_qty to 0 of the prepoduction moves
so procurement runs with negative qty move and it is merged
with the existing ones in the preproduction picking.
This will make the moves in the preprod picking be 0 and not
deleted to avoid deleting manually added moves from the client
in the preproduction picking.

**Limitation**
The current setup will update the pre_prod_pick moves with
0 demand, but for the post_prod_pick moves there is no pull rule
that will trigger a procurement with -ve old demand to update
the post_prod_pick move leaving it not updated to the bom changes.

This will not be an issue in 18.0+ because of changing to push rules
as the post_prod_pick will not be there unless the MO is done, so
BoM updates will not be needed to be reflected.

opw-4746230

Forward-Port-Of: odoo/odoo#209642

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

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

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

Exemple of steps: - Install `crm` - Open crm with pivot view - Click on '+' on a stage, exemple: "Proposition" There is a dropdown with other sub-dropdown, If we go to a sub-dropdown for the first time it is displayed correctly but the second time it is displayed with a wrong position (on the parent dropdown). The problem occurs because the `batchedUpdate` function doesn't wait for the element to be displayed before updating its position. In our case, the dropdown didn't have time to h

Exemple of steps:
- Install `crm`
- Open crm with pivot view
- Click on '+' on a stage, exemple: "Proposition"

There is a dropdown with other sub-dropdown,
If we go to a sub-dropdown for the first time it is displayed correctly but the second time it is displayed with a wrong position (on the parent dropdown).

The problem occurs because the `batchedUpdate` function doesn't wait for the element to be displayed before updating its position. In our case, the dropdown didn't have time to have its position adjusted because the batch was called too early.
opw-4493236

Forward-Port-Of: odoo/odoo#214139

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

### Steps to reproduce: - Ensure Recruitment and Referral modules are installed - Create a job application and set a value in source field - Save and notice the source field got deleted ### Cause: This is happening as in hr_referral we are setting the source_id to be the referral user's source. https://github.com/odoo/enterprise/blob/18cc5b67095d304d514a362c5f02d8426b4a3697/hr_referral/models/hr_applicant.py#L65-L67 ### Fix: If there is not referral user we should keep the value

### Steps to reproduce:
	- Ensure Recruitment and Referral modules are installed
	- Create a job application and set a value in source field
	- Save and notice the source field got deleted

### Cause:
This is happening as in hr_referral we are setting the source_id to be the referral user's source.

https://github.com/odoo/enterprise/blob/18cc5b67095d304d514a362c5f02d8426b4a3697/hr_referral/models/hr_applicant.py#L65-L67

### Fix:
If there is not referral user we should keep the value set by the user and not override it with False

opw-4677023

Forward-Port-Of: odoo/enterprise#83036

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