Currently when the user validates a sale order delivery which has a kit the cost
gets reset to 0.

<h2>Steps to produce:</h2>

* Install sale_margin, sale_management, mrp
* Create a product with an AVCO or FIFO product category
* Create a BOM of type ‘Kit’ for that product.
* Add components A and B to the BOM, each with an on-hand quantity and a cost of
  10.
* On the kit product compute the cost according to the BOM
* Create and confirm SO for 1 unit of the kit product
* Delivery > Validate the Delivery  and go back to the Sale Order

Replication video: [Link](https://drive.google.com/file/d/1PgAh1xwBZX7RsRQ5ZsQipqYjuxvex2CA/view?usp=sharing)
<h2>Observed Behavior:</h2>

The product cost on the sale order is set to 0, but it should be 20.

<h2>Root cause:</h2>

After commit [1], an override for `_get_price_unit` was added to correctly calculate kit prices for BOM products. 

The goal was to prevent the cost from being set to 0 after a delivery is validated. However, when this logic is triggered during 
delivery validation, it doesn’t behave as intended.

After the delivery is validated, compute [2] runs and calls function [3]. However, `self` at [3] refers to a stock move record, so we get the components of the kit instead of the kit product itself.

The function `_bom_find` expects the main kit product, not the components. Because of this, the kit’s unit price isn’t calculated, and the parent function [4] ends up setting the purchase price to 0.

<h2>Solution:</h2>

Use the kit product IDs from the sale order lines instead of the move lines, ensuring the main kit product (not its components) is used and the BOM is found properly.

Return unit price for kit products instead of total value for the function `_get_kit_price_unit`

Update the test case to account for delivered quantities:

  **Before:**
  The sales order used Units as the unit of measure while the product and stock moves use a pack of 10. Since only 3 units get delivered and one product equals 10 units, this was not counted as a full delivery. Therefore, the delivered quantity was treated as 0, which allowed the product cost to be set at [5] and pass the test case
 
 **After:**
 The test now covers the case where a full quantity is delivered by using a pack of 10 as the unit of measure on the sales order. This ensures the product cost is handled correctly when the delivered quantity is 1 or more.

[1]:
https://github.com/odoo/odoo/commit/5a44ae1ec71573c57a5d60903f9b81e842fc582b
[2]-
https://github.com/odoo/odoo/blob/d4b6897211c65ba6d6ba8132480627e6fa66c481/addons/sale_stock_margin/models/sale_order_line.py#L11-L34
[3]-
https://github.com/odoo/odoo/blob/d4b6897211c65ba6d6ba8132480627e6fa66c481/addons/sale_mrp/models/stock_move.py#L9-L16
[4]-
https://github.com/odoo/odoo/blob/d4b6897211c65ba6d6ba8132480627e6fa66c481/addons/stock_account/models/stock_move.py#L230-L233
[5]-
https://github.com/odoo/odoo/blob/d4b6897211c65ba6d6ba8132480627e6fa66c481/addons/sale_stock_margin/models/sale_order_line.py#L21-L22

opw-5479266

Forward-Port-Of: odoo/odoo#246030

Step to reproduce:
- install `l10n_es_edi_verifactu_pos` and open POS
- finalize 2 order with same customer (do not invoive it)
- close session
- go to pos orders, select both order and try to create consolidated invoice

Traceback:
```
File "/home/odoo/addons/l10n_es_edi_verifactu_pos/models/pos_order.py", line 293, in _prepare_invoice_vals
    res['l10n_es_edi_verifactu_refund_reason'] = self.l10n_es_edi_verifactu_refund_reason
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/orm/fields.py", line 1365, in __get__
    record.ensure_one()
```

Cause:
- `_prepare_invoice_vals` is written to accept only one order at time but it can contain multiple orders

Fix:
- we now do not allow invoice consolidation for Veri*Factu
- the consolidation flag has been made invisible so every order now has
to be invoiced individually.

opw-5379577

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

Forward-Port-Of: odoo/odoo#239391

### Context:

A confirmation dialog must be small and minimal for several reasons:

- Users are being interrupted mid-task. A wall of text forces them to context-switch and parse information when they just need to make a quick decision
- The goal is a binary choice (confirm/discard). Too much content complicates what should be a simple yes/no moment
- ...

In the backend, our dialogs `SM` size is set to a **forgiving** `460px`. This value allows dialogs to be relatively small, while still providing enough tolerance to showcase more content if necessary.

In the frontend, instead, the default value in use is BS default, thus `300px`. A website default font-size is also much bigger, `16px` against `13px` in the backend.

As a result, the dialog may be too small when used in scenarios that are not "confirmation dialogs" strictly speaking.

### The issue:

In some cases, enforcing SM size to any confirmation dialog gives bad results in the frontend.

| backend | fronted |
|--------|--------|
| <img width="644" height="370" alt="image" src="https://github.com/user-attachments/assets/ab40312a-06df-4203-8b3d-3b2074341986" /> | <img width="667" height="416" alt="image" src="https://github.com/user-attachments/assets/c0770de4-e3c0-4a15-b2a5-6a498c94fb20" /> | 

Enforcing a higher `SM` value for the frontend (eg. `500px`) is not a solution because the default BS value is technically correct and users can customize it anyway by overriding this setting.

### The solution:

Allow the ConfirmationDialog component to use sizes different from `SM`. This commit sets some portal dialogs to MD size.

| saas-19.1 | this pr |
|--------|--------|
| <img width="667" height="416" alt="image" src="https://github.com/user-attachments/assets/c0770de4-e3c0-4a15-b2a5-6a498c94fb20" /> | <img width="953" height="605" alt="image" src="https://github.com/user-attachments/assets/07eab456-97c3-4e9d-8ce2-dd79ac5b82d4" /> | 

task-5906425

note: Several design improvements are necessary and will be handled in forward-port targeting master 



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

The color filter applied to a video background would disappear after selecting the block and saving the page again.

Steps to reproduce:
===================
1. Enter Edit mode on the website.
2. Drag and drop a snippet (e.g., "Intro").
3. Set a video background for the block and apply a color filter.
4. Save the page.
5. Enter Edit mode again, click the block to select it, and Save.

-> The color filter is removed from the video background.

Cause:
======
Selecting the block triggers the `toggleBgImageClasses()` function. This function attempts to determine the background configuration. Since a video background is used, there is no standard image URL, so the code proceeds to call `setImageBackground` with an empty URL ([1]). This update process involves re-applying the color filter via the `selectFilterColor` action. However, the current background image style (the filter color) was not being passed to this function during this specific update flow. Consequently, the function assumed no filter existed and removed it ([2]).

Solution:
=========
Retrieve the current `filterColor` (which exists in background-image style) and pass it explicitly when calling the apply function.

[1]: https://github.com/odoo/odoo/blob/fa482e36bc36809e55b6a11ebcc5bb130f20fd31/addons/html_builder/static/src/plugins/background_option/background_image_option.js#L18-L20
[2]: https://github.com/odoo/odoo/blob/fa482e36bc36809e55b6a11ebcc5bb130f20fd31/addons/html_builder/static/src/plugins/background_option/background_image_option_plugin.js#L170

opw-5448696

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

Forward-Port-Of: odoo/odoo#242236

Bring back all tests temporarily disabled by [1]. Below are the
explanations about the needed changes in the code.

---
Change in `/project_mrp_account:MrpProduction.write`
Tested by `/project_mrp_account.test_changing_mo_analytic_account`

In the test, when changing the project of the MO:
https://github.com/odoo/odoo/blob/08b62a4bbcc6f9a391b2cc00a621ef4c76100229/addons/project_mrp_account/tests/test_analytic_account.py#L211-L212
We reach the override in `project_mrp_account`. On Odoo 18.0, a line
calls the method `_account_analytic_entry_move`:
https://github.com/odoo/odoo/blob/706431510110a005618a2acaf6566f2bb61d5114/addons/project_mrp_account/models/mrp_production.py#L31
This line is in charge of creating AA/AAL related to the SM. However,
the commit [1] has removed `account_analytic_entry_move` and all its
calls. This is why the test fails in the first assert:
https://github.com/odoo/odoo/blob/08b62a4bbcc6f9a391b2cc00a621ef4c76100229/addons/project_mrp_account/tests/test_analytic_account.py#L210
It doesn't find anything. However, the commit [2] brings the method
back with a brand-new name: `_create_analytic_move`. We therefore
need to connect it again where it is needed.

---
Change in `/stock_account:StockMoveLine.write`
Tested by `/project_mrp_account.test_update_components_qty_to_0`

Quite the same as above. Commit [1] removes this while it's actually
needed. One difference, a `sudo` call, because a stock user doesn't
have any access to analytic world.

---
Change in `/stock_account:StockMoveLine.unlink`
Tested by `/project_mrp_account.test_mo_qty_analytics`

Same as above, also with a new `sudo`.

---

[1] https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229
[2] 35db55618fa70146afc89e662410aca95947e17b

Forward-Port-Of: odoo/odoo#245864

When a product is part of a group with Reserve Only Full Packagings
enabled, another check occurs in _check_qty. This rounds with a precision
of 1.0 the down rounding method. In the case that the quantity was a
decimal, such as 22.4, this would be rounded to 22. In the next transfer
the quantity would then only be 22 instead of the expected 22.4. This
would also cause any packages to not be added as the quantity and demand
are not equal.

If the uom of the product and package are the same we dont need this
package check. Which also prevents the rounding issue.

This fix insures the _check_qty method does not round in cases it does
not need to. (self == uom_id)

How to reproduce:

    In Settings:
        Enable Units of Measure & Packagings
        Enable Multi-Step Routes
    In Warehouses
        Set Outgoing Shipments to Pick then Deliver (2 steps)
    In Inventory
        Create a new product
        Give the product a category
        Set category Reserve Packagings to Reserve Only Full Packagings
        Set on-hand amount

    Workflow:
    Create a sales order
        Create a new Company
        Add product with decimal quantity (1.3)
        Confirm SO
    Go to the sale order delivery
        Validate
    Go to the next transfer
        Quantity will now be rounded (1.0)

opw-5486932

Forward-Port-Of: odoo/odoo#246208