Steps:
- Create a price list (or existing one)
- Create (or find) a product with only one variant
- Add price list rule for that variant (Should show as Variant:... in Pricelist listing)
- Go to pricelist listing, select the pricelist
- Edit price list rule - Remove the product
- Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id)

Related ticket:
opw-5411034

(Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view)

Description of the issue/feature this PR addresses:
Fix corrupted data
<img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/961e75f8-b2a6-4812-a0b4-d73e02d52b08" />

Current behavior before PR:
product_tmpl_id set to None
product_id / applied_on data stays the same

Desired behavior after PR is merged:
When product_tmpl_id is removed, reset the applied_on type back to 3_global

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

Forward-Port-Of: odoo/odoo#250531
Forward-Port-Of: odoo/odoo#249417

…bcontracted

**Problem:**
Landed cost added on the receipt of a subcontracted product
do not increase the valuation of the product and do not create 
account move lines.

**Steps to reproduce:**
- create a tracked product with avco perpetual category
- create a subcontracted bom for this product with no comp
- create and confirm a PO for 10 unit of this product at a unit price 
of 1$ with the same partner as the subcontractor of the bom
- validate the receipt
- navigate to inventory/operations/adjustments/landed costs
- create a new landed cost
- select the receipt from the PO
- add a landed cost of 10$ and validate
- navigate to inventory/reporting/stock
- search for your product and click on the unit cost

**Current behavior:**
1) the valuation of the product was not increased by the value 
of the landed cost
2) open journal items : no account move lines were created for the 
landed cost

**Expected behavior:**
1) the valuation of the product should have been increased:
in the unit cost view, the SBC move should have gone from a 
value of 10 to 20
2) account move lines should have been created with a value 
of 10

**Cause of the issue:**
both issues come from the fact that when creating the 
stock valuation adjustment line, the move linked is the receipt move
when it should be the move of the subcontracted MO linked to the 
receipt.

**fix:** 
if we create the adjustement line with move_id as the move of the MO
(instead of the move of the receipt as it is the case currently) : 
when button_validate is called on the landed cost : 
- when using the remaining quantity, it will be the correct one 
(in our case 10, instead of 0 for the move of the receipt because it's 
actually an internal move) so the account move line are going to 
be created
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L129-L130
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L372-L373
which solves problem 2) 

-  when calling _set_value on the move (which will be the move of 
the MO thanks to this fix), 
https://github.com/odoo/odoo/blob/064407d32f998ceb08601f9e0a6356c94ad10347/addons/stock_landed_costs/models/stock_landed_cost.py#L152
get_value_data will call _get_value_from_extra,
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_account/models/stock_move.py#L392
which uses _get_landed_cost to fetch the landed cost
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L18
before this fix the landed cost created from the receipt were linked to 
the receipt move so they were not fetched inside _get_landed_cost
which caused problem 1) but now the move_id of the adjustment lines 
is the move of the MO so they are fetched inside _get_landed_cost
https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L7-L12
So now the adjustment lines do impact the valuation of the move of 
the MO which solves problem 1)

opw-5723126

Forward-Port-Of: odoo/odoo#248469

Steps to reproduce:
1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty).
2. Create a Manufacturing Order (MO) for the product selecting BoM A.
3. Switch BoM A to BoM B, then switch back to BoM A.
4. Modify the production quantity field. -> New operation lines are appended every time the quantity is changed.

The issue occurred because _compute_workorder_ids used 'wo.ids' to filter existing workorders. In the "Draft" state (UI/onchange), records exist as "virtual records" (NewIds). For these records, .ids returns an empty list [], which evaluates to False in Python.
Consequently, the existing virtual workorders were filtered out of the dictionary used to map operations to existing lines. The logic assumed the lines didn't exist and used Command.create() instead of Command.update(), causing duplication. Similar issues existed where 'NewIds' were ignored during BoM swaps, leaving "phantom" records in the cache.

Solution:
Removing the '.ids' check and using '.mapped('id')' ensures the computation remains "virtual-aware" and stable across sequential onchanges.

TECHNICAL JUSTIFICATION:
In Odoo 18.0, the ORM explicitly supports using Command.update and Command.delete with virtual records (NewIds) without an origin. This is handled by the 'write_new' method in relational fields:
- Virtual browse wraps IDs in NewId: https://github.com/odoo/odoo/blob/f688c6b66310438fa3e36a207770a63d0d8fffa5/odoo/fields.py#L4826-L4855

opw-5489862

Forward-Port-Of: odoo/odoo#246995

**Problem:**
When Billing a dropshipped PO, if the price of the bill 
is changed from the price of the Purchase Order,
the standard price of the product is not updated

**Steps to reproduce:**
- enable the dropshipping settings
- create a storable product with avco perpetual category
- in the inventory tab, select the dropship route
- in the purchase tab, set a vendor
- create and a confirm a quotation for this product
- on the linked purchase order, set a unit price of 100$ and 
confirm
- validate the dropship move
(- you can check on the product form that the standard price 
is now 100$)
- create a bill for the purchase order
- set the price to 90$ and confirm
- navigate to the product form

**Current behavior:**
The standard price is still 100$

**Expected behavior:**
It should be 90$

**Cause of the issue:**
When we validate the picking, action_done() is called on the moves .
Inside the action_done() override of stock_account, 
after the call to super, set_value is called on is_in 
and is_dropship moves 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L168-L169

Inside _set_value(), 
because the move is dropship, it's going to be added to 
products_to_recompute 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L277-L278

and then we're going to exit this iteration of the for loop. 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L285-L286
so basically we simply call the _update_standard_price() on the product.
https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/stock_move.py#L310
Because the product is avco, _update_standard_price is going to call _run_average_batch 
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/product.py#L541

The value is not set on the dropship move but it's still used in the computation because for dropship move, we use _get_value()
https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/product.py#L382-L383
which will take into account the bills and POs if there are some.

But the problem is that, when we post the invoice we only call set_value on is_in moves
https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/account_move.py#L42
So the standard price of our dropshipped product is not updated.

opw-5498878

Forward-Port-Of: odoo/odoo#250067

How to reproduce
------
1. Open the Marketing Automation app
2. Create a new campaign
3. Click on Add new activity to create a new activity (in the previously created campagin)
4. Set the Activity Type to email
5. In the Mail Template option, select or create a mailing
6. Open the selected/created mailing (using the Templates smart button)
7. Click on the gear icon and then click Delete (either one or multiple together)

DEMO: https://www.awesomescreenshot.com/video/50021531?key=18a341a6939e6ff8deb847fc251db570

Current behavior
-----
Odoo Server Error is displayed.

Expected behavior
------
Normal user error indicating that the mailing(s) being deleted is still linked to an activity (or marketing campaign).

Cause
------
When formatting the user error, we used the attribute `name`, to
get the mailing's display name, which does not exist in `mailing.mailing`
model. Therefore, a KeyError is raised.
The `name` attribute was an attribute in a class named `UtmSourceMixin` in
the utm module, of which `mailing.mailing` was inheriting. In saas-19.2,
that class was removed and hence the `name` is no longer available for
`mailing.mailing`.
The commit in which the metioned class was removed is:
https://github.com/odoo/odoo/commit/93f8bb821ab86612d95d93ae0fdca5a08a12e2d5
(See utm_source.py)

Solution
------
Change the `name` to `mailing.display_name`.
DEMO: https://www.awesomescreenshot.com/video/50049334?key=a34a525ef38bdf2dc8037f2dcfa68761

task-5999999

### Description of the issue/feature this PR addresses:
A regression in account_edi_xml_ubl_bis (_ubl_get_delivery_node_from_delivery_address) references invoice.invoice_date in the intracom delivery branch even when invoice is not set.
This method is also used in sale-order UBL export flows (for example during quotation PDF generation from mail.compose.message), where vals.get('invoice') can be None.
Blame points to regression introduction in commit 0bf8df7d0a096cf8fe984c42d331404d473eeb71 (FP from f6c5aed52e00e807c4879e4139b116f1bea8282e).

### Current behavior before PR:
When the flow reaches sale-order BIS3 export without an invoice in vals, Odoo crashes with:

AttributeError: 'NoneType' object has no attribute 'invoice_date'

This raises an RPC_ERROR and breaks the mail composer / send flow

### Desired behavior after PR is merged:
The intracom delivery-date override is only applied when invoice exists and has invoice_date.
If invoice is missing (sale-order export context), no crash occurs, the delivery node is still generated safely, and mail composer/report generation completes normally.
Invoice export behavior remains unchanged for valid invoice contexts.



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

Forward-Port-Of: odoo/odoo#250167

The rounding of time was not correct. I was always flooring, but before
the new duration the rounding was depending of the precision of the
duration. The rounding has been restored as before and put in
formatDuration.
formatFloatTime has been modified to use formatDuration and now take
the same options (specify the unit of time of the value).

The graph view and list view didn't extract the otpions from the fields
with widget. Now, they get the options and give them to the formatter.

The widget was showing the seconds by default, but it doesn't match with
the behavior of the DateTime widget. It has been changed and now the seconds
are shown only if the options 'showSeconds' is true and it's false by default.
The impacted views has been restored as before the original commit.

The options of float_time widget couldn't take falsy values, now it can.

an improvment has also been done: the popover on the float_time widget
doesn't show up if the input value and the formattedValue are the same.

followup of TASK-5347051

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

The rounding of time was not correct. I was always flooring, but before
the new duration the rounding was depending of the precision of the
duration. The rounding has been restored as before and put in
formatDuration.
formatFloatTime has been modified to use formatDuration and now take
the same options (specify the unit of time of the value).

The graph view and list view didn't extract the otpions from the fields
with widget. Now, they get the options and give them to the formatter.

The widget was showing the seconds by default, but it doesn't match with
the behavior of the DateTime widget. It has been changed and now the seconds
are shown only if the options 'showSeconds' is true and it's false by default.
The impacted views has been restored as before the original commit.

The options of float_time widget couldn't take falsy values, now it can.

an improvment has also been done: the popover on the float_time widget
doesn't show up if the input value and the formattedValue are the same.

followup of TASK-5347051

Steps to reproduce
===============
1. Open appointment of resource type
2. Create a new resource from resource tags.
3. Give the resource a name and save.
----> ValidationError will be shown.

Issue
=====
When creating the new resource from the appointment form view, the value for the `tz`
of the `appointment.resource` is `False`. Also, `tz` field is inherited from `resource.mixin`
and is a related field as `resource_id.tz`. Therefore, when creating the `appointment.resource`
with `tz` as `False` writes the related `resource.resource`'s `tz` field. As `tz` field is
required field for the `resource.resource` table, the `ValidationError` is raised.

Solution
=======
After this commit, we give the default value to the timezone with fallback to current
user's timezone or UTC which matches to the default value of `resource.resource`'s timezone field but
with a side-effect of overwriting resource's timezone if somehow `default_resource_id` is provided.

We also fix in parallel by making the timezone field `readonly` when invisible to avoid "saving" the
`False` value for the tz.

Task-5712786

You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected.

Steps to reproduce
1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b),
model_b.x_studio_test(relation=other_model)`.
2. Create a related field on model_a and click the related icon for the test field.
3. The popover will now be displaying the fields for other_model instead of model_b.

Cause:
This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). 

Solution:
Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`.

opw-ticket 5459944

Forward-Port-Of: odoo/odoo#249185

Steps:
- Create a price list (or existing one)
- Create (or find) a product with only one variant
- Add price list rule for that variant (Should show as Variant:... in Pricelist listing)
- Go to pricelist listing, select the pricelist
- Edit price list rule - Remove the product
- Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id)

Related ticket:
opw-5411034

(Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view)

Description of the issue/feature this PR addresses:
Fix corrupted data
<img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/961e75f8-b2a6-4812-a0b4-d73e02d52b08" />

Current behavior before PR:
product_tmpl_id set to None
product_id / applied_on data stays the same

Desired behavior after PR is merged:
When product_tmpl_id is removed, reset the applied_on type back to 3_global

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

Forward-Port-Of: odoo/odoo#250531
Forward-Port-Of: odoo/odoo#249417

Steps to reproduce:
1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty).
2. Create a Manufacturing Order (MO) for the product selecting BoM A.
3. Switch BoM A to BoM B, then switch back to BoM A.
4. Modify the production quantity field. -> New operation lines are appended every time the quantity is changed.

The issue occurred because _compute_workorder_ids used 'wo.ids' to filter existing workorders. In the "Draft" state (UI/onchange), records exist as "virtual records" (NewIds). For these records, .ids returns an empty list [], which evaluates to False in Python.
Consequently, the existing virtual workorders were filtered out of the dictionary used to map operations to existing lines. The logic assumed the lines didn't exist and used Command.create() instead of Command.update(), causing duplication. Similar issues existed where 'NewIds' were ignored during BoM swaps, leaving "phantom" records in the cache.

Solution:
Removing the '.ids' check and using '.mapped('id')' ensures the computation remains "virtual-aware" and stable across sequential onchanges.

TECHNICAL JUSTIFICATION:
In Odoo 18.0, the ORM explicitly supports using Command.update and Command.delete with virtual records (NewIds) without an origin. This is handled by the 'write_new' method in relational fields:
- Virtual browse wraps IDs in NewId: https://github.com/odoo/odoo/blob/f688c6b66310438fa3e36a207770a63d0d8fffa5/odoo/fields.py#L4826-L4855

opw-5489862

Forward-Port-Of: odoo/odoo#246995

*: purchase_stock

Issue Before This Commit:
======================
In a `multi-step` configuration, while validating a transfer that has no `stock reference`, its next operation (Input → QC → Stock) is merged into an existing transfer that also lacks a stock reference, even when the transfers are manually
created and not generated from a Sales or Purchase Order. This results in unrelated transfers being grouped together.

Steps to Reproduce:
======================
- Install the `stock` module.
- Configure the warehouse to use `three-step reception`.
- Create and validate two receipts for Product A (qty 10) with Vendor A.
- `Observation`: the next transfers for both receipts are merged into a single transfer, even though both receipts were        
     created manually and not generated from any same source document like PO/SO.

Cause of the Issue:
======================
In the `_search_picking_for_assignation()` method, when no `stock.reference`is defined on a move, the system still attempts to find an existing picking using the `partner_id`. Additionally, in the `_key_assign_picking()` method, moves
without a `reference_ids` are grouped based on their `partner_id`. As a result, validating multiple manually created receipts sharing the `same vendor` causes them to be incorrectly merged into the `same next transfer`, since they do not share a common stock reference.

After this Commit:
======================
The `_search_picking_for_assignation()` method now skips searching for existing pickings when moves lack a `stock.reference`. The `_key_assign_picking()` method groups moves by their `originating picking` instead of the partner, preventing merges between unrelated transfers without a stock reference. This ensures each manual transfer creates its `own next operation` in multi-step routes.

Task-ID: 5242340

Forward-Port-Of: odoo/odoo#250385
Forward-Port-Of: odoo/odoo#235423

### Description of the issue/feature this PR addresses:
A regression in account_edi_xml_ubl_bis (_ubl_get_delivery_node_from_delivery_address) references invoice.invoice_date in the intracom delivery branch even when invoice is not set.
This method is also used in sale-order UBL export flows (for example during quotation PDF generation from mail.compose.message), where vals.get('invoice') can be None.
Blame points to regression introduction in commit 0bf8df7d0a096cf8fe984c42d331404d473eeb71 (FP from f6c5aed52e00e807c4879e4139b116f1bea8282e).

### Current behavior before PR:
When the flow reaches sale-order BIS3 export without an invoice in vals, Odoo crashes with:

AttributeError: 'NoneType' object has no attribute 'invoice_date'

This raises an RPC_ERROR and breaks the mail composer / send flow

### Desired behavior after PR is merged:
The intracom delivery-date override is only applied when invoice exists and has invoice_date.
If invoice is missing (sale-order export context), no crash occurs, the delivery node is still generated safely, and mail composer/report generation completes normally.
Invoice export behavior remains unchanged for valid invoice contexts.



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

Forward-Port-Of: odoo/odoo#250167

Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises

    ValueError: bad delimiter or lineterminator value

This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:

> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.

so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.

Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.

https://runbot.odoo.com/odoo/error/240950

Forward-Port-Of: odoo/enterprise#109081

Steps to reproduce:
1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty).
2. Create a Manufacturing Order (MO) for the product selecting BoM A.
3. Switch BoM A to BoM B, then switch back to BoM A.
4. Modify the production quantity field. -> New operation lines are appended every time the quantity is changed.

The issue occurred because _compute_workorder_ids used 'wo.ids' to filter existing workorders. In the "Draft" state (UI/onchange), records exist as "virtual records" (NewIds). For these records, .ids returns an empty list [], which evaluates to False in Python.
Consequently, the existing virtual workorders were filtered out of the dictionary used to map operations to existing lines. The logic assumed the lines didn't exist and used Command.create() instead of Command.update(), causing duplication. Similar issues existed where 'NewIds' were ignored during BoM swaps, leaving "phantom" records in the cache.

Solution:
Removing the '.ids' check and using '.mapped('id')' ensures the computation remains "virtual-aware" and stable across sequential onchanges.

TECHNICAL JUSTIFICATION:
In Odoo 18.0, the ORM explicitly supports using Command.update and Command.delete with virtual records (NewIds) without an origin. This is handled by the 'write_new' method in relational fields:
- Virtual browse wraps IDs in NewId: https://github.com/odoo/odoo/blob/f688c6b66310438fa3e36a207770a63d0d8fffa5/odoo/fields.py#L4826-L4855

opw-5489862

Forward-Port-Of: odoo/odoo#246995

### Issue:
When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app.

### Steps to reproduce:
- Have a payslip run with payslips
- Go to a payslip, validate and generate the document
- Then cancel and reset to draft
- Reset the Payslip Run to draft
- Delete it
- Open the Documents app

### Cause:
The payslips are linked to the run with a `ondelete='cascade'` relation. 

https://github.com/odoo/enterprise/blob/03b2a7dae0e5c5ad3142ec2da8f3de5c9b1957f4/hr_payroll/models/hr_payslip.py#L110-L113

This means that deleting the run also deletes its payslips on a database level, bypassing the ORM. As the document is not directly linked by a relational field but instead by `res_model` and `res_id`, these fields are not updated and therefore are still pointing to a record that is no longer in DB.

### Solution:
Extend the `unlink()` method in `hr.payslip.run` and unlink the documents there.

opw-5501061

Forward-Port-Of: odoo/enterprise#105969

The PR is the enterprise counterpart of https://github.com/odoo/odoo/pull/250051

Here is the original message:
The commit aims to improve the UX on touch screens, by improving
inputs and buttons design to make them more usable on those touch
oriented devices first by giving more space around certain elements
and making other UI elements more compact to give the user more
information. As a side effect, this task also allowed to improve the
desktop experience regarding suffixes and to unify the look and
feel of text inputs.

A dedicated o_input_box class has been added. Being used at the highest
level on an input/button element or its parent in the UI, it can be used
to add overlay prefix and/or suffix inside of them, using on those UI
elements the 'o_input_box_overlay + prefix/suffix' classnames.

For example:
```
<div class='o_input_box'>
    <i class='fa fa-gear o_input_box_overlay prefix'/>
    <input class='o_input'/>
    <button class='btn btn-link o_input_box_overlay suffix'>Click Me</button>
    <i class='fa fa-arrow o_input_box_overlay suffix'/>
</div>
```

In this example, an input box would be display around the input, with
enough padding before and after the input value, displaying 2 icons
and a button.

Currently, positioning the overlay elements require to call the dedicated
utility function, exported from '/web/static/src/core/input_box.js'.
Padding is then calculated and adapted accordingly to maintain affordance
of the input or button text, and place the dropdown arrow.

An InputBox component has been added as well, implementing easily the right
elements around an input, but it is possible to use the classnames without
the need for this specific component.

If an element with o_input_box is contained inside another o_input_box
parent, the highest element is considered as the input box, and displayed
correctly. This allows a component that already have the class to have a
sibling element serving as an overlay, by adding a parent to both elements
having the o_input_class. It is also useful when some UI is declared from
the arch XML while other overlays are defined from the component side.

This commit also removes the need of a dedicated component for the boolean
toggle field in list views. The edition of any boolean field in
readonly/non selected rows in list views is already well handled in a
scss rule, and it is not necessary to have this dedicated wrapper around
the standard BooleanToggleField component.

task-5355007

Steps to reproduce:
1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse).
2. Generate a payslip for this employee.
3. Print the payslip (PDF) or generate a payment export (SEPA, NACHA, ABA, CSV).
4. Observe that the employee's name is displayed instead of the account holder's information.

Issue:
Payroll reports and payment exports were frequently hardcoded to use the employee's legal name or work contact ID. This is incorrect when a bank account belongs to a different partner, as payment records should reflect the actual account holder.

Solution:
Unified logic across standard and localized payroll modules (AU, BE, CH, IN, SA, US) to prioritize the bank account's linked partner:
- Updated QWeb templates to display bank.partner_id.name for account allocations.
- Modified payment wizards (CSV, NACHA, ABA, SEPA) to use the bank account's partner ID.
- Ensured a fallback to the employee's legal name remains in place.

opw-5357652

Forward-Port-Of: odoo/enterprise#108785
Forward-Port-Of: odoo/enterprise#106718

Problem:
-------
In several scenarios, Worked Days are incorrectly computed when the employee
has no contract or when the contract does not fully overlap with the payslip
period.

Case 1:
- Create an employee without a contract
- Create a payslip for this employee for the current month:
You'll see X days of attendance (= today until the end of the payslip period)
and Y days of out of contract (= number of days from the start of the payslip period until today)
- Create a payslip for this employee for the previous month:
you'll see ( Z_prev + Y )  days out of contract ( Z_prev = number of working days in the previous month)
- Create a payslip for this employee for the next month:
you'll see Z_next days of attendance (Z_next = number of working days in the next month)

Case 2:
- Create a new employee with a contract starting during the current month
- Create a payslip for this employee for the previous month
- Out-of-Contract days are incorrectly computed as:
  contract_start_date - previous_month_start.

Case 3:
- Create an employee with a contract ending during this month
- Create a payslip for this employee for the next month
- Out-of-Contract days are incorrectly computed as:
  next_month_end - contract_end_date.

Solution:
--------
When generating work days lines:
- Explicitly handle employees without a contract.
- Use adjusted date bounds when the contract does not overlap the payslip
  period.

Several tests were added to cover these scenarios, as well as the tests the corresponding commit
in odoo/odoo (PR odoo: 241978)

task-5430759

Forward-Port-Of: odoo/enterprise#109237
Forward-Port-Of: odoo/enterprise#103207

How to reproduce
------
1. Open the Marketing Automation app
2. Create a new campaign
3. Click on Add new activity to create a new activity (in the previously created campagin)
4. Set the Activity Type to email
5. In the Mail Template option, select or create a mailing
6. Open the selected/created mailing (using the Templates smart button)
7. Click on the gear icon and then click Delete (either one or multiple together)

DEMO: https://www.awesomescreenshot.com/video/50021531?key=18a341a6939e6ff8deb847fc251db570

Current behavior
-----
Odoo Server Error is displayed.

Expected behavior
------
Normal user error indicating that the mailing(s) being deleted is still linked to an activity (or marketing campaign).

Cause
------
When formatting the user error, we used the attribute `name`, to
get the mailing's display name, which does not exist in `mailing.mailing`
model. Therefore, a KeyError is raised.
The `name` attribute was an attribute in a class named `UtmSourceMixin` in
the utm module, of which `mailing.mailing` was inheriting. In saas-19.2,
that class was removed and hence the `name` is no longer available for
`mailing.mailing`.
The commit in which the metioned class was removed is:
https://github.com/odoo/odoo/commit/93f8bb821ab86612d95d93ae0fdca5a08a12e2d5
(See utm_source.py)

Solution
------
Change the `name` to `mailing.display_name`.
DEMO: https://www.awesomescreenshot.com/video/50049334?key=a34a525ef38bdf2dc8037f2dcfa68761

task-5999999

Forward-Port-Of: odoo/enterprise#109400

## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.

<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />

## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
    - Any Customer
    - Any Recurring Plan
    - Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**

## Cause
The title shown in the preview is defined here:

https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195

The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201

The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237

The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.

## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:

https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803

<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />

## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.

opw-5489970

Forward-Port-Of: odoo/enterprise#109268
Forward-Port-Of: odoo/enterprise#106767

## [FIX] sale_renting_planning: fix sync between rental dates and planning slots dates
Before this commit, it was possible to have `Planning Slots`
with `Sync Shifts and Rental Orders` whose dates were different
from the `Rental order`.

This commit makes sure that all dates are always synced:
- If the `Rental Order` dates are changed then all
`Planning Slots`' dates changed to the new dates.
- If a `Planning Slot` dates have changed then all
other `Planning Slots` and the `Rental Order` Dates
are changed to the new dates.

## [FIX] sale_renting_planning: fix sync between order line quantity and planning slots
Before this commit, adding/removing a `Planning Slot` would not
change the `SOL quantity` and changing the `SOL quantity` would not
add/remove `Planning Slots` unless all slots are being deleted.

This commit makes sure that when the `SOL quantity` is
changed, the number of `Planning Slots` is changed accordingly,
and if a Planning Slot` was added/removed, the `SOL quantity`
would update accordingly.

Note: The new sync behaviour from `SOL quantity` is ignored for
`Products` with `hour UOM` because it is not clear yet how to update
the `Planning Slots` if the new quantity of hours doesn't span a full
rental interval.

## [FIX] sale_renting_planning: fix set multiple slots to resources
Before this commit, adding multiple `Planning Slots` at the
same time with the same `Role` can assign them to the same
`Resource` even if they conflict with each other.

This commit makes sure that when adding multiple `Planning Slots`
none of them would conflict with each other after being added.

task-5187356

Forward-Port-Of: odoo/enterprise#104771

**Steps to Reproduce:**
1. Open Payroll->Payslips->Pay Runs
2. Click on a Pay Run in Mobile View (Width < 600px).
3. Return to the previous view using the breadcrumb.
4. The system crashes with Traceback: TypeError: Cannot set properties of null (setting 'scrollLeft')

**Bug Cause:**
The custom 'hr_payroll.PayrunKanbanRenderer' template overrode the 'class' attribute of the root div. By setting it only to 'o_payrun_kanban', the standard 'o_renderer' class was removed. The Kanban controller's scroll restoration logic (introduced in recent lazy-loading updates) relies on the '.o_renderer' selector to find the scrollable container. When missing, querySelector returns null, leading to a traceback.

**Solution:**
Updated the XML template to explicitly include 'o_renderer' in the class list. This restores the functional hook required by the JavaScript controller for scroll restoration while maintaining the custom 'o_payrun_kanban' layout.

Task: 5971861

Forward-Port-Of: odoo/enterprise#108847

### Issue:
The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours.

### Steps to reproduce:
- Go to Planning app
- Create a shift for an employee from 3pm to 2am (over two days)
- The hours of the shift are displayed
- Modify the shift end to 3am
- The hours of the shift aren't displayed

### Cause:
Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c).

But as the pills are no longer truncated since 17.0, the computation of pill names is faulty.

### Solution:
We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it.

opw-5881532

Forward-Port-Of: odoo/enterprise#109314
Forward-Port-Of: odoo/enterprise#107233

Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises

    ValueError: bad delimiter or lineterminator value

This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:

> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.

so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.

Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.

https://runbot.odoo.com/odoo/error/240950

Forward-Port-Of: odoo/enterprise#109081

This reverts commit 2b2d73df420baee4fec1c51c28250666d80b48b8.

## How to reproduce (in runbot):
- Create Product P
- Create Delivery transfer from 'WH/Stock/Shelf 1'
- Open Forecast report:
=> RuntimeError: dictionary changed size during iteration

The original fix will be redone in another commit.

---

## Traceback:
```
  File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 21, in get_report_values
    'docs': self._get_report_data(product_ids=docids),
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 128, in _get_report_data
    res['lines'] = self._get_report_lines(product_template_ids, product_ids, wh_location_ids, wh_stock_location)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 359, in _get_report_lines
    for product_id, location_id in currents:
RuntimeError: dictionary changed size during iteration
```

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

Forward-Port-Of: odoo/odoo#251768

…lues landed cost sbc

**Problem:**
account move line created from a landed cost on a  subcontracted 
receipt do not take into account already out quantity.

**Steps to reproduce:**
- create a tracked product with avco auto category
- create a subcontracted bom for this product with no comp
- create and confirm a PO for 10 unit of this product 
with the same partner as the subcontractor of the bom
- validate the receipt
- create and validate a delivery for 4 unit of your product
- navigate to inventory/operations/adjustments/landed costs
- create a new landed cost
- select the receipt from the PO
- add a landed cost of 10$ and validate
- select the valuation smart button
- a 6$ svl was created (which is correct because 6 out 10 products
of the receipt are still in stock)
- click on the book widget to open the account move view

**Current behavior:**
Only two account move lines were created both with a value 
of 10
One crediting sotck interim received
On debiting stock valuation

**Expected behavior:**
4 extra account move lines (all with a value of 4) should have been 
created to compensate the out quantity like it is the case for 
non subcontracted product.
One debiting stock interim delivered
One crediting stock valuation 
One debiting expenses
One crediting stock interim delivered

**Cause of the issue:**
_is_in() will return false for the move of a subcontracted receipt
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L185
This is wanted and happens because _should_be_valued()
will return true when called on the subcontracted location
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_account/models/stock_move.py#L129

As a consequence, qty_out stays 0
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L185-L186
and we do not append the values for the extra amls 
inside _create_account_move_line()
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L465-L466

**fix:**
if we make sure the the adjustment line is linked to the move 
of the MO instead of the move of the receipt, this problem does 
not happen because _is_in() returns true for the move of the MO. 
Also in this case we don't need _get_stock_valuation_layer_ids()
which was introduced by this PR https://github.com/odoo/odoo/pull/166107
to solve the same issue. 
That is because the move used in button_validate is the move linked
to the adjustment line, which will, after this fix, be the one of 
the MO, so we can directly take its stock valuation layers.

opw-5723126

Issue Before This Commit:
=======================
In the `batch transfer report`, move lines are ordered by the `picking's batch sequence` (picking_id.batch_sequence). When operators use the document to pick items, they have to scan through the report to find all lines for the same product. As a result, operators `lose time scanning the document` and `risk of missing lines`.

Steps to Reproduce:
=======================
- Install the `stock_picking_batch` module.
- Create `multiple deliveries` with several `common products`.
- Add these deliveries to a batch transfer and print the batch transfer report.
- Observe that product lines are ordered by location and then by picking.

Cause of the issue:
=======================
The batch transfer report currently sorts move lines by picking in the report `(picking_id.batch_sequence)`. When the same product exists in another picking, This causes lines for the same product to be scattered across the report instead of being grouped together, causing the product to appear in multiple places in the document.

After This Commit:
=======================
In the report, move line sorting by picking (picking_id.batch_sequence) has been replaced with sorting by product `(product_id.id)`. Move lines are now ordered by product, so similar products are displayed together in the document. This helps operators find products more quickly, reduces scanning effort, and makes the process more reliable.

TaskID-5379367

# Steps to reproduce:
- Open the company, change the language to Arabic
- Go to POS, open the shop
- Buy anything and click on receipt

# Problem:
When clicking on the receipt, you would find the phone number is written right to left, although it should be printed left to right.

# Cause:
Normally when another language is selected, this line will adapt to it, and translate the whole block "Tel: `props.data.company.phone`" to arabic (right to left)
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L12

# Fix:
We need to specify the direction of the phone number to be Left to right.
```
<div>Tel:<span dir="ltr"><t t-esc="props.data.company.phone" /></span></div>
```
**Result:**
<img width="167" height="86" alt="HATEF" src="https://github.com/user-attachments/assets/4fe0bdd0-fe77-430f-9136-cd7086c4d5d9" />

There is also alternative fixes:
# First alternative fix:
Replace the '+' with '00' (there is no difference when trying to copy), and make a function in js that preserve the whole thing in a string variable.
```
    get phoneText() {
        return _t("Tel:") + " " + this.props.data.company.phone.replace("+", "00");
    }
```
**Result:**
<img width="215" height="148" alt="hatef2" src="https://github.com/user-attachments/assets/e9cb4415-baad-4d66-a04b-ecdb308e3e72" />

**Drawback:**
- The inconsistency between how the number is stored and how we view it.

# Second alternative fix:
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.js`
```diff
import { _t } from "@web/core/l10n/translation";
import { Component } from "@odoo/owl";
+ import { localization } from "@web/core/l10n/localization";
```
```diff
+    get direction() {
+        return localization.direction;
+    }
```

**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml`
```diff
                <t t-if="props.data.company.phone">
-                    <div>Tel:<t t-esc="props.data.company.phone" /></div>
+                    <t t-if="direction == 'ltr'">
+                        <div>Tel:<t t-esc="props.data.company.phone" /></div>
+                   </t>
+                    <t t-elif="direction == 'rtl'">
+                       <div><t t-esc="props.data.company.phone" />Tel:</div>
                    </t>
                </t>
```

**Drawback:**
- Too much code for a small issue that probably won't bother the client.
- The need to change in multiple translation files for all RTL languages in odoo.
- Readability


opw-5881503

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

**Problem:**
Searching for text that only exists in a setting's sub-field content (e.g., "qr" matching "Add QR-code link on PDF") fails to find the setting when searching from a different app tab in General Settings. The same search works when already on the correct app tab.

**Steps to reproduce:**
1. Open Settings (General tab is selected)
2. Search for "qr"
3. "Invoice Online Payment" setting is not found
4. Navigate to Accounting settings tab
5. Search for "qr" again
6. Now the setting appears

**Current behavior:**
Settings from non-selected apps are not found when the search term only matches sub-field content (text inside the setting body).

**Expected behavior:**
Search should find settings across all apps regardless of which tab is currently selected.

**Cause of the issue:**
SearchableSetting collects search labels in two phases: the setting's own label and help text during setup(), and sub-field text from span[searchableText] DOM elements during onMounted(). However, visible() is evaluated during render via t-if, which runs before onMounted. When an app first renders due to a search (it was previously unrendered because its tab wasn't selected), visible() only has the incomplete label set and returns false, preventing the setting div from rendering. This creates a chicken-and-egg problem: the DOM needed for label collection never exists because visibility check fails without those labels.

**Fix:**
A reactive labelsReady flag defers visibility filtering until onMounted has had a chance to collect all DOM-based labels. On the initial render, visible() returns true unconditionally so the DOM exists for label collection. The state change then triggers a proper re-render with the complete label set.

opw-5946625