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

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

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

Since odoo/odoo#249455 the order payload from the self order frontend is being checked to ensure the data is valid. However, these checks did not account for the situation where payment data is included, as is the case when using a self order kiosk with a payment terminal connected. The result was that using the kiosk with a payment terminal would result in an error even though the payment was successful on the terminal.

Steps to reproduce:
- Configure a self order kiosk POS
- Connect a payment terminal (Adyen, Stripe, Viva etc.)
- Try to pay for an order from the kiosk

EXPECTED:
- The order is made successfully.

ACTUAL:
- A generic error message is shown and the order fails. The payment goes through successfully on the payment terminal.

The fix is to allow a payment to be included in the self order data, but only in Kiosk mode and only if the payment amount is valid.

We also now validate that the self ordering type is correct, this
ensures that a kiosk payment cannot be spoofed for a mobile self order
POS.

Finally, there is also a small change for Viva.com to use the PoS config
name instead of UUID, since UUID is no longer loaded in self order.

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

Forward-Port-Of: odoo/odoo#256042

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

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

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

[FIX] html_builder, *: hide the size of CORS-protected images
*: html_editor

Steps to reproduce:
- Add an image on the website.
- Replace it with a CORS-protected image.

-> The image options display a size, but it is incorrect.

The problem is that it is not the real size of the image but the size of
a default image (due to it, if you replace the image by another CORS
protected one, you'll see that the size of the image remains the same).
Indeed, the size of an image (in bytes) is computed from the length of
the raw b64 content of the image, on which a ratio of 3/4 is applied.
Because the image is CORS protected, we can not retrieve the raw b64 of
the image so the image size should not be displayed.
This commit hides the size of CORS protected image as it is impossible
to retrieve.

Note: example of a CORS protected image:
https://tinyjpg.com/images/social/website.jpg 

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, *: correctly determine image mimetype
*: html_editor

The goal of this commit is to improve the way the mimetype of an image
is determined if the information is not in the DOM. Before this commit,
the system relied on the extension of the image source to determine its
mimetype. This is not really robust and it is easily trickable. For
example, in `html_editor`, if an image in a html field comes from an
attachment, its `src` attribute will end by the attachment name. If a
user changes the attachment name extension, the next time the image is
added on the DOM, the extension is changed but the mimetype of the image
is unchanged.
To solve the problem, the mimetype of the image is determined thanks to
the headers of the http request to the `src` of the image. That way, the
information comes from the server hosting the image.

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, website: enable the quality change on shaped img

This commit improves [this one] by adding a test (this commit was
created before [this one] was merged).

[this one]: https://github.com/odoo/odoo/commit/738d5fb5ae2154e1f6993817fab5471d2d4384fa

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, *: hide shape option for CORS-protected images
*: website

Steps to reproduce the problem:
- Add an image on the page.
- Replace the image by a CORS protected one.
- Try to apply a shape on the image.

-> Traceback

The goal of this commit is to hide the "Shape" option if the "original
image" of an image is not retrievable. Indeed, in this case, the option
will fail to apply correctly.

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, *: avoid displaying options that are not compatible
*: html_editor, website

Few options like filter, quality, format and cropping rely on canvas to
work. The problem is that it does not work correctly for mimetypes like
`svg` or `gif`. Indeed, if an image modification is done on such images,
it will automatically be transformed into a `png` by default. To avoid
it, this commit hides the options that rely on a canvas manipulation
when clicking on a `svg` or `gif` image. The process image function has
also been adapted to not try to transform an image if its mimetype is
not compatible with a canvas transformation. Instead, those images are
directly transformed into `b64` images without any transformation.
Thanks to it, a shape can be applied on a `svg` or a `gif`.

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, *: apply shape on replaced svg and gif images
*: website

Steps to reproduce the problem:
- Add a "Text-Image" snippet on the page and add a shape on the image.
- Replace the image by a svg or a gif.

-> A shape is displayed on the image options but the shape is not
applied on the image.

task-5405262

---------------------------------------------------------------------------------------------------------------------------------------------

[FIX] html_builder, *: avoid copying options on new incompatible images
*: html_editor, website

Steps to reproduce:
- Add an image on the website.
- Add a shape on the image.
- Replace the image by a CORS-protected one.

-> The image still has the shape data attributes on its HTML element
while it should not as it does not have the prerequisites to have a
shape (it does not have an original source). The same problem exists
with the hover effect.

This commit moves the logic that transfers the shape and hover effect on
replaced images from `html_editor` to the responsible plugins in
`html_builder` and `website`. It also adds a check to verify that the
replaced image is eligible to have a particular option before
transferring its data information.

task-5405262

Forward-Port-Of: odoo/odoo#259032
Forward-Port-Of: odoo/odoo#251703

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

### Steps to reproduce:
	- Create an accrual plan of one level to give 20 days at the start of the year
	- Create an allocation with different mode than 'By Employee'
	- Set the accrual plan for the allocation and date from 1st Jan
	- Notice the Allocation number of days doesn't get automatically calculated

### Cause:
This is happening because when trying to process the accrual plan we won't have any records in the field employee_id

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L892-L893

And since employee_id is computed field when computing it we don't handle the case of any other mode other than 'By Employee'.

https://github.com/odoo/odoo/blob/bcdd12d13d73915e565fd2c8478b936a16efb9f4/addons/hr_holidays/models/hr_leave_allocation.py#L259-L270

### Fix:
If we have different mode in the allocation we fetch the employees in this mode (Department, Company, Employee Tag) and set them as the allocation employee_ids so when computing the employee_id we will have a record in the field and it won't be null

P.S. In the forward port we will have to introduce another fix for the multi allocation wizard

opw-5888023

Forward-Port-Of: odoo/odoo#258520
Forward-Port-Of: odoo/odoo#247091

Before this commit, the message highlight was too distracting. This was improved [1] so that highlighted message doesn't have the vertical translation during the highlight duration. To make the message more visible than the other messages, other messages have their opacity reduced.

While reduced opacity is good, there was an extra blur, which is more distracting. This commit fixes it by removing it.

Also at the end of message highlight, the scroll position of message list was changing when this shouldn't. This happens for 2 reasons:

1. The "Welcome to conversation" message was mistakenly displayed during the message highlighting, thus when message highlight ended its removal would substract some scrollTop and move scroll up.
2. The "Load More" was temporarily not shown during the message highlight. This is a problem because when message highlight ended, this was adding slightly more scollTop and move scroll down.

The "Welcome to conversation" should not be shown when there's logically a "Load more", which this commit fixes. The hiding of "Load More" was intended to avoid their triggering when opening conversation [2], but the logic around these triggers had been improved [3] therefore this is no longer necessary. This commit relaxes the showing of "Load more" to display them even during a message highlighting.

Task-6121035

[1]: https://github.com/odoo/odoo/pull/246989
[2]: https://github.com/odoo/odoo/pull/181392
[3]: https://github.com/odoo/odoo/pull/216776

Before / After

_(before visual artifacts come from GIF recorder that doesn't like blur)_
![before](https://github.com/user-attachments/assets/2a1ab290-7df3-49db-b132-67599ef693e7)
![after](https://github.com/user-attachments/assets/ad531b18-71af-4704-ad5a-29e630e87d6a)

[FIX] purchase: set the correct price in alternative PO
Steps to reproduce the bug:
- Enable "Purchase Alternatives" in settings
- Go to Accounting > Configuration > Taxes:
    - Configure a 15% purchase tax:
    - Advanced Options tab:
    - Included in Price: enabled

- Create a storable product "P1":
    - Tax: 15%
    - In the Purchase tab, add vendors:
        - "Azure Interior": price = $10, min qty = 1
        - "Deco Addict": price = $15, min qty = 1

- Create a purchase order for "Azure Interior":
    - Order 100 units → total price is automatically computed as $1000
- Create an alternative purchase order:
    - Vendor: "Deco Addict"
    - Copy products: enabled

Problem:
The price is $1360, instead of $1500

When the alternative purchase order is created and the product is set
on the purchase order line, the required onchange methods are not
triggered:
https://github.com/odoo/odoo/blob/ad253ef4c2cb06536b99bb919a3e01ed980d2e96/addons/purchase/models/purchase.py#L1169

As a result, both the unit price and the taxes are missing on the
purchase order line. When `_compute_price_unit_and_date_planned_and_name`
is triggered, it attempts to compute the `price_unit`.

https://github.com/odoo/odoo/blob/fb24ad03fc47a303fa8719c0795e1afa9a7eb821/addons/purchase/models/purchase_order_line.py#L345-L346

At this point, it checks whether the purchase order has a vendor.
Since "Deco Addict" is set, it calls `_fix_tax_included_price_company`
using:
- the supplier price ($15)
- the supplier tax (15%)

However, since no taxes are yet set on the purchase order line,
`_fix_tax_included_price_company` incorrectly assumes the price is
tax-included and converts it to a tax-excluded price
(~13.04 instead of 15).

https://github.com/odoo/odoo/blob/7076b4f4d0d933d93b24e8e4c7cf21ef0b0008e5/addons/account/models/account_tax.py#L571-L573

Then, a 15% tax is applied on top of this incorrect base price, leading
to the wrong total.

opw-6047004

Forward-Port-Of: odoo/odoo#258154

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#258882
Forward-Port-Of: odoo/odoo#257586