Before this commit:

- Product retrieval during import relied on exact name match and substring (ilike) search.
- Exact name search was case sensitive, so values like `Network Cable` would not match `Network cable`.
- Substring matching could return unrelated products (e.g. `Wireless bluetooth speaker` gets matched with
  `Wireless bluetooth speaker battery`), leading to unrelated matches.

After this commit:

- Exact name search is now case insensitive, allowing matches such as `Network Cable` and `network cable`.
- Substring based matching has been replaced with a similarity ratio (90%) to reduce false positives and improve matching reliability against customer database product names.

Technical:

- Replaced `=` with `=ilike` in the exact name search domain to make the lookup case insensitive.
- Similarity ratio is computed using Python's `difflib.SequenceMatcher` on product names, with a minimum threshold of 90% to qualify as a match.
- Added system parameter for configurable product name similarity threshold.

task-5951469

Forward-Port-Of: odoo/odoo#257538
Forward-Port-Of: odoo/odoo#252147

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

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable product with a vendor using the MTO route
- Create and confirm an SO for 1 unit of that product
- Cancel and reset to draft the associated draft PO
- Update the SO demand from 1 to 2 units
#### > A new draft PO is created rather than updating the existing one.

### Cause of the issue:

Both the confirmation and the demand updates of the SO call the `_action_launch_stock_rule` to generate the related PO. The procurement and PO generated in both cases including the `stock_reference_ids` of the SO: https://github.com/odoo/odoo/blob/3891dd471d64629634644c0b022a171bbaa65b49/addons/sale_stock/models/sale_order_line.py#L277-L289
However, cancelling the PO will remove its assocaited stock reference: https://github.com/odoo/odoo/blob/3891dd471d64629634644c0b022a171bbaa65b49/addons/purchase_stock/models/purchase_order.py#L201-L202
As such, when the second procurement is run, the `_run_buy` will not consider the existing PO without reference as a valid candidate to update:
https://github.com/odoo/odoo/blob/3891dd471d64629634644c0b022a171bbaa65b49/addons/purchase_stock/models/stock_rule.py#L370-L372
An it will therefore create a new one:
https://github.com/odoo/odoo/blob/3891dd471d64629634644c0b022a171bbaa65b49/addons/purchase_stock/models/stock_rule.py#L101-L115

opw-5940590

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

Forward-Port-Of: odoo/odoo#258696

Steps to produce:
---
- Install the `Sales` module.
- Enable discounts from settings.
- Create a Sale Order with a negative discount on an order line.
- Preview the Sale Order and click on the view details button.

Issue:
---
- Negative discount values are not shown in the preview (portal view), but they are displayed in the generated PDF.

Root cause:
---
- At [1], the portal template includes a condition to display discounts only when they are greater than 0, while the report templates lack this check, leading to inconsistent behavior.

Solution:
---
- Applied the same condition in the report templates to align the PDF output with the portal preview behavior.

Before:
---
<img width="787" height="136" alt="image" src="https://github.com/user-attachments/assets/d32311be-4aec-4d6f-b905-d5e52f712ba4" />

After:
---
<img width="775" height="139" alt="image" src="https://github.com/user-attachments/assets/2614a8ad-dca6-49ca-b720-5c234aa91cf6" />


[1]https://github.com/odoo/odoo/blob/0f463fd247d2f5da79d6ec2b6bec18774f6f600b/addons/sale/views/sale_portal_templates.xml#L539

Enterprise PR: https://github.com/odoo/enterprise/pull/111916

opw-6061568

Forward-Port-Of: odoo/odoo#258981
Forward-Port-Of: odoo/odoo#255735

PR #212726 removed a Many2One field and replaced it with an existing binary field (`l10n_it_edi_attachment_file`) and a new Char field (`l10n_it_edi_attachment_name`) to store E-invoice files as XMLs. This change was made for security reasons.

This pre-existing binary field was already used for importing SDI documents, which caused errors resolved in PR #252806.

The new char field was not set during the SDI import process in PR #212726. This can cause errors when exporting invoice documents, as our code sees content in the binary field and expects the name to also be present. See [`_get_invoice_legal_documents()`](https://github.com/odoo/odoo/blob/f48f221c91b8d123bcaf1c4d8ed6c7dfba763ae6/addons/l10n_it_edi/models/account_move.py#L411).

This commit ensures that the name of an imported SDI document is set in the move's `l10n_it_edi_attachment_name` field.

opw-6023263
[link](https://www.odoo.com/odoo/my-tasks/6023263)

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

Forward-Port-Of: odoo/odoo#257586

**Problem:**
When creating a new stock.move.line in the moves view (accessed via smart button from a picking), the newly created line disappears after any refresh action (manual refresh or triggering "Put in Pack").

**Steps to reproduce:**
1. Open a receipt/picking operation
2. Click on the "Moves" smart button to open the detailed operations view
3. Create a new stock.move.line record
4. Click "Put in Pack" or manually refresh the page
5. Observe that the newly created line disappears

**Current behavior:**
The newly created stock.move.line disappears from the view after refresh, and only reappears if you navigate back to the picking and then return to the moves view.

**Expected behavior:**
The newly created stock.move.line should remain visible in the view after refresh or any action that triggers a view reload.

**Cause of the issue:**
  The action_detailed_operations method uses a static domain [('id', 'in', self.move_line_ids.ids)] that captures a snapshot of move line IDs at the moment the action is opened.
  https://github.com/odoo/odoo/blob/22ac818970f104a732cc7d24afc440cf0e6d74bd/addons/stock/models/stock_picking.py#L1204-L1212 When a new stock.move.line is created in this view, its ID is not included in the original static list. Any refresh (manual or triggered by operations like "Put in Pack") re-applies this static domain, filtering out the newly created lines because their IDs weren't captured in the initial list.

**Fix:**
Using a dynamic domain based on picking_id ensures all move lines belonging to the picking are always visible, regardless of when they were created. This aligns with the expected behavior of showing "all move lines for this picking" rather than "only the move lines that existed when the view was opened". The relational lookup [('picking_id', '=', self.id)] is re-evaluated on each refresh, automatically including any newly created lines that have the correct picking_id set.

opw-5398620

Forward-Port-Of: odoo/odoo#251619
Forward-Port-Of: odoo/odoo#247170