This issue occurs because, in the recent [commit], `sign_request` was changed to `sign_item`, but the `sign_item.exists()` check is performed after the type comparison, resulting in a `TypeError`.

Traceback:
```py
  File "/home/odoo/src/odoo/saas-19.2/odoo/addons/base/models/ir_http.py", line 415, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/saas-19.2/odoo/http/routing_map.py", line 207, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/saas-19.2/sign/controllers/main.py", line 708, in get_sign_request_items
    if not sign_request.exists() or not consteq(sign_item.access_token, token) or not sign_item.exists() or not sign_item.signer_email:
TypeError: unsupported operand types(s) or combination of types: 'bool' and 'str'
```

Solution:
We first perform the existence check and then compare the types.

[commit]: https://github.com/odoo/enterprise/pull/111786/changes/f40082f4e6f50dccbfa639edbef08428868cb31d

sentry-7376866293

Forward-Port-Of: odoo/enterprise#112659

When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely.

Step to reproduce:
- Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025)
- Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method
- Compute the board and observe that entries from January to April 2026 are missing

Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal.

opw-6016834

Forward-Port-Of: odoo/enterprise#113521

Currently, when a user creates a kit, the price of the kit itself is included in stock valuation.

## Steps to produce:
* Install `mrp_account` without demo data.
* Create a product with inventory tracking enabled.
* Create a BoM of type kit for that product.
* Add component products with a defined cost and on-hand quantity greater than 0 to the BoM.
* Recompute the kit product’s cost from its BoM on the product page.
* Go to Inventory > Reporting > Stock.

## Observed Behavior:
The cost of the kit is currently being included in the stock valuation.

For example, consider a kit product called **“Computer”** that is composed of the
following components:
| Product | Quantity | Cost |
|--------|--------|--------|
| CPU | 1 | $300 |
| Motherboard | 1 | $300 | 

The total cost of the Computer kit is therefore $600. Since the Computer is made up of the CPU and Motherboard, the total inventory value should be $600. However, the system is currently calculating the total inventory value as $1,200
, which is incorrect because it is counting both the kit and its components.

## Root cause:
This behavior started after the refactor in [1], where the `_compute_value_svl`
function was replaced by the `compute_value` function to calculate both average and total value for 
inventory valuation.

With this change, the new compute function in [2] now also includes kit products when calculating inventory valuation based on their costing method.

In earlier versions, this did not occur because `_compute_value_svl` depended on valuation layer groups. Kit products were excluded at [3] through the  `_get_valuation_layer_groups()` call, as illustrated in image [4].

[2]-
https://github.com/odoo/odoo/blob/1b9937a702fbeb47cd6d42d8119cead5828fd3fe/addons/stock_account/models/product.py#L139-L169 
[3]-
https://github.com/odoo/odoo/blob/a9d2e54201173d1d2d5ab97de0904d63a4b6b82b/addons/stock_account/models/product.py#L284

## Solution:
To ensure correct total inventory valuation, kit products should be excluded from valuation and only their individual components should be calculated.

This can be achieved by modifying the domains used in 'action_product_stock_view` and `_get_accounts_by_product`
to exclude the kits so that the kit products get filtered out, allowing the report to consider only its components.

**Before:**
<img width="1857" height="938" alt="image" src="https://github.com/user-attachments/assets/bbd4eb94-ba1a-429a-a61c-afbe33729ac0" />

**After:**
<img width="1915" height="883" alt="image" src="https://github.com/user-attachments/assets/c93d55c8-8197-4e57-9f87-b2159fe67d87" />

[1]:
https://github.com/odoo/odoo/pull/222169/commits/6e694b79b8892d693117f6c79df1a2d3a4759f4f 
[4]:
https://drive.google.com/file/d/1g4BzGscCW2K0rf5iDKrq-psYRlKhYkDP/view?usp=sharing

opw-5462515

Forward-Port-Of: odoo/odoo#244030

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.
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_version instead of hr_leave_allocation in the hr_leave_employee_type_report.

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

opw-5220577

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





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

Forward-Port-Of: odoo/odoo#258562

### Issue:
Color picker preview not showing correctly when a theme with a
gradient background is applied to the header.

### Steps to reproduce:
1. Go to the Theme tab and open the color presets dropdown.
2. Select any preset and set its background to a gradient.
3. Apply this theme to the header.

### Reason:
- The color picker preview relies on `getComputedStyle` of the current
  editing element to determine what background to show.
- For the header, the targeted editing element is `#wrapwrap > header`,
  but the actual gradient styles are applied to its inner `<nav>`
  elements (e.g., via `customizeWebsiteColorAction`).
- Since the `background-image` property is never applied directly to the
  header element itself, computing its style does not capture the 
  gradient defined on its inner elements, resulting in an incorrect or
  missing preview.

### Fix:
- Avoid depending strictly on the computed style of the main editing
  element for generating the preview.
- Ensure the preview accurately reflects the applied styles by utilizing
  CSS variables, even when certain builder actions apply those styles to
  inner elements rather than the primary targeted element, as
  demonstrated in the header example with `customizeWebsiteColorAction`.
  
task-[6075788](https://www.odoo.com/odoo/project/974/tasks/6075788)

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

Forward-Port-Of: odoo/odoo#256566

The invoice outstanding credits/debits widget currently displays all reconcilable items for a partner across the same account, regardless of the company they belong to.

In multi-company environments, specifically when accounts have been merged, this allows users to see
and try to reconcile payments from Company A into an invoice from Company B. This action eventually triggers a validation error stating that entries must belong to the same company.

This commit adds a company filter to the widget's logic to ensure only relevant outstanding payments are suggested, preventing cross-company reconciliation errors and improving UX.

**Description of the issue/feature this PR addresses:**
This PR fixes a validation error in multi-company environments where the invoice_outstanding_credits_debits_widget suggests payments or credit notes belonging to a different company than the current invoice.

The issue typically arises when a partner has outstanding transactions in multiple companies and the accounts (e.g., Account Receivable) have been merged, allowing the widget to query lines that are not valid for the current record's company context.

**Current behavior before PR:**
When viewing an invoice for Company A, the "Outstanding Credits/Debits" widget displays all reconcilable account.move.line records for that partner that match the account type, regardless of their company_id.

If a user clicks "Add" on a payment that belongs to Company B, Odoo attempts to reconcile them, resulting in a traceback or a validation error:

"Invalid Operation: All tracebacks/entries must belong to the same company."

This creates confusion for the end-user, as they are presented with "ghost" credits that cannot actually be applied.

**Desired behavior after PR is merged:**
The invoice_outstanding_credits_debits_widget (and the underlying logic in account.move) will strictly filter the suggested outstanding items by self.company_id.

Users will only see and be able to reconcile payments, credit notes, or debits that belong to the same company as the invoice they are currently processing. This ensures data integrity and a seamless UX in multi-company setups.

**Steps to reproduce:**
1) Enable Multi-Company: Ensure you have at least two companies (e.g., Company A and Company B) active in your database.

2) Chart of Accounts Setup:

In both companies, use the same account for Receivables (or merge them so they share the same ID/Code if testing a migrated environment).

3) Ensure the account is marked as Allow Reconciliation.

4) Create a Payment in Company B:

5) Post the payment so it remains as an "Outstanding Receipt".

6) Create an Invoice in Company A

7) Confirm/Post the invoice.

8) Check the Widget:
Scroll down to the bottom of the Invoice form in Company A.

9) Observe the "Outstanding Credits" widget.

The Error:
The payment from Company B will appear as an available credit for the invoice in Company A.

10) Click on "Add".

A validation error (UserError) will pop up: "All entries must belong to the same company."

**video**
https://drive.google.com/file/d/1PfBxupP8t-t21wsP2FIgNXFnTP0Zq140/view

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

Forward-Port-Of: odoo/odoo#255875

### Steps to reproduce:

- In the settings Dropshipping
- Put you warehouse in 2 steps delivery
- Create a kit product with 2 components: COMP1, COMP2
- Set a vendor on COMP2 and the dropship route
- Create and confirm an SO for 1 unit of your kit
- Validate the ship and pick for COMP1
- Confirm the PO for COMP2 and validate the associated dropship
#### > The qty_delivered on the sol is still at 0

### Cause of the issue:

The `delivered_qty` is computed via the `_prepare_qty_delivered`: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale/models/sale_order_line.py#L887-L902 However, since at least on of the component is dropshipped, the qty_delivered is computed by this condition: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale_mrp/models/sale_order_line.py#L54-L63 Which is 0 since the pick `location_dest_id.usage` is not `customer`.

### Additional issue:

The delivered quantity of a Kit with at least one dropshipped component can only be 0 or the full demand.

- In the settings enable Dropshipping
- Create a kit product with 2 components: COMP1, COMP2
- Set a vendor on COMP2 and the dropship route
- Create and confirm an SO for 3 unit of your kit
- Validate the delivery for COMP1 for 2 units and backorder
- Confirm the PO for COMP2 and validate the associated dropship for 1 unit and do not backorder
#### > The qty_delivered on the sol is 0 instead of 1
- Cancel the backorder for COMP1
### > The qty_delivered on the sol is 3 instead of 1

### Cause of the issue:

This is caused by the exact same dropship computation: https://github.com/odoo/odoo/blob/9b9ff3ddcba6f0c9d37d08fb4fb900bed3b396a4/addons/sale_mrp/models/sale_order_line.py#L63-L66

### Note:

The behavior should be consistent if the components are fully dropshipped or MTO buy and as such they should not be considered to be in all or nothing shipping policy.

opw-6040640

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

Forward-Port-Of: odoo/odoo#257617

Concurrent processing of emails with the same `Message-Id` can create duplicate records.

### Steps to reproduce

1. Configure multiple mail aliases (e.g., two helpdesk teams).
2. Send one email with both aliases as recipient.

The Mail Transfer Agent may invoke `odoo-mailgate.py` once per recipient, resulting in concurrent processing of the same email in separate transactions.

We expect one record per alias/team, but duplicates may be created.

### Cause

This is a race condition in the `Message-Id` deduplication logic, caused by concurrent transactions and PostgreSQL snapshot isolation.

Odoo uses the `REPEATABLE READ` isolation level. This means that each transaction takes a snapshot of the database at its first query and cannot see changes committed by other concurrent transactions.

When two concurrent transactions process the same email:

1. Both enter `message_process` and take their snapshot.
2. Both search for the `Message-Id`. Because their snapshots don't include each other's work, both find nothing.
3. Both create records.

Even if one transaction commits before the other performs the check, the second transaction still uses its original stale snapshot and create duplicates.

### Fix

After the initial duplicate check, attempt to acquire a transactional advisory lock on a hash of the `Message-Id` using `pg_try_advisory_xact_lock`. If another transaction is already processing the same email and holds the lock, the call returns false and the email is treated as a duplicate. If the lock is acquired, processing continues as normal.

opw-5116492

Forward-Port-Of: odoo/odoo#258847
Forward-Port-Of: odoo/odoo#250027

[FIX] point_of_sale: detect refund+eWallet orders as refunds for invoice signs
Refund orders paid through eWallet top-up can have a net total of 0, which
made refund detection based only on negative totals inconsistent. As a result,
some refund flows were treated as normal invoices and refund tax/invoice signs
were incorrect.

Steps to reproduce:
-------------------
* Configure an eWallet program in POS.
* Create and pay a POS order for one product, then invoice it.
* Refund that order and choose eWallet as refund payment method (refund + top-up).
* Validate and inspect the generated accounting document.

> Observation:
The refund flow may not be consistently treated as a refund when the order’s
net amount is 0, causing incorrect invoice move type/sign handling and wrong
tax booking behavior.

Why the fix:
------------
Refund detection now also relies on `refunded_order_id` in key paths:
* `_compute_prices`: apply refund factor when order is linked to a refunded order
  (or already negative), so totals/taxes keep refund semantics.
* `_prepare_invoice_vals`: create `out_refund` when the order is linked to a
  refunded order (or has negative total), ensuring a credit note is produced.
* `_prepare_base_line_for_taxes_computation`: consider refund context with
  `is_refund` or negative total for tax base sign consistency.

This keeps existing negative-total refund behavior while correctly handling
refund+eWallet cases where the arithmetic total can be 0.

opw-5426818

Forward-Port-Of: odoo/odoo#247948