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

### Issue before this commit:
When a sales order with a product invoiced on delivered quantities is fully delivered and then completely returned the delivered quantity is reset to zero. In this situation, where nothing has been invoiced and nothing remains to be invoiced, the invoice status of the sales order line is incorrectly set to "Fully Invoiced" instead of "Nothing to Invoice".

### Steps to reproduce the issue:
1. Create a new quotation for a storable product.
2. Confirm the order.
3. Validate the delivery of the product.
4. Perform a return for the product
5. Validate that return to simulate a customer return.
6. The sales order details correctly reflect that the delivered quantity and invoiced quantity are both zero. Despite these values—which indicate there is nothing to invoice—the invoice status on the quotation erroneously displays as "fully invoiced".

### Cause of the issue:
The invoice status computation includes a fallback logic that marks a sales order line as "invoiced" when all related stock moves are either done or cancelled. However, this logic does not verify whether any quantity remains effectively delivered. As a result, after a full return, even when qty_delivered = 0, the condition is still met and the line is incorrectly marked as fully invoiced.

### Reason to introduce the fix:
A fully returned sales order line with no delivered and no invoiced quantity should not be considered fully invoiced. The fix ensures that the fallback to "invoiced" only applies when there is a strictly positive delivered quantity, preventing incorrect invoice status after full customer returns.

opw-6014772

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

Forward-Port-Of: odoo/odoo#257942
Forward-Port-Of: odoo/odoo#254871

Pre-requisites:
------------------------------------------
1. Install `sale_project` and `project_account_budget` modules
2. Have two companies configured in the system
3. Enable Timesheets from the Settings app
4. Create two projects (one for each company)
5. Ensure the following settings are enabled on both projects:
     * Timesheets
     * Billable

Steps to Reproduce:
------------------------------------------
1. Switched to Company A
2. Create a product with:
    * Type: Service
    * Create on Order: Task
    * No company restriction
3. Set the product's `project_id` to Company A's project
4. Switch to the newly created company (Company B)
5. Set the product's `project_id` to Company B's project
6. Enable Analytic Distribution from SOL Optional
7. Create a sale order with the configured product, and delete the auto-fetched
Analytic Distribution account for the sale order (Company B's project)
8. Now confirm the sale order

Observation:
----------------------------------------
The SOL's analytic distribution uses the analytic account from Company A's project instead of Company B

Issue:
----------------------------------------
The `project_id` field on `product.template` is `company_dependent=True`, meaning it stores different values per company. However, in `_compute_analytic_distribution()`, the code accesses `line.product_id.project_id` without calling `with_company`, so it resolves the field using the wrong company context

Solution:
----------------------------------------
using `with_company()`, the correct company context is applied when accessing
`project_id`, preventing inconsistencies in multi-company environments and
ensuring the appropriate project is used for the corresponding company.


opw-5864452

Forward-Port-Of: odoo/odoo#257776

__ISSUE__:
- FIFO balance miscalculation for non-overlapping allocations. cumulative_allocated_days was partitioned globally by (employee, leave_type), but taken_per_allocation scoped leaves to each allocation's date range. This caused the FIFO formula to silently absorb leaves from one period into another's allocation capacity.

ex:
    Alloc A (20 days) 2025, taken leaves 15 days
    Alloc B (20 days) 2026, taken leaves 5 days

    report: 2025: (15 taken), (5 left)
            2026: (7 taken), (20 left)

- Left" rows shifted by one year in non-UTC timezones. Allocation date_from/date_to (Date fields) were cast to timestamp as midnight UTC. In negative-UTC /positive-UTC timezones midnight UTC of Dec 31 renders as the prev/next day.

__FIX__:
- detect overlap groups using a running MAX(date_to) and partition the cumulative sums within each overlap group. This way non-overlapping allocations are treated as independent, while overlapping or open-ended allocations still share FIFO within their group.

- offset allocation dates by 12 hours so no timezone can shift them across a day boundary.

- opw-5169606
- opw-5352114

Forward-Port-Of: odoo/odoo#257873

[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

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

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

[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

### Issue before this commit:
When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format.

### Steps to reproduce the issue:
1. Download Italian loc + electronic invoicing
2. Activate UoM option in settings
3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3)
4. Invoice this product
5. Create the XML for SdI
6. Check format with Fex > apex is not recognised as a valid character

### Cause of the issue:
The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications.

### Reason to introduce the fix:
Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules.

opw-6075119

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

Forward-Port-Of: odoo/odoo#258851
Forward-Port-Of: odoo/odoo#257012

Currently when creating a subscription for a service product, if the minimal period is a multiple of the time unit: eg two week, three months, etc... The discount amount ends up wrongly computed.

The reason for that is that discounts for services are computed by taking the price of the minimal period and then comparing it to other prices, however that base price is not scaled down to single units of time like the compared prices are. https://github.com/odoo/enterprise/blob/9eac36e4d981fd6062702e7119c664ac7951d613/website_sale_subscription/models/product_template.py#L130-L135 https://github.com/odoo/enterprise/blob/9eac36e4d981fd6062702e7119c664ac7951d613/website_sale_subscription/models/product_template.py#L204-L205

**Steps to reproduce:**

- Create a service subscription product
- In Recurring Prices, select or create a recurring plan that is a multiple of a unit of time, ex 2 Months
- Create two entries, one with the created plan and one with a plan that spans a longer period, ex 1 Year
- Set the prices, ex 100 and 600
- Click 'Go to Website' and you'll observe that both are 50% off

opw-6107509

**Steps to reproduce**
- Create a first partner (name: "Partner", email: "partner@mail.com", phone: "123").
- Go to the website form of a helpdesk team, and submit a ticket using "Partner@mail.com" as email (notice the different capitalization) and "456" as phone number.

Behavior without this fix: a new partner is created, but the ticket is assigned to the orignal partner ("partner@mail.com") and its phone number is updated.

Behavior after this fix: no partner is created.

**Causes**
- the partner search was case sensitive
- the created partner was not used as the `partner_id` of the ticket as it was added to the params but needs to be in the kwargs passed to `handle_website_form` in order to be found used by `extract_data`. The original partner was found in `_find_or_create_partner` by the call to
`_mail_find_partner_from_emails` (case-insensitive)

Note: this commit also ensures consistency between the partner's company and the ticket's company (same as in `_find_or_create_partner` of `helpdesk.ticket`).
Also, avoid allowing modifying existing partner's phone via this form.

opw-5914064

Forward-Port-Of: odoo/enterprise#109393