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

Currently, an error occurs when user creates a reminder.

**Steps to Reproduce:**
 - Install the `calendar` module.
 - Go to `Calendar` > `Configuration` > `Reminders`.
 - Create a `new reminder` and clear the `Type` field.

`KeyError: False`

**Cause**:
 - Error started occurring in 19.0 due to a change in selection field behavior. Since change https://github.com/odoo/odoo/pull/214422/commits/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef, selection fields no longer display an “empty” value.
 - To remove a value from a selection field, the user must clear the field, similar to a many2one field.
 - When the Type field is cleared, its value becomes False, which raise the error here [1].

**Fix:**
 - This commit ensures that when the alarm type is False, display_alarm_type is set to an empty value 
    similar to the display interval [2].
 - Since both fields are required, once they are set again, the correct name is computed accordingly.

[1]: https://github.com/odoo/odoo/blob/2ee2f7678ed262036ee8cf8719ceafd3d69d4062/addons/calendar/models/calendar_alarm.py#L72-L74

[2]: https://github.com/odoo/odoo/blob/97e90f14ea40e4dc8645f845ef78eb579bb3e8dc/addons/calendar/models/calendar_alarm.py#L71

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

Forward-Port-Of: odoo/odoo#243526

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

This commit fixes two unit tests involving the datetime field which are randomly failing since [1].

In the first one, we add a record in an editable list view. The first field is automatically focused (in `onMounted`). Before this commit, the first field was the datetime. When it is focused, the datetime field re-renders itself (from a `<button>` to an `<input>` with datepicker). The test failed when those two renderings were done within the same animationFrame, which was rare but possible. We fix the test by moving `foo` field before `date`, that way, the date field is never focused, and we can properly assert the default date value.

In the second one, again in an editable list, we select a date in the picker, and we then assert that the field is rendered with a `<button>` whose text is correct. The test sometimes failed because there was no button (the field was still displaying an `<input>`). When the value is selected, an update is done in the model, which triggers a re-rendering. At that moment, the picker still states that there's an `activeInput` ("date"), so the field is rendered with an input. The picker state is only updated afterwards, so there's another rendering, where `picker.activeInput` is "", which leads to the expected `<button>` being rendered. However, that rendering can happen in another animationFrame, thus triggering the issue. This commit fixes it by simply waiting for the button to be displayed.

[1] https://github.com/odoo/odoo/pull/218387

runbot error-238437 (1)
runbot error-238758 (2)

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#247026

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

Steps to reproduce:
- Choose France as the company location, and download "France - Work Entries Time Off" module.
- From Employees > Configuration > Settings > French Time Off Localization, select Paid time Off.
- Create a new employee and a new contract (in running state) for that employee that starts on 01/01/2025.
- While in the contract screen, create a new schedule that has 2 weeks calendar and Europe/Paris timezone.
- From Time Off > Management > Allocations, allocate 1+ paid time off days for the newly created employee that's valid from 01/01/2025.
- From the employee's profile > Time Off, try to take a Monday off.

Issue:
- The user gets a Validation error stating that the "start date" is later than the "end date".

Fix:
- In a 2 weeks calendar, there are 2 lines that are there to separate the first week from the second week (for aesthetic purposes). These lines have "hour_from" and "hour_to" = 0, which are taken into account when calulating the minimum hour to start the day off.
- Add a check to remove lines from calendar that are just there for display purposes.

opw-5387347

Forward-Port-Of: odoo/odoo#246565
Forward-Port-Of: odoo/odoo#246094

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

`distribution_analytic_account_ids` is a virtual relational field backed by the `JSON` field `analytic_distribution`. Its custom search method did not handle the `any` / `not any` operators, causing domains like:
```py
('distribution_analytic_account_ids', 'any', <analytic.account domain>)
```
to fail during domain optimization with errors such as:
```py
ValueError: Cannot use 'any' with non-relational fields in condition ('analytic_distribution', 'any', [('plan_id', 'in', [2])])
```

This commit adds support for relational semantics in `_search_distribution_analytic_account_ids` by resolving the RHS domain on `account.analytic.account` into ids and converting:
- `any` → `in`
- `not any` → `not in`

This aligns the behavior with relational field expectations while keeping the logic at the field search level instead of modifying domain internals.

**Steps to reproduce:**
- Created a `v19` db and install Accounting app
- Navigate to `journal items` menu
- Add the custom filter: `[("distribution_analytic_account_ids.plan_id", "in", [2])]`
- In logs you will see:
```py
ValueError: Cannot use 'any' with non-relational fields in condition ('analytic_distribution', 'any', [('plan_id', 'in', [2])])
```
- In UI it will pop up domain is invalid.

opw-5875337
upg-3855669


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

Forward-Port-Of: odoo/odoo#246965

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

### Issue:
In 18.0-18.2, for product with a Manufacturing BoM containing a Component, a WO and a Quality Point If a Reordering Rule is triggered, odoo try to add the newly ordered quantity to an existing MO But if the MO is "locked" because a quality check has been performed, a Error is raised:
```
Odoo Warning
You cannot update the quantity to do of an ongoing manufacturing order for which quality checks have been performed.
```

### Steps to reproduce:
- Create a product tracked by quantity
- Add a BoM (1 component tracked by Quantity, 1 Operation with 1 Quality Point)
- Create a Reordering Rule (Route: Manufacture, Trigger: Manual, Min/Max: 1)
- Click on Order
- Open the created MO and the Shop Floor (Remove the filters to see the WO)
- Complete the Quality Point
- Modify the Reordering Rule (Min/Max: 2)
- Click on Order - the error should be raised

### Cause:
The MO to update is retrieved here:
https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L53-L57 Using a domain defined in this function:
https://github.com/odoo/odoo/blob/45184da06cf7b92a48e3e4e90bf8b285bdd9ad6a/addons/mrp/models/stock_rule.py#L130-L153

In 18.0-18.2, when validating a `quality check` from the Shop Floor while the WO is in `waiting` state, the MO remains in `confirmed` state This makes the domain match the current WO and MO, triggering `change_prod_qty` even though the MO is locked

In 18.3–18.4, a similar issue can occur with multiple WOs when the first blocks the second and a `quality check` is performed on the latter The `blocked` state behaves like `waiting`, but the issue is avoided when using the Shop Floor because this commit ensures that clicking a card starts the timer and changes the state to `progress`: https://github.com/odoo/enterprise/pull/84425/commits/67c2127424ef3a1eb4794edd2c262b94ef186561 However, it could still theoretically be triggered under specific conditions

In 19.0, the new stock.reference system (https://github.com/odoo/odoo/pull/212679) ensures the MO is detected as different, so a new one is always created

opw-5012588

Forward-Port-Of: odoo/enterprise#104158
Forward-Port-Of: odoo/enterprise#101313