Steps to reproduce:
-------------------------
1. Install the Time Off module.
2. Go to Time Off > Management > Allocations, create an allocation
   for an employee, and approve it.
3. Go to Reporting > Balance and apply the filter
   Department > Employee.
4. Change the employee’s department.
5. Create an allocation for the same employee and approve.
6. Apply the Department > Employee filter again.

Observed behaviour:
----------------------------
After a department change:
* Existing allocations keep the old department
* New allocations use the new department

As a result, duplicate employee entries appear in the report

Cause:
----------
It is using [allocation.department_id.](https://github.com/odoo/odoo/blob/4c91eb3b2469cd04718005162b4572e9e3d07e72/addons/hr_holidays/report/hr_leave_employee_type_report.py#L62)
Allocations store the department at creation time, which may differ
from the employee’s current department, causing an incorrect report filtering.

Solution:
------------
Fetch department_id from hr_employee instead of hr_leave_allocation in the
hr_leave_employee_type_report and hr_leave_report.

This ensures:
* Leave balances always follow the employee’s current department
* Correct aggregation when grouping by Department → Employee

**NOTE:**
Before this [commit](https://github.com/odoo-dev/odoo/commit/976e0f9a667f4573e73e33737425d370ec1e1452), the issue was resolved starting from version saas-18.4, as the balances were filtered using the employee's department (via `hr_version`).
https://github.com/odoo/odoo/blob/104a33f093ca583c91db9705f087c73d8464c173/addons/hr_holidays/report/hr_leave_employee_type_report.py#L65-L74
related commit: https://github.com/odoo/odoo/commit/21f18b1a6fdbf1a01c3dda83acfa66addd01a759

Since `hr_version` is no longer used in the query, this issue needs to be addressed again and forward-ported to all versions up to master.

Before:
<img width="1238" height="857" alt="image" src="https://github.com/user-attachments/assets/15e1293b-dc50-4067-a12f-079c046c2074" />

After:
<img width="1247" height="824" alt="image" src="https://github.com/user-attachments/assets/feea32de-0d9c-4eef-9ae5-639f4658560c" />


opw-5220577




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

Forward-Port-Of: odoo/odoo#243076

Steps to produce:
---
- Install `Sales` module.
- Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab.
- Confirm the sale order and create an invoice.

Issue:
---
- In the email notification sent to the salesperson, the record reference displays as False and the amount shows as 0.00.

Root cause:
---
- Here at [1], the record name is False because the invoice is still in draft state.
- In [18], _sync_invoice sets amount_currency = line.balance for new
  lines, but balance is precomputed as 0 before the INSERT because
  _compute_balance returns 0 for invoice lines. In [17] it read
  price_subtotal directly, which is always correct.
- In 17.0 the same mail fires at the same moment, but _sync_invoice
  had already set balance = −295 and amount_currency = −295 from
  price_subtotal, so the email reads the correct 295.00.

Solution:
---
- Use record.display_name instead of record.name, as display_name is always present regardless of the record state.
- Use the tax totals amount instead of amount_total, which is not yet computed on draft invoices.

[1]https://github.com/odoo/odoo/blob/0bcc34ec2f92b9b95cde321423d810002bb317ce/addons/account/models/account_move.py#L6478
[18]https://github.com/odoo/odoo/blob/b0a50104a12b205958316d382b4c7b2176395877/addons/account/models/account_move_line.py#L1566-L1610
[17]https://github.com/odoo/odoo/blob/73c076893de79df5a86aa970fde46a7aacbeaf3d/addons/account/models/account_move_line.py#L1536-L1585


Before:
---
<img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/48c2dc03-765a-49c3-bad3-fd0b14405786" />

After:
---
<img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/53682171-155f-46b3-85dd-0c7c98482067" />


opw-6023827
---

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

Forward-Port-Of: odoo/odoo#254862

Currently, when a user creates a quotation from the Opportunities available in Contacts, archived warehouses are also considered for the quotation.

## Steps to replicate:
- Install Sales, CRM, and Inventory.
- Create a new Warehouse and move it to the first position in the warehouse list view (highest priority).
- Archive the newly created warehouse.
- Navigate to Contacts > Acme Corporation > Opportunities >Office Design Project
- New Quotation > Other Info > Delivery and check the Warehouse field.

## Observed behavior
The archived warehouse is still assigned to the Warehouse field in the Delivery section. This issue does not occur when the user creates a quotation directly from the CRM app, it only happens when the quotation is created through the Contacts apps.

## Root cause:
This unintentional behavior was introduced after commit [1]. When a user opens 'Opportunities' from the contacts view, the function `action_view_opportunity` [2] is triggered, which sets `active_test` to False in the context.

Later, when a new quotation is created, the compute method [3] is executed. This method calls `_get_default_warehouse_id` [4], which performs a search. Because `active_test` is already set to False in the context, the search also includes archived warehouses, causing them to be fetched unintentionally.
[2]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/crm/models/res_partner.py#L39-L53 [3]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/sale_stock/models/sale_order.py#L194-L204 
[4]:
https://github.com/odoo/odoo/blob/bd18ecdf179f9a5f902d78af13dad62125c82550/addons/stock/models/res_users.py#L9-L12

## Solution:
Explicitly set `active_test=True` in the context when preparing the quotation for an opportunity. This ensures that archived warehouses are excluded from the search and prevents them from being selected.

**Alternate Solution:**
We could also make `active_test` to true when searching for warehouse directly as well.
```py
 def _get_default_warehouse_id(self): 
     # !!! Any change to the following search domain should probably 
     # be also applied in sale_stock/models/sale_order.py/_init_column. 
     return self.env['stock.warehouse'].with_context(active_test=True).search([('company_id', '=', self.env.company.id)], limit=1)
```
[1]:
https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 

opw-5999034

Forward-Port-Of: odoo/odoo#252166

Issue:
--
The query created by the function '_compute_sale_order_ids' takes
around 20-40 seconds since its doing "WHERE" searches on millions
of stock.picking records

Fix:
--
Added an index to the "lot_id" field of the stock.move.line model.
(Already existing databases can be fixed by using the webshell)

Steps to recreate the issue:
--
1. Have around a million stock.picking records
2. Go to "Inventory/Products/Lots/Serial Numbers"
3. Select any existing record or create and save a new one
4. These actions will take around 20-40 seconds to complete

Before this commit:
--
Selecting or saving any 'stock.lot' takes around 20 seconds

After this commit:
--
Selecting or saving any 'stock.lot' takes around 1-4 second

Benchmark:
--
Benchmark test was done one a database with ~4000 stock.move records and
1.74 million stock.picking records
Opw-5459842
| Before this Commit | ~20 seconds
| After this Commit | **~1-4 seconds & Memory usage just a little bit higher

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

Forward-Port-Of: odoo/odoo#255255

**Steps to reproduce:**
* Install `l10n_sa_edi` module.
* Create a parent company and a child company, both with the same VAT number.
* Onboard the parent company's Sales journal with ZATCA.
* Onboard the child company's Sales journal with ZATCA. Create a journal for the child if there is no journal.
* Change the child company's ZATCA API mode to any other mode.

**Observed behavior:**
* Changing the child company's API mode resets and unboards the parent company's Sales journal as well.

**Cause:**
* In `res.company.write`, when `l10n_sa_api_mode` changes, journals to reset are fetched using `_check_company_domain(company)`.
* `account.journal` uses `check_company_domain_parent_of`, which returns journals where `company_id` is a parent of the given company — so passing a child company also matches journals belonging to the parent.

**Fix:**
* Replace `_check_company_domain(company)` with a direct `('company_id', '=', company.id)` filter, so only journals strictly owned by the company being modified are reset.

opw-6099340

Forward-Port-Of: odoo/odoo#258006