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

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

- Create a product P with a bom with an operation in the Assembly line
- Create and confirm an MO for 1 unit of P
- Open Shop Floor, Mark the operation as Done
- Click on the All MO tab
> The operation was removed from the Assembly line
- Click on "close production"
#### > Nothing happends while the MO should be marked as done and disappear

### Cause of the issue:

The issue has been introduced by commit [1].
To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation:
https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 
Prior to commit [1], in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [1], the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect:
https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 
In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``.

What is true however, is that in the exceptional use case treated in [1] where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`:
https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 
and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)).

### Fix:

The double validation did not happen prior ot the change of [1] because we did not skip redirection at the time:
https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 
returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place:
https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524

Commit [1]: 10ed12241365942914885dff953049303b9ed94f

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

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

Forward-Port-Of: odoo/odoo#214049
Forward-Port-Of: odoo/odoo#212885

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

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

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

### Steps to reproduce:

- Create a product P with a bom with an operation in the Assembly line
- Create and confirm an MO for 1 unit of P
- Open Shop Floor, Mark the operation as Done
- Click on the All MO tab
> The operation was removed from the Assembly line
- Click on "close production"
#### > Nothing happends while the MO should be marked as done and disappear

### Cause of the issue:

The issue has been introduced by commit [X](10ed12241365942914885dff953049303b9ed94f)
To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation:
https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [X](10ed12241365942914885dff953049303b9ed94f), in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit  [X](10ed12241365942914885dff953049303b9ed94f) the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect:
https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``.

What is true however, is that in the exceptional use case treated in commit [X](10ed12241365942914885dff953049303b9ed94f) where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`:
https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)).

### Fix:

The double validation did not happen prior ot the change of commit [X](10ed12241365942914885dff953049303b9ed94f) because we did not skip redirection at the time:
https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place:
https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524

Commit  [X](10ed12241365942914885dff953049303b9ed94f): 10ed12241365942914885dff953049303b9ed94f

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

opw-4800147

Forward-Port-Of: odoo/enterprise#88000
Forward-Port-Of: odoo/enterprise#86905

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