### Issue:
During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up.

### Steps to reproduce:
- Install 'l10n_ar'
- Settings > Accounting
- Make sure the "Fiscal Localization" have a value (not Argentina)
- Change the "Fiscal Localization" to "Argentine - Generic Chart of Accounts [...]"
- Go in Accounting > Configuration > Journals
- Click on "Ventas Preimpreso"
- The journal don't have "Use Documents" ticked but it should

### Cause:
When loading the data, `_get_chart_template_data()` calls `_get_ar_base_res_company()` and `_get_latam_document_account_journal()`.

The first one returns the data to change `res.company.account_fiscal_country_id` to `base.ar`. The second one [checks](https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/addons/l10n_latam_invoice_document/models/account_chart_template.py#L12) that [`self.env.company.account_fiscal_country_id.code == "AR"`](https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/l10n_ar/models/res_company.py#L36) before returning the data to change `l10n_latam_use_documents` to `True`. As `res.company.account_fiscal_country_id` has not been updated, it's not Argentina during the check and `_get_latam_document_account_journal()` returns nothing.

### Solution:
When loading the template, we cannot use `res.company.account_fiscal_country_id` to know if we are in LATAM or not. So instead we check on `chart_template`.

opw-5221931

Forward-Port-Of: odoo/odoo#237725
Forward-Port-Of: odoo/odoo#236217

**Steps to Reproduce:**

1. create test ``Float`` field in model ``A`` with ``digits`` args
2. create ``Many2One`` field with comodel ``A``  and then create Float Field in ``B Model`` with related ``A`` model test and store True

**Issue:**
  1. ``column_type`` for both model table will be different. For ``test field in model A`` the ``column_type`` will be ``numeric``. But for the related field ``column_type`` ``float`` it should be ``numeric``. This happen because the @lazy_propery it hold the ``column_type`` which is ``float8`` and other related attributes from ``setup_related`` before that ``_digits`` have the null value. So, from [here](https://github.com/odoo-dev/odoo/blob/a9398502260fa57573b88fd62ca3f554e0685c7b/odoo/fields.py#L772) it remains ``float8`` it should update with ``numeric``

   **Second issue comes From odoo 18.3**:=

during upgrade if any new ``module`` is intalled due to dependency change and inherits the same model that is ``A``. 
Due to ``_auto_init`` it will recompute this related field  because due to this newly [commit](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808) clear the columns column becomes [``False``] and [``not column``] becomes true  from ``update_db`` and same reason as above  it didn't return from [here](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808#diff-956d895aa67961bac940841f7c3d1e10eb8ecabec82ef017803c4a6a3bb7cd22R1074) because column type is ``float8`` which leads to  memory of unecessary compute which shouldn't do in first place.

**FIX:**

Remove the ``column_type`` and let it get again as soon ``_digits`` attribute add.

before fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  |    data_type
--------------+------------------
 test_line_id | double precision
(1 row)

```

After fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  | data_type
--------------+-----------
 test_line_id | numeric
(1 row)

```
opw-5222760
upg-3253635

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

Forward-Port-Of: odoo/odoo#237544
Forward-Port-Of: odoo/odoo#235112

Steps to reproduce:
1. Open database with version saas-18.4
2. Install module l10n_fr_hr_payroll_with_accounting
3. Make sure that your company's country is France.
4. Set `Salary Journal` in: `Configuration` -> `Structure` -> `FR: Employe Carde` -> `Employe Carde`
5. In Payroll app create a payslip for any employee having contract.
6. Make sure in `other inputs` you make new type and in that in the `availability in structure` has Employee cadre chosen.
7. Now with that Salary Input type click on `Compute sheet` button.
8. The `Invalid Operation` error card will appear.

**Description:**

In saas-18.4, the model hr.contract was [changed](https://github.com/odoo/upgrade/blob/fa44eb03c2b46d948e20dc6f5ac01dca2b625b90/migrations/hr/saas~18.4.1.1/pre-migrate.py#L41) to hr.version . All related code https://github.com/odoo/enterprise/commit/46052c4bc5ad1bd2549a6125202e0671b56beac8 was updated to use version instead of contract. in this commit.

However, in the module l10n_fr_hr_payroll, there where some fields which is still using `contract` to refer other fields .
https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/l10n_fr_hr_payroll/data/l10n_fr_hr_payroll_employe_cadre_data.xml#L130 Because of this, Odoo raises the error `Wrong python code name 'contract' is not defined when evaluating the code`.

I have fixed the issue by updating the name from contract to version in that module contract to version.

opw: [5259362](https://www.odoo.com/odoo/project/70/tasks/5259362)

**PROBLEM**
If in an invoice you delete a taxed line, and then add an untaxed line the tax amount might not be up to date.

**STEP TO REPRODUCE**
1. create an invoice with 2 lines both taxed.
2. remove one of the line, and create a new line which is untaxed.
3. confirm the invoice and notice the tax amount is not correct (= to the tax amount with the 2 taxed lines).
Be sure to not click on the "journal items" tab, else the bug will not occur.

**ISSUE**
In _sync_tax_lines(), there is checks to know if we should recompute the tax amount, or keep the old one.
We enter the check that checks the changed lines and determine if we should recompute the tax amount. This check doesn't take into account the fact that a line could have been deleted. Because we are in a elif chain, we don't do other checks.

**FIX**
Moving up in the elif chain the check that test if a base line with tax was removed and recompute the tax amount if that's the case.

[opw-5157090](https://www.odoo.com/odoo/project/49/tasks/5157090)

Forward-Port-Of: odoo/odoo#237060

**Issue**
In shopfloor, a traceback occurs when clicking on the add button if the associated operation has a `quality_check` of type `register_consumed_materials`.

**Steps to reproduce**
1. Create two products (product and component)
2. Create a BOM for this product that consumes that component
3. Create an operation linked to that BOM (Manufacturing > Configuration > Operations)
4. Add a quality check of type “Register Consumable Material” for this operation
5. Create a MO from that BOM and confirm it
6. Click on the shopfloor smart button → If debug mode is activated, a traceback occurs → Otherwise
7. Click on the 'add' button → A traceback occurs

**Cause**
In the method [`subRecordProps`](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L190C9-L194C14), when a quality check of type `register_consumed_materials` is done, the variable `production` is not propagated into the props. And [this](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L184) tries to access the production in the props, which is [called](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163) when the user clicks the 'add' button.

**Solution**
Add the `production` variable to the props.

opw-5165259

Forward-Port-Of: odoo/enterprise#98808

Steps to reproduce:
- Enable Multi-step routes & set warehouse to 3 steps delivery
- Make a SO for 5 qty of a stored product
- Validate the PICK
- Set the SO line qty to 3 & save
- Set the SO line qty to 5 & save

Issue:
While the first update to 3 creates a return PICK from Packing Zone -> Stock for 2 qty, the second updates does nothing.

When checking the outgoing/incoming moves to see which quantity should be set in the procurement, it only considered the outgoing quantity from the first step of the delivery.

Which means that the return wasn't taken into account, so since we only compare the new SO line qty to the already moved PICK, there was no difference thus no procurement made.

Now, we also consider less strict critera for incoming moves when checking in `strict == False` mode, as this is only used to compute the procurement quantity.

opw-5028794

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

Forward-Port-Of: odoo/odoo#237609
Forward-Port-Of: odoo/odoo#233796

Currently, when creating a booking from inside a point of sale, if you select multiple tables, only one will be saved.

Steps to reproduce:
-------------------
* Open the restaurant
* Open booking tab
* Create a new booking for 3 people
* Select 2 tables of 2 capacity
* Save
> Observation: Only one table resource is saved

Why the fix:
------------
By having the context key `default_resource_total_capacity_reserved` we would recompute the resources for the booking. It was recomputed in a way that we just une the minimum resources needed in regards of the resource capacity. For example if we had 3 tables of 2 and we are booking for 3, we wouldn't need the 3rd extra table.

In our case the capacity was always set to 2, as the point of sale form actually uses the field `waiting list capacity`. Since most table are usually for at leat 2 people only 1 would be needed. Removing `default_resource_total_capacity_reserved` from the context gives more freedom upon reservation and does not compute resources, it uses those selected on the form.

opw-5109501

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

Forward-Port-Of: odoo/enterprise#96811

**Description**

The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects.

**Steps to Reproduce**

1. Create a planning slot for an employee spanning a full month
2. Add employee time-off (resource.calendar.leaves) during that period
4. Navigate to Timesheets > Timesheets / Planning Analysis report
5. Filter by the employee and date range
6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project

**Root Cause**

The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy.

**Solution**

Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates.

opw-5027070

Forward-Port-Of: odoo/enterprise#100516
Forward-Port-Of: odoo/enterprise#97657

**Issue**
In shopfloor, a traceback occurs when clicking on the add button if the associated operation has a `quality_check` of type `register_consumed_materials`.

**Steps to reproduce**
1. Create two products (product and component)
2. Create a BOM for this product that consumes that component
3. Create an operation linked to that BOM (Manufacturing > Configuration > Operations)
4. Add a quality check of type “Register Consumable Material” for this operation
5. Create a MO from that BOM and confirm it
6. Click on the shopfloor smart button → If debug mode is activated, a traceback occurs → Otherwise
7. Click on the 'add' button → A traceback occurs

**Cause**
In the method [`subRecordProps`](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L190C9-L194C14), when a quality check of type `register_consumed_materials` is done, the variable `production` is not propagated into the props. And [this](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L184) tries to access the production in the props, which is [called](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163) when the user clicks the 'add' button.

**Solution**
Add the `production` variable to the props.

opw-5165259

Steps to reproduce:
1. Install website_sale_subscription
2. Enable Comparison Price from the settings
3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price
4. Go to product page via smart button

Issue:
- The comparison price is not visible beside the recurring plan.

Cause:
- The product page updates the pricing display dynamically using client-side rendering when the subscription plan information is loaded. The XML template `website_sale_subscription.SubscriptionPricingSelect` used the <field> tag `<field name="product.compare_list_price"/>` to render the comparison price. The <field> tag is a server-side QWeb element and is not supported by the client-side Owl engine, causing the rendering to display nothing.
Additionally, client-side templates do not have automatic access to server-side field formatting (like currency symbols) when simply escaping raw values.

Solution:
- In `variant_mixin.js`, extract the already formatted comparison price text from the existing DOM element (the `<del>` tag inside the pricing selector) before the element is replaced and pass this formatted string to the rendering context. Update the XML template to use `t-esc` to display this pre-formatted string instead of using `<field>`

before:
<img width="426" height="79" alt="image" src="https://github.com/user-attachments/assets/fe34b4c5-5cd6-4877-80e3-9ed4481cd86f" />

After:
<img width="392" height="115" alt="image" src="https://github.com/user-attachments/assets/ed043fef-bfd3-46de-aeb2-1a48cacc89ed" />

opw-5248297

Forward-Port-Of: odoo/enterprise#100140

### Issue:
During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up.

### Steps to reproduce:
- Install 'l10n_ar'
- Settings > Accounting
- Make sure the "Fiscal Localization" have a value (not Argentina)
- Change the "Fiscal Localization" to "Argentine - Generic Chart of Accounts [...]"
- Go in Accounting > Configuration > Journals
- Click on "Ventas Preimpreso"
- The journal don't have "Use Documents" ticked but it should

### Cause:
When loading the data, `_get_chart_template_data()` calls `_get_ar_base_res_company()` and `_get_latam_document_account_journal()`.

The first one returns the data to change `res.company.account_fiscal_country_id` to `base.ar`. The second one [checks](https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/addons/l10n_latam_invoice_document/models/account_chart_template.py#L12) that [`self.env.company.account_fiscal_country_id.code == "AR"`](https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/l10n_ar/models/res_company.py#L36) before returning the data to change `l10n_latam_use_documents` to `True`. As `res.company.account_fiscal_country_id` has not been updated, it's not Argentina during the check and `_get_latam_document_account_journal()` returns nothing.

### Solution:
When loading the template, we cannot use `res.company.account_fiscal_country_id` to know if we are in LATAM or not. So instead we check on `chart_template`.

opw-5221931

Forward-Port-Of: odoo/odoo#237725
Forward-Port-Of: odoo/odoo#236217

Same issue already fixed for 18.4+ here:
https://github.com/odoo/odoo/pull/231399

Issue:
When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank.

Repro Steps:
1- Create invoice for romanian localization.
2- Link payment account to invoice.
3- Add bank to payment account.
4- Confirm and send invoice with "Send E-Factura SPV" checked.

Cause:
The state field is defined differently for res.bank and res.partner. res.partner uses state_id, while res.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for res.bank.

Fix:
The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly.

opw-5362000

(cherry picked from commit a2af8d434bfc7f77008959c8179e8f158bcf9e93)

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

Forward-Port-Of: odoo/odoo#237615

**PROBLEM**
If in an invoice you delete a taxed line, and then add an untaxed line the tax amount might not be up to date.

**STEP TO REPRODUCE**
1. create an invoice with 2 lines both taxed.
2. remove one of the line, and create a new line which is untaxed.
3. confirm the invoice and notice the tax amount is not correct (= to the tax amount with the 2 taxed lines).
Be sure to not click on the "journal items" tab, else the bug will not occur.

**ISSUE**
In _sync_tax_lines(), there is checks to know if we should recompute the tax amount, or keep the old one.
We enter the check that checks the changed lines and determine if we should recompute the tax amount. This check doesn't take into account the fact that a line could have been deleted. Because we are in a elif chain, we don't do other checks.

**FIX**
Moving up in the elif chain the check that test if a base line with tax was removed and recompute the tax amount if that's the case.

[opw-5157090](https://www.odoo.com/odoo/project/49/tasks/5157090)

Forward-Port-Of: odoo/odoo#237060

Steps to reproduce:
- Enable Multi-step routes & set warehouse to 3 steps delivery
- Make a SO for 5 qty of a stored product
- Validate the PICK
- Set the SO line qty to 3 & save
- Set the SO line qty to 5 & save

Issue:
While the first update to 3 creates a return PICK from Packing Zone -> Stock for 2 qty, the second updates does nothing.

When checking the outgoing/incoming moves to see which quantity should be set in the procurement, it only considered the outgoing quantity from the first step of the delivery.

Which means that the return wasn't taken into account, so since we only compare the new SO line qty to the already moved PICK, there was no difference thus no procurement made.

Now, we also consider less strict critera for incoming moves when checking in `strict == False` mode, as this is only used to compute the procurement quantity.

opw-5028794

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

Forward-Port-Of: odoo/odoo#237609
Forward-Port-Of: odoo/odoo#233796

**Description**

The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects.

**Steps to Reproduce**

1. Create a planning slot for an employee spanning a full month
2. Add employee time-off (resource.calendar.leaves) during that period
4. Navigate to Timesheets > Timesheets / Planning Analysis report
5. Filter by the employee and date range
6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project

**Root Cause**

The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy.

**Solution**

Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates.

opw-5027070

Forward-Port-Of: odoo/enterprise#100516
Forward-Port-Of: odoo/enterprise#97657

**PROBLEM**
Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g, and it consumes 1000kg).

**STEP TO REPRODUCE**
1. create a product.
2. create a bom with:
 - a component tracked by lot, with kg as product uom, but g as the bom uom.
 - create a step, during which 50g of the component is consumed.
3. create two lots of the component, with 1kg each.
4. create a MO for the product with the bom.
5. in the shop floor, try consuming the component and select one of the lot as a source.
6. the consumed amount should be 50g, remove the move line created (pencil icon, then remove).
7. recreate the move line, the consume amount will be nonsensical (something like 1 000 000g).

**CAUSE**
1. The dialog opened for selecting the lot create a new `stock.quant` record, instead of returning the existing quant for the lot. This quant will have a quantity of 0, impacting the computation we do for the quantity we should take from this quant.
2. The formula for the quantity to take from the quant was : `max(min(remaining_qty, quant.available_quantity), 1)`. The `max(...,1)` doesn't work well when `remaining_qty` is between 0 and 1. For example, when using UoM like we do in the repro steps, `remaining_qty = 50g = 0.05kg`. But instead of taking 50g, because of the max we take 1kg = 1000g.
3. There was a double UoM conversion (`_prepare_move_line_vals` already does the conversion, so we don't need to do it before passing qty_to_take as parameter).

opw-5136050

Version - 17.0

Issue:
- When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error
- As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued.

Steps to reproduce:
- Create an upsell order of a subscription.
- Click Create Alternative to generate an alternative SO.
- Confirm the SO and click on Create Invoice to make the invoice
- This will throw an error of defferred end date

Cause:
- The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO.
- Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error.

Fix:
- Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation.

Impact:
Invoices for alternative upsell sale orders can now be created successfully without errors.

task-5241150

Forward-Port-Of: odoo/enterprise#99831
Forward-Port-Of: odoo/enterprise#98983

Steps to reproduce:
1. Install website_sale_subscription
2. Enable Comparison Price from the settings
3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price
4. Go to product page via smart button

Issue:
- The comparison price is not visible beside the recurring plan.

Cause:
- The product page updates the pricing display dynamically using client-side rendering when the subscription plan information is loaded. The XML template `website_sale_subscription.SubscriptionPricingSelect` used the <field> tag `<field name="product.compare_list_price"/>` to render the comparison price. The <field> tag is a server-side QWeb element and is not supported by the client-side Owl engine, causing the rendering to display nothing.
Additionally, client-side templates do not have automatic access to server-side field formatting (like currency symbols) when simply escaping raw values.

Solution:
- In `variant_mixin.js`, extract the already formatted comparison price text from the existing DOM element (the `<del>` tag inside the pricing selector) before the element is replaced and pass this formatted string to the rendering context. Update the XML template to use `t-esc` to display this pre-formatted string instead of using `<field>`

before:
<img width="426" height="79" alt="image" src="https://github.com/user-attachments/assets/fe34b4c5-5cd6-4877-80e3-9ed4481cd86f" />

After:
<img width="392" height="115" alt="image" src="https://github.com/user-attachments/assets/ed043fef-bfd3-46de-aeb2-1a48cacc89ed" />

opw-5248297

Forward-Port-Of: odoo/enterprise#100140

**Steps to reproduce:**
- create a product tracked by lot 
- create a lot with a quantity of 2
- create a new sale order
- add two sale order lines, both for a quantity of 1 of the product
- confirm
- open the picking in barcode
- scan the stock location
- scan the lot 
- scan the lot another time
- validate

**Current behavior:**
a backorder is created

**Expected behavior:**
No back order should be created 

**Cause of the issue:**
After scanning the lot for the first time we have the following situation: 
two lines : 
- one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1
- one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1
both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2
All of this is correct.

when scanning the lot for the second time: 
_findLine iterates through the lines to select the right 
line to use.
 _findLine calls _lineIsNotComplete on the first line to check 
if it's complete (this first line is complete).
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684
But _lineIsNotComplete will actually do the check on the 
parent line (which is not complete), so the return value will 
be true. 
https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338
As a consequence, the quantity will be added in the first line and 
we will have a qty_done of 2 in the first line 
and a qty_done of 0 in the second line. 
Which will lead to the creation of a back order

opw

Forward-Port-Of: odoo/enterprise#99774

**Description**

The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects.

**Steps to Reproduce**

1. Create a planning slot for an employee spanning a full month
2. Add employee time-off (resource.calendar.leaves) during that period
4. Navigate to Timesheets > Timesheets / Planning Analysis report
5. Filter by the employee and date range
6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project

**Root Cause**

The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy.

**Solution**

Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates.

opw-5027070

Forward-Port-Of: odoo/enterprise#100516
Forward-Port-Of: odoo/enterprise#97657

## **Issue Before This Commit:**
When a work order is assigned to an employee (not linked to the current user),
and the current user marks it as done, the time log is wrongly created
under the current user’s employee instead of the assigned one.
This behavior caused confusion for the user as the
wrong person was shown as working on the order.

## **Steps to Reproduce:**
- Create an MO with work orders and confirm it.
- Assign another employee to a work order.
- Mark the work order as done with the current user from the work order line.
- Open the workorder and notice that the time log is created for the current user’s employee.

## **Cause of the Issue:**
The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790),
where the logic for assigning the main employee was overridden,
ignoring the case of an already assigned employee.

## **With This Commit:**
The time log is now created for the assigned employee,
This resolves the confusion by ensuring
the right person is tracked on the work order.

TaskID: 4983514

Forward-Port-Of: odoo/enterprise#100604
Forward-Port-Of: odoo/enterprise#93378

This restores a feature lost at [1]: a call beginning before the
calendar current range but ending inside it was not shown anymore.
Indeed the `end_date` became computed from the `duration` instead of the
other way around, allowing efficient domain manipulation based on the
duration. However, it prevented domain manipulation based on the end
date, which the calendar view needs. It also just makes sense to allow
filtering based on the end date too (even if we judged it less useful
when making [1]). A solution could be to store the end date too, but it
would be redundant data. This instead allows domain manipulation through
a field `compute_sql` definition.

At the same time, this does the same thing for the start date: creating
a new computed field `effective_start_date`, which is either the call
start date or its `create_date`. This allows to entirely remove the
domain override needed in the calendar model (combined with the
community commit that comes with this one, which makes the calendar now
consider records without a set end date but which started within range).

Note: the date_delay option of the calendar was removed at [2].

This also fixes a runbot issue during the "click everywhere" test:
- Enter VoIP app
- Go to calendar
- Enter web studio
=> Crash, because the studio calendar ignores the VoIP custo about the
   calendar domain and filters on `end_date`. The VoIP custo being gone
   and filtering on `end_date` restored, this is not a problem anymore.

[1]: https://github.com/odoo/enterprise/commit/47300cc462420273dd90d5668f542878b6f73254
[2]: https://github.com/odoo/odoo/commit/40c75d3635b4d0de8fca631e4aebd26a466a8709

task-5350495
runbot-234398

Steps to reproduce the bug:
1. install hr_contract_salary_payroll
2. check "My US Company"
3. go on "Work Entries", then click on the arrow to view the next month. -> This will generate work entries for the next month
4. Go back to employees / Troy Cruz / Offers (smart button) -> You should be on the form view of a new offer. Do not save it.
5. Change the contract template to (e.g.) Experienced Developer -> A validation Error should appear

The validation error would tell us that we are trying to set a new contract to the employee, but the employee already had a running contract.

This happens because `self.employee_id` would be set to false just after the write of it's version's `contract_date_end`:
https://github.com/odoo/enterprise/blob/9ea4c1382a75024acacba7af1529d0c5cc762827/hr_contract_salary_payroll/models/hr_contract_salary_offer.py#L78C1-L78C7

This only happens when there are work entries after the specified end date. This is why we had to look at the next month's work entries.

The problematic code gets rolled back at some point, but `self.employee_id` stays empty if we don't save the form, since self is a `newId` in this case, which is not stored in the DB (and thus not rolled back)

The issue was that the context was supposed to have the `salary_simulation` key present, since we are doing a salary simulation.
But, the backend would still try to unlink the work entries of current_version during the simulation. Which is not needed and causes `self.current_employee_id` to be set to `False`

The context variable and a check before `_remove_work_entries()` has thus been added to fix that.

task-5207567

Steps to reproduce the bug:
1. install hr_contract_salary_payroll
2. check "My US Company"
3. go on "Work Entries", then click on the arrow to view the next month. -> This will generate work entries for the next month
4. Go back to employees / Troy Cruz / Offers (smart button) -> You should be on the form view of a new offer. Do not save it.
5. Change the contract template to (e.g.) Experienced Developer -> A validation Error should appear

The validation error would tell us that we are trying to set a new contract to the employee, but the employee already had a running contract.

This happens because `self.employee_id` would be set to false just after the write of it's version's `contract_date_end`:
https://github.com/odoo/enterprise/blob/9ea4c1382a75024acacba7af1529d0c5cc762827/hr_contract_salary_payroll/models/hr_contract_salary_offer.py#L78C1-L78C7

This only happens when there are work entries after the specified end date. This is why we had to look at the next month's work entries.

The problematic code gets rolled back at some point, but `self.employee_id` stays empty if we don't save the form, since self is a `newId` in this case, which is not stored in the DB (and thus not rolled back)

The issue was that the context was supposed to have the `salary_simulation` key present, since we are doing a salary simulation.
But, the backend would still try to unlink the work entries of current_version during the simulation. Which is not needed and causes `self.current_employee_id` to be set to `False`

The context variable and a check before `_remove_work_entries()` has thus been added to fix that.

task-5207567

Currently an error occurs when there are multiple stock references of same name, and user assigns references on Reception report.

Steps to replicate:
- Install `sale_stock`.
- Load Demo data from Settings.
- From settings, check `Reception Report`.
- Go to Operations > Reference > S00004 > Duplicate it (from the form view).
- Open Receipts > WH/IN/00002 > Allocation (Smart button) > Click 'Assign All' or the S00004 line.

Error:
```
File "/home/odoo/odoo18/community/addons/stock/report/report_stock_reception.py", line 271, in action_assign
    self._action_assign(in_move, out)
  File "/home/odoo/odoo18/community/addons/stock/report/report_stock_reception.py", line 343, in _action_assign
    in_move._get_source_document()._add_reference(out_ref)
  File "/home/odoo/odoo18/community/addons/stock/models/stock_picking.py", line 2102, in _add_reference
    self.move_ids.reference_ids = [Command.link(reference.id)]
  File "/home/odoo/odoo18/community/odoo/orm/fields_misc.py", line 112, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.reference(3, 19)
```

Cause:
- As the user duplicated the record, there were two records received in the variable `reference` at [1] that caused the expected singleton error.

Solution:
- The methods `_add_reference()` and `_remove_reference()` can now handle multiple reference records.

[1]: https://github.com/odoo/odoo/blob/4b2154870eebcce449f53d8f593386ae6af04a83/addons/sale_stock/models/sale_order.py#L329

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

Before this commit, rendering BuilderList with many elements caused noticeable delays.

How to reproduce:
=======================
- Use a runbot with all demo data
- Switch to edit mode in the website builder
- Add a form
- Link the form to the Contact model
- Add the "State" field

Before this commit:
The options related to the "State" field took more than one second to render.

After this commit:
Rendering is several hundred milliseconds faster. Additional commits will follow to further improve the situation.

Reason for the slowdown:
=======================
BuilderList is not optimized to render several thousand records (about 1900 in this example). This commit addresses the identified bottlenecks to reduce rendering time.

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

- Earlier, when downloading an invoice, invoices that were never sent didn’t have a generated PDF.
This happened because the method _get_invoice_legal_documents_all had allow_fallback=False by default.
As a result, those invoices returned no attachments, leading to blank pages or missing files in the ZIP download —
since the invoices weren’t sent and no fallback was allowed.

**Steps to reproduce:**
**1:** Go to Invoices
**2:** Try to use Export ZIP for any non-sent invoice → you’ll see a blank page

**What this patch does:**
- It limits the Export ZIP option to the list view only. This doesn’t fix the missing PDF issue, but it makes sense — having “Export ZIP” on every single invoice form view isn’t useful.

**Possible improvements to consider:**
**1:** Restrict Export ZIP so it’s only available for sent invoices. This would improve performance since sent invoices already have PDFs stored in the filestore.

**2:** Allow a fallback for invoices that haven’t been sent, so their PDFs are generated when exporting — but this may cause performance issues if too many non-sent invoices are processed at once.

**3:** Instead of showing a blank page for non-sent invoices, show a user-friendly
 error message. (I noticed this was in the original commit
odoo/odoo@c81ab09d0404cc57f48c202360361a1700f060db where this was
 introduced but was later removed — not sure why.)

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

Forward-Port-Of: odoo/odoo#234886

Currently, if a user overpays while using a different language, like French, the receipt does not show the change.

**Steps to replicate:**
* Install POS with demo data and change language to French .
* POS > Furniture Shop > Open the register
* Select a product, overpay with cash, and validate.

**Issue:**
* As seen in [1], the `Change` field doesn’t appear when overpaying with cash, even though it shows in the English version.

**Root cause:**
* The issue happens because changing the language translates the payment line name at [2] (coming from the translated return at [3]). This makes it get included in the sum at [4], which incorrectly subtracts it from the total cash paid and causes the change amount to disappear on the receipt.

**Solution:**
* Check and add up the payment lines where `is_change` is `false`, and use that instead of relying on the payment line’s name at [3].

**Before:**
<img width="830" height="556" alt="image" src="https://github.com/user-attachments/assets/5aaddfe0-fe46-49e1-a877-4fe4de2fb5c7" />

**After:**
<img width="931" height="596" alt="image" src="https://github.com/user-attachments/assets/4215d6b8-14b4-4e59-85bc-4d0f43f1d09c" />

[1]:
https://www.odoo.com/web/image/91240289?access_token=bef22d9abd1232e34f510648a34f7709d82b848ed852fccdb893f2d1149067abo0x69505fa6&filename=image.png&unique=dd2a62fbe180532cf5cf00c27adc60742f113ddc 
[2]:
https://github.com/odoo/odoo/blob/0581b7fb6abc8e856cedf13254ba1f9d362d6d34/addons/point_of_sale/static/src/app/models/accounting/pos_order_accounting.js#L146 
[3]:
https://github.com/odoo/odoo/blob/0581b7fb6abc8e856cedf13254ba1f9d362d6d34/addons/point_of_sale/models/pos_order.py#L188-L195 
[4]:
https://github.com/odoo/odoo/blob/0581b7fb6abc8e856cedf13254ba1f9d362d6d34/addons/point_of_sale/static/src/app/models/accounting/pos_order_accounting.js#L147

opw-5344903

**Steps to reproduce:**
1. Open database with version 19.0
2. Install module l10n_fr_hr_payroll_with_accounting
3. Set `Salary Journal` in: `Configuration` -> `Structure` -> `FR: Employe Carde` -> `Employe Carde`
4. In Payroll app create a payslip for any employee
5. In `structure` Employee cadre be choosen, And also
6. Make sure in salary inputs you make new type and in that in the
`availability in structure` has Employee cadre chosen.
7. Now with that Salary Input type click on `Compute sheet` button.
8. The `Invalid Operation` error card will appear.

**Description:**

After this changes in the [commit](https://github.com/odoo/enterprise/pull/100112/files) you will face another issue for which the steps are there in steps to reporduce.

In this [commit](https://github.com/odoo/enterprise/commit/bd2ee7546df3f31c73e8aaae0244ac6767f982fb#diff-5b26ac7c31dbf0286aa98671d7dadb50c117ea2ffb0d52d55a8f4e5d16d7ee88R709) Instade of `company_id` there is `company_20id`, which is not valid field. As in this code:
https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/l10n_fr_hr_payroll/models/res_config_settings.py#L11 we can see that `company_id ` is set as related field for nombre_employes, so I have changed from `company_20id ` to `company_id`

**opw**: [5259362](https://www.odoo.com/odoo/project/70/tasks/5259362)

**Steps to reproduce:**
* Install the **pos_sale** module.
* In **Settings**, enable the *Units of Measure & Packagings* option.
* Create two products, each using a different **Unit of Measure** (e.g., *Unit*, *Hours*),
and ensure both are available in POS.
* Open the **Sales** app and create a quotation including both products. Confirm the order.
* Open the **POS Store** and go to **Quotation/order** options , and select
*Created Sale Order* with the option **Settle the order**.
* Proceed to the payment screen and attempt to validate the payment.

**Observed behavior:**
* A **singleton error** is raised when validating the payment for a sale order
containing multiple lines with different UoMs.

**Cause:**
* The code incorrectly passes `self`, which may contain multiple sale order lines,
leading to a singleton expectation failure.

**Fix:**
* Pass a single sale order line to avoid the singleton error during payment validation.
---
opw-5251840

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

Currently, an error occurs when a user replaces a `combo product` with another 
product in a sale order line before the order is saved.

**Steps to produce:**

- Install the `sale_management` module with demo data.
- Open `sale order`, click `Add a product`, and add a `combo product` (Office Combo). 
  (`Make sure the form is not saved`)
- Click on the `combo name` (Office combo x 1) and replace it with another product.

**Error:**
`IndexError: tuple index out of range`

**Root cause:**
After PR [1], at [2], when a combo product is replaced before the order is
saved, the code attempts to update the combo item lines even though the
template type (`product_template_id.type`) is not `combo`. This leads to an
update of `product_uom_qty`, which triggers the `_compute_price_unit` method
and results in the error at [3].

**Fix:**
This commit prevents errors when a user replaces a combo product with another product.

[1]:
https://github.com/odoo/odoo/pull/194496

[2]:
https://github.com/odoo/odoo/blob/47e561bd1f6bc14724d60ebf09a66e458dfd4799/addons/sale/models/sale_order.py#L966-L970

[3]:
https://github.com/odoo/odoo/blob/c758b93a57cd98ab76c26c03bd0097f2eef50961/addons/sale/models/sale_order_line.py#L766

sentry-7009976704

### Issue:
During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up.

### Steps to reproduce:
- Install 'l10n_ar'
- Settings > Accounting
- Make sure the "Fiscal Localization" have a value (not Argentina)
- Change the "Fiscal Localization" to "Argentine - Generic Chart of Accounts [...]"
- Go in Accounting > Configuration > Journals
- Click on "Ventas Preimpreso"
- The journal don't have "Use Documents" ticked but it should

### Cause:
When loading the data, `_get_chart_template_data()` calls `_get_ar_base_res_company()` and `_get_latam_document_account_journal()`.

The first one returns the data to change `res.company.account_fiscal_country_id` to `base.ar`. The second one [checks](https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/addons/l10n_latam_invoice_document/models/account_chart_template.py#L12) that [`self.env.company.account_fiscal_country_id.code == "AR"`](https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/l10n_ar/models/res_company.py#L36) before returning the data to change `l10n_latam_use_documents` to `True`. As `res.company.account_fiscal_country_id` has not been updated, it's not Argentina during the check and `_get_latam_document_account_journal()` returns nothing.

### Solution:
When loading the template, we cannot use `res.company.account_fiscal_country_id` to know if we are in LATAM or not. So instead we check on `chart_template`.

opw-5221931

Forward-Port-Of: odoo/odoo#237725
Forward-Port-Of: odoo/odoo#236217

**Steps to Reproduce the Issue**:

1. Install the following apps in version 19.0 database:
   * stock_account
2. Go to Settings → enable Lots & Serial Numbers.
3. Open the Inventory app, then go to Products and create a new product
with the following configuration:
   * Product Type: Goods
   * Track Inventory: By Unique Serial Number
   * Inventory tab: Enable Valuation by Lot/Serial
   * General Information tab: Create a new Product Category with:
     * Costing Method: AVCO (Average Cost)
4. Go to Products → Lots/Serial Numbers.
5. Create a new Lot/Serial Number and select the product you just created, then
click Save.
6. Now update the Cost in the Lot/Serial Number form and click Save again.
7. You will now encounter the trackback error.

**Description:**

In the [commit](odoo@22b9e1a#diff-2623d0e4c393b65afe1c6d00f55af80d19f022aaeb0da0e5e173e37a84138159R42) The `lot_id` is written but in `stock.move` model there is `lot_ids` [field]((https://github.com/odoo/odoo/blob/6496653de3c9bb2a3cde8e38fdda8fb7abe27713/addons/stock/models/stock_move.py#L189)) so it gives error `keyerror`.
Now i have used [`lot_id`](https://github.com/odoo/odoo/blob/9333df06e15134df92efed765cf95db38c0dfede/addons/stock/models/stock_move_line.py#L48) field of `stock.move.line` for mapping the `move_id` so that after price adjustment correct move value is set.

opw-[5266457](https://www.odoo.com/odoo/project/70/tasks/5266457)



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

To reproduce
-------------
1. Install `l10n_es_edi_verifactu_pos`, and select the ES company
2. Make an order in PoS with a price less than 400, and don't invoice it.
3. Close the PoS session, then go to PoS > Orders, and select the previously made order
4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order.
5. Click invoice to invoice the order; the invoice is no longer simplified.

Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead.

The fix
-------
We add a new field on the `pos.order` model to retain if that order was previously invoiced with a simplified invoice, in that case, we set its type to 'F3' instead of 'F1' when fully invoicing it.

Sources:
--------
Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD

opw-5343973

Steps to reproduce:
- Enable Multi-step routes & set warehouse to 3 steps delivery
- Make a SO for 5 qty of a stored product
- Validate the PICK
- Set the SO line qty to 3 & save
- Set the SO line qty to 5 & save

Issue:
While the first update to 3 creates a return PICK from Packing Zone -> Stock for 2 qty, the second updates does nothing.

When checking the outgoing/incoming moves to see which quantity should be set in the procurement, it only considered the outgoing quantity from the first step of the delivery.

Which means that the return wasn't taken into account, so since we only compare the new SO line qty to the already moved PICK, there was no difference thus no procurement made.

Now, we also consider less strict critera for incoming moves when checking in `strict == False` mode, as this is only used to compute the procurement quantity.

opw-5028794

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

Forward-Port-Of: odoo/odoo#237609
Forward-Port-Of: odoo/odoo#233796

**PROBLEM**
If in an invoice you delete a taxed line, and then add an untaxed line the tax amount might not be up to date.

**STEP TO REPRODUCE**
1. create an invoice with 2 lines both taxed.
2. remove one of the line, and create a new line which is untaxed.
3. confirm the invoice and notice the tax amount is not correct (= to the tax amount with the 2 taxed lines).
Be sure to not click on the "journal items" tab, else the bug will not occur.

**ISSUE**
In _sync_tax_lines(), there is checks to know if we should recompute the tax amount, or keep the old one.
We enter the check that checks the changed lines and determine if we should recompute the tax amount. This check doesn't take into account the fact that a line could have been deleted. Because we are in a elif chain, we don't do other checks.

**FIX**
Moving up in the elif chain the check that test if a base line with tax was removed and recompute the tax amount if that's the case.

[opw-5157090](https://www.odoo.com/odoo/project/49/tasks/5157090)

Forward-Port-Of: odoo/odoo#237060

**Description**

The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects.

**Steps to Reproduce**

1. Create a planning slot for an employee spanning a full month
2. Add employee time-off (resource.calendar.leaves) during that period
4. Navigate to Timesheets > Timesheets / Planning Analysis report
5. Filter by the employee and date range
6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project

**Root Cause**

The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy.

**Solution**

Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates.

opw-5027070

Forward-Port-Of: odoo/enterprise#100516
Forward-Port-Of: odoo/enterprise#97657

When you create a product with atleast one variant that has 2 value,
and create a BoM for this product that has 2 lines with each line
having one of the two values, then create a POS order with one unit
of each variant, the cost of the first line not correctly computed.

Steps to reproduce:
-------------------
* Create a prodcut P with one attribute A that has two values A1 and A2
* Create a product C with no attribute and a cost of 10$
* Create a BoM for P with two lines:
  - Line 1: product C, quantity 1, only for attribute value A1
  - Line 2: product C, quantity 2, only for attribute value A2
* Open a PoS session
* Add Product P with attribute value A1 to the order
* Add Product P with attribute value A2 to the order
* Validate the order and close the session
* Go to the order and check the cost of each line
> Observation: The cost are not correct, they should be 10$ and 20$

Why the fix:
------------
Before this fix we were not taking the
`bom_product_template_attribute_value_ids` into account when filtering
the stock moves to consider for the cost computation. This value
represent the attribute values that the product must have for
this BoM line to be considered.

opw-4765234

Forward-Port-Of: odoo/odoo#236450
Forward-Port-Of: odoo/odoo#225014

In the stock.picking form, we can modify the `lot_id` of the product we deliver to the customers. Since 19.0, the edited `lot_id` wasn't saved properly, leading to the original `lot_id` being used when confirming the delivery.

### Steps to reproduce:

1. Install the Stock (`stock`) app.
2. Enable the *Lots & Serial Numbers* traceability settings.
3. Create a product tracked *By Unique Serial Number*
4. Create a quotation with a line that includes the product tracked by unique serial number
5. Confirm the quotation
6. Click on the *Delivery* smart button
7. Display the *Serial Numbers* column in the list view
8. Update the Serial Number of the product (remove the original serial number, then add a new one)
9. Click *Validate*, or *Save manually* and reload the page
10. The Serial Number set in step 8 is replaced by the original one

The condition at the start of the `StockMove._set_lot_ids` method was preventing the `stock.move.line` from being updated. In the context of this issue, at the moment of execution, the `stock.move.line` still has the original `lot_id`, but it should be updated to the `lot_id` set by the user. This update does not occur because of the condition.

https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/stock/models/stock_move.py#L606-L607

After applying this fix, the serial number set by the user is correctly saved and used when clicking the *Validate* button on the stock picking form.

opw-5169690

Before this PR:
- Auto focus on a participant’s video when joining a call did not trigger due 
to a typo in the find() callback, causing it to always return undefined.
- The video-focus-on-join feature was only conditioned on the call component 
not being shown in the Discuss desktop view. This does not handle the cases 
when call is in meeting view or PiP view
- The video-focus-on-join feature only ran at call join time. In one-one calls, 
when the other participant turned on their camera after the call started, 
their video was not focused even when auto-focus was enabled
- When any participant had video enabled, the call component could overflow 
the chat window, causing an unwanted horizontal scrollbar.

This PR:
- Fixes the find() callback typo so the active streaming session is correctly 
detected and auto-focused when joining a call.
- Updates the video-focus-on-join conditions to support all intended layouts: 
    1. mobile (small UI)
    2. chat window
    3. PiP window.
- Extends the video-focus-on-join feature: in one-one calls, when the other 
participant turns on their camera mid-call, their video is now automatically 
focused (when auto-focus is enabled and the above layout conditions are met).
- Fixes layout overflow by preventing the call component from exceeding the 
chat window width.

Before / After fix (overflow issue):
<img width="300" height="640" alt="image" src="https://github.com/user-attachments/assets/a291949f-5a82-4c0c-a3c3-d31078e2e62e" /> <img width="300" height="640" alt="image" src="https://github.com/user-attachments/assets/f8405be4-e200-416b-b582-ecc057a0f9a3" />


part of task-[5227387](https://www.odoo.com/odoo/project/1519/tasks/5227387)

Issue:
----------------------------------
When accessing a work order in a work center not included in the default
selection on the shop floor, the system would change the default view by
removing `All MO` and `My WO`, disrupting the expected behavior for users.

Steps to reproduce:
----------------------------------
- Open the Shop Floor view and note the default filters like All MO and My WO.
- Access a production whose work order is in a work center not included in the
  current selection, and move it to that work center.
- Observe that the view reloads and the default filters are removed, showing
  only the newly added work center.

With this commit:
----------------------------------
The function is fixed to keep default selections like All MO and My WO when
adding a new work center. These were previously removed because they aren't
stored and weren't re-added. Now, the new work center is added without altering
the default view.

Task-id: [4392236](https://www.odoo.com/odoo/project/966/tasks/4392236)

The link between purchase order and a repair order break at when the PO is confirmed.

### Steps to reproduce:
* Install the Repair and Purchase modules
* Activate multi-steps routes
* Unarchive the MTO route
* Create a product with the MTO route enabled
* Create a Repair
* On the Repair Order, in part add:
	- type : ADD
	- product : mto product
* Save the RO
* Go to Purchase Order
* Confirm the PO
-> Issue Smart link between PO and RO broken.

### Observation:
The smart link is defined on:
RO -> PO:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/repair_order.py#L15-L17 PO -> RO:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_repair/models/purchase_order.py#L15-L17

When we confirm the PO, from the picking information it will create new moves:
https://github.com/odoo/odoo/blob/2c87f3b2b397f268f0e50cb73cd81de992ddd42e/addons/purchase_stock/models/purchase_order.py#L293-L298

To create those stock moves, we go into_create_stock_moves where, for each POL, we will generate their values and erase the smart link:
https://github.com/odoo/odoo/blob/a2be8182010613c6f92f59e686a2fbf066cc6b68/addons/purchase_stock/models/purchase_order_line.py#L362-L365

### Origin:
In this commit https://github.com/odoo/odoo/commit/9d98c43581e2579f43b35541b43264866dede5a5:
"`created_purchase_line_id` is cleared after confirming the RFQ. This
allows to merge more in `_merge_moves`."
This breaks the link between PO <-> RO to maybe merge the move in the future.

This issue is not present in 19.0 since it was solve in this commit :
https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a

### About the fix:
The root cause of this issue remains ambiguous despite the analysis. Therefore, in the interest of stability and caution, we opted to implement the fix in a safer location.

opw-5121816

### **Summary**

In a real multi-company setup with multiple Belgian companies registered on Peppol, incoming Peppol invoices are systematically created in the **current user’s company**, instead of the company that actually received the document.

The problem occurs even though the correct journal is identified in `account_edi_proxy_client.user` and used to call `_create_document_from_attachment()`.

### **How to reproduce**

#### **Environment**

* Two Belgian companies: e.g. **Company A** and **Company B**
* Both registered and active on Peppol
* Each company has its own **Peppol purchase journal** (`company.peppol_purchase_journal_id`)
* An accountant with access to both companies

#### **Steps**

1. Trigger Peppol incoming document retrieval (`_peppol_get_new_documents`)

2. Odoo resolves the correct receiving company and journal:

   ```python
   company = edi_user.company_id
   journal = company.peppol_purchase_journal_id
   ```

3. The code uses this journal to import the invoice:

   ```python
   move = journal\
       .with_context(
           default_move_type='in_invoice',
           default_peppol_move_state=content['state'],
           default_peppol_message_uuid=uuid,
       )\
       ._create_document_from_attachment(attachment.id)
   ```

4. **Actual result**:
   The `account.move` is created in **the company of the current user**, *not* in `journal.company_id`.

5. **Expected result**:
   The vendor bill must belong to the company that received the Peppol document (i.e. `journal.company_id`).

This behaviour is reproducible 100% of the time when a user has multiple companies enabled.

---

### **Root Cause**

The selected journal is **never propagated** to the EDI XML decoder.

#### 1. The call in the Peppol module *looks* correct:

```python
journal.with_context(...)._create_document_from_attachment(...)
```

…but `_create_document_from_attachment()` in `account.journal` does *not* use `self` to determine the journal:

```python
invoices = self.env['account.move']
# `self` (journal) is not used at all during decoding
decoders = self.env['account.move']._get_create_document_from_attachment_decoders()
```

So the journal passed to `.with_context()` is effectively **ignored** inside the decoder chain.

#### 2. The XML decoder in `account.edi.format` explicitly uses the *environment company*:

```python
res = edi_format.with_company(self.env.company)._create_invoice_from_xml_tree(...)
```

Thus:

* The company used during invoice creation is **self.env.company**
* That is the **current user’s company**
* Not the Peppol recipient’s company
* Not the journal’s company
* Not the company associated with the Peppol identifier

#### 3. `_create_invoice_from_xml_tree()` supports a journal, but it is never provided

```python
if not journal:
    journal = self.env['account.journal'].browse(self._context.get("default_journal_id"))
```

Since `default_journal_id` is **never set**, the fallback is always used.

---

### **Why the fix requires passing `default_journal_id` explicitly**

Even if it **feels redundant**, it is necessary.

* We *are* calling the decoder through `journal.with_context(...)`
* But `_create_document_from_attachment()` does **not** use `self`
* The decoder receives **no reference to the journal**
* And is executed in a context where `self.env.company` = current user’s company

Because Odoo intentionally allows calling `_create_document_from_attachment()` on an **empty journal recordset**, the decoder cannot deduce the journal from `self.id`.

Therefore, the only reliable way to pass the journal down the stack is through the context key `default_journal_id`.

---

### **Proposed Fix**

Add `default_journal_id=journal.id` in the context at the point where the journal is still known:

```diff
--- a/addons/account_peppol/models/account_edi_proxy_user.py
+++ b/addons/account_peppol/models/account_edi_proxy_user.py
@@
 move = journal\
     .with_context(
         default_move_type='in_invoice',
         default_peppol_move_state=content['state'],
         default_peppol_message_uuid=uuid,
+        default_journal_id=journal.id,  # ensure correct company is used
     )\
     ._create_document_from_attachment(attachment.id)
```

This allows the EDI decoder to resolve:

```python
journal = self.env['account.journal'].browse(self._context.get("default_journal_id"))
```

Which in turn ensures:

* the invoice is created in `journal.company_id`
* the correct taxes, accounts, fiscal settings, and partner mapping are applied
* multi-company Peppol setups behave as designed

---

### **Impact**

Without this fix:

* All incoming Peppol invoices are created in the wrong company in multi-company environments.
* This leads to:

  * wrong journal assignment
  * wrong fiscal configuration
  * partner mismatches
  * tax errors
  * reconciliation issues

With this fix:

* Each Peppol invoice is correctly routed to the receiving company’s journal
* Behaviour is stable and consistent with Odoo’s EDI design

---

### ✔️ This is a minimal, safe and backward-compatible fix

* It changes only the Peppol integration behavior
* It does not modify EDI core internals
* It uses an existing mechanism (`default_journal_id`) already expected by Odoo
* It matches the intended API contract
* It prevents silent cross-company data corruption

Forward-Port-Of: odoo/odoo#237904

**Steps to reproduce:**
- Go to the restaurant
- Select a table, click on a combo and order it
- Add quantity to the ordered combo and add a note to it
- Select the desired combo options in the popup
- The combos' children lines' qty are not updated and are either too much or 1

**Why the fix:**
When we add a note to an orderline that has qty that has not been sent to the kitchen, we split the line in 2 lines, one with everything that has been sent to the kitchen and one with everything that has not been sent and the note we just added.

This implementation didn't account for the combos, so the combo_line_ids' qty were never updated and stayed as is in the original line, and were set as 1 in the new line.

We now update the children lines' qty at the same time as the parent lines.

This behavior will need to change with the changes made in version  18.3, as this version introduces the possibility of having the same child line multiple times in the same combo, like 2 of the same burger in a single combo.
Another problem is there is currently a bug in 18.3 preventing us from correctly changing the qty of a combo's children by changing the parent's qty if the same item is ordered twice (the qty will still be set to the parent's qty instead of being multiplied). So this will need to be changed once this reaches 18.3

opw-5164102

**Steps to reproduce**

1.Install Accounting, Contacts, and l10n_cz.
2.Create an invoice with a future `invoice date` and confirm it. 
3.Go to Contacts → open the company (res.partner). 
4.Modify any address field (street, zip, etc.) and save. 
5.Return to the invoice → in the chatter, the `date` field has change unexpectedly

> Note: The `date` field is not shown in invoice default form view. Add it manually for clearer reproduction.

**Issue**
- The confirmed invoice `date` changes when updating the company partner’s address.

**Cause**

https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/l10n_cz/models/account_move.py#L20-L24


- When creating an invoice, the `date` field is correctly set based on the 
`taxable_supply_date` while the invoice is in the draft state. After 
confirming (posting) the invoice, it moves to the `posted` state.

- However, when updating the partner address, the `_compute_date` method 
is triggered again, which calls `super()` and recomputes the `date` field 
using the standard logic. Since the invoice is already in the `posted` 
state, the CZ-specific condition is not satisfied, and the `date` gets 
updated incorrectly.

 **Solution**

- Update `_compute_date` to only call super() for invoices in draft state.
- This prevents unwanted recomputation of the `date` on post invoices.

opw - 5086961

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

When setting options like "Loop" or "Hide Player Controls" on an
embedded Vimeo video, these settings were not applied on the final
page after saving.

Steps to reproduce:
===================
- Go to the Website editor.
- Drag and drop a "Media List" or similar snippet.
- Double-click the video placeholder to open the media dialog.
- In the "Video" tab, paste a Vimeo URL.
- Enable "Loop" and/or "Hide Player Controls".
- Save the page.
-> Observe that the video does not loop and the controls are still
  visible.

Cause:
======
When rebuilding the iframe, `generateVideoIframe` was processing the
video's `src` URL through using `escape()` function. This function
is designed to prevent XSS by converting characters like
`&` into their HTML entity equivalent, `&`.

However, Vimeo video URLs use the `&` character to separate query
parameters (e.g., `?loop=1&controls=0`). The `escape()` function
was converting this URL to `?loop=1&controls=0`. but `setAttribute`
already handles URL values safely. so Vimeo player will receive url
containing &.
This broke the URL's structure. The Vimeo player received a malformed
URL, could not parse the parameters correctly, and therefore ignored
the options for looping and controls.

escape was used before cause  The original code was adding the iframe
using `.html(...)`
see commit: https://github.com/odoo-dev/odoo/commit/8749410b1033ddec1207ce1db42d1889a0d2ea33

side note 1: before saving the vimeo video works because we render it
without the double escaping of & (as will be the case for saved video
if this PR is applied)

side note 2: the issue of double escaping also apply to youtube, but it
seems to be ok with superfluous & in URL while in vimeo:

https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1
has the video that doesn't loop, is not muted (so doesn't auto play in
an iframe on most browser) and show controls
https://player.vimeo.com/video/1138854841?autoplay=1&muted=1&autopause=0&controls=0&loop=1:
all option works

Solution:
=========
The unnecessary `escape()` call has been removed.
since the video should be only added using media dialog and the
`setAttribute(...)` will escape it by default

opw-5225261

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

**Description of the issue/feature this PR addresses:**
This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls.

**Current behavior before PR:**
When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life.

**Desired behavior after PR is merged:**
The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times.

task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227)

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

### **Summary**

In a real multi-company setup with multiple Belgian companies registered on Peppol, incoming Peppol invoices are systematically created in the **current user’s company**, instead of the company that actually received the document.

The problem occurs even though the correct journal is identified in `account_edi_proxy_client.user` and used to call `_create_document_from_attachment()`.

### **How to reproduce**

#### **Environment**

* Two Belgian companies: e.g. **Company A** and **Company B**
* Both registered and active on Peppol
* Each company has its own **Peppol purchase journal** (`company.peppol_purchase_journal_id`)
* An accountant with access to both companies

#### **Steps**

1. Trigger Peppol incoming document retrieval (`_peppol_get_new_documents`)

2. Odoo resolves the correct receiving company and journal:

   ```python
   company = edi_user.company_id
   journal = company.peppol_purchase_journal_id
   ```

3. The code uses this journal to import the invoice:

   ```python
   move = journal\
       .with_context(
           default_move_type='in_invoice',
           default_peppol_move_state=content['state'],
           default_peppol_message_uuid=uuid,
       )\
       ._create_document_from_attachment(attachment.id)
   ```

4. **Actual result**:
   The `account.move` is created in **the company of the current user**, *not* in `journal.company_id`.

5. **Expected result**:
   The vendor bill must belong to the company that received the Peppol document (i.e. `journal.company_id`).

This behaviour is reproducible 100% of the time when a user has multiple companies enabled.

---

### **Root Cause**

The selected journal is **never propagated** to the EDI XML decoder.

#### 1. The call in the Peppol module *looks* correct:

```python
journal.with_context(...)._create_document_from_attachment(...)
```

…but `_create_document_from_attachment()` in `account.journal` does *not* use `self` to determine the journal:

```python
invoices = self.env['account.move']
# `self` (journal) is not used at all during decoding
decoders = self.env['account.move']._get_create_document_from_attachment_decoders()
```

So the journal passed to `.with_context()` is effectively **ignored** inside the decoder chain.

#### 2. The XML decoder in `account.edi.format` explicitly uses the *environment company*:

```python
res = edi_format.with_company(self.env.company)._create_invoice_from_xml_tree(...)
```

Thus:

* The company used during invoice creation is **self.env.company**
* That is the **current user’s company**
* Not the Peppol recipient’s company
* Not the journal’s company
* Not the company associated with the Peppol identifier

#### 3. `_create_invoice_from_xml_tree()` supports a journal, but it is never provided

```python
if not journal:
    journal = self.env['account.journal'].browse(self._context.get("default_journal_id"))
```

Since `default_journal_id` is **never set**, the fallback is always used.

---

### **Why the fix requires passing `default_journal_id` explicitly**

Even if it **feels redundant**, it is necessary.

* We *are* calling the decoder through `journal.with_context(...)`
* But `_create_document_from_attachment()` does **not** use `self`
* The decoder receives **no reference to the journal**
* And is executed in a context where `self.env.company` = current user’s company

Because Odoo intentionally allows calling `_create_document_from_attachment()` on an **empty journal recordset**, the decoder cannot deduce the journal from `self.id`.

Therefore, the only reliable way to pass the journal down the stack is through the context key `default_journal_id`.

---

### **Proposed Fix**

Add `default_journal_id=journal.id` in the context at the point where the journal is still known:

```diff
--- a/addons/account_peppol/models/account_edi_proxy_user.py
+++ b/addons/account_peppol/models/account_edi_proxy_user.py
@@
 move = journal\
     .with_context(
         default_move_type='in_invoice',
         default_peppol_move_state=content['state'],
         default_peppol_message_uuid=uuid,
+        default_journal_id=journal.id,  # ensure correct company is used
     )\
     ._create_document_from_attachment(attachment.id)
```

This allows the EDI decoder to resolve:

```python
journal = self.env['account.journal'].browse(self._context.get("default_journal_id"))
```

Which in turn ensures:

* the invoice is created in `journal.company_id`
* the correct taxes, accounts, fiscal settings, and partner mapping are applied
* multi-company Peppol setups behave as designed

---

### **Impact**

Without this fix:

* All incoming Peppol invoices are created in the wrong company in multi-company environments.
* This leads to:

  * wrong journal assignment
  * wrong fiscal configuration
  * partner mismatches
  * tax errors
  * reconciliation issues

With this fix:

* Each Peppol invoice is correctly routed to the receiving company’s journal
* Behaviour is stable and consistent with Odoo’s EDI design

---

### ✔️ This is a minimal, safe and backward-compatible fix

* It changes only the Peppol integration behavior
* It does not modify EDI core internals
* It uses an existing mechanism (`default_journal_id`) already expected by Odoo
* It matches the intended API contract
* It prevents silent cross-company data corruption

Forward-Port-Of: odoo/odoo#237904