Go to the Planning calendar view and toggle filters such that there is no data displayed. Save the current filters as favorite. Then, reload and switch to the list view.

Before this commit, in **debug mode**, the props validation of the ResourceTag component crashed, because it received `false` as value for the `type` props, which expected a `string`.

The problem comes from the SampleServer, which only knows about the fields of the main model, but not those of co-models reachable from relational fields. In this case, there's a `resource_ids` many2many field on the main model whose relation is `resource.resource`, and there's a `type` selection field on that model. That field is required, so the code only expected `string` values, not `false`. But as the SampleModel doesn't know about that `type` field, it generates `false` as value.

Ideally, the SampleModel should know about the whole field specs (main model + relations). However, even though that would be quite easily doable for kanban and list views (unity specs), it wouldn't be the case for the other views (the SampleServer is shared between all views using sample data). So it would require non trivial architectural changes to make this work.

For that reasons, we went for the easy fix, which is to adapt the props definition to support `false`, as the value was actually already correctly handled by the Component itself.

runbot error~239951

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

This commit improves the drag and drop functionality by detecting
the closest elements when dragging. The previous implementation
only calculated distance when the cursor was outside the
rectangle, returning 0 for any position inside. This caused
issues with nested dropdowns: when a small dropdown is inside a
larger one, the quadrance of the larger one would be 0, but since
for the smaller one it is actually harder to place it perfectly inside,
the distance would be non-zero, so the larger one would be preferred.

The new implementation:
- Handles rectangle-to-rectangle overlap detection using center
  distances
- For non overlapping rectangles, returns correct quadrance
- Returns negative normalized overlap ratio for overlapping
  elements, preferring smaller elements with similar overlap
  percentages
- Supports both point queries (x, y) and rectangle queries
  (x, y, width, height)

Steps to see the issue:
- Open Website and start editing
- Drop the `s_banner` snippet
- Try to drop a button (or any other inner element) next to the
existing button in the snippet
=> The experience is not the most user-friendly

Old implementation:

https://github.com/user-attachments/assets/507c0402-b855-46a7-938d-8f05d905dd3e

New implementation:

https://github.com/user-attachments/assets/34b352b4-e08a-4a7f-a2b5-2702ee8e63ef

It might not look like an improvement in the video, but it feels actually easier now when trying to drag and drop to a relatively small dropzone.

task-5794898

## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.

## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**

When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.

## Cause

The condition for the *I Take It* button to be displayed is the following:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283

The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716

When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636

Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.

opw-5451282

Forward-Port-Of: odoo/enterprise#104919

According to the Mexican Social Security Law, when an employee's total monthly earnings (including bonuses and commissions) are equal to or less than the monthly minimum wage (l10n_mx_daily_min_wage * 365 / 12), they are exempt from social security contributions and income tax, also they lost the subsidy benefit.

- The next rules are zeroed out when the gross salary is equal or less  than the minimum wage:
  - IMSS_EMPLOYEE: IMSS Total (Employee)
  - ISR: ISR (Income Tax)
  - SUBSIDY: Used Subsidy
- IMSS_EMPLOYEE and ISR are omitted from the generated XML.
- As the ISR is zero, the `totalDeducciones` attribute on the `nomina12:Nomina` node should be removed.
- The SUBSIDY should be present in the `SubsidioCausado` attribute on the `nomina12:SubsidioAlEmpleo` node, but the `Importe` attribute on the `nomina12:OtroPago` node should be 0.0.

This change requires updates to existing standard tests, as some previous test cases used amounts lower than the minimum wage.

target: 19.0
task-5226971

Forward-Port-Of: odoo/enterprise#107712
Forward-Port-Of: odoo/enterprise#104668

**Issue:**
Loading the shop page was slow due to excessive forced reflows. When a reflow occurs, the browser can't reuse the layout computed so far, and it's forced recalculate it again.

**Cause:**
In `updateVariantPreview`, the init loop wrote to the DOM (textContent, classList) then immediately read `offsetWidth` in the same iteration, forcing the browser to flush and recalculate layout once per product.
This PR tackles the 2 areas of improvement identified:
1. Reduce reflows **number**.
2. Reduce reflows performance **cost**.

[task-5177358](https://www.odoo.com/web#id=5177358&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form)

---

###  1: Reduce reflows **number**.

**Before this PR:**
Phase 1 was a single loop mixing writes and reads, triggering N layout recalculations for N products on the page.

| Performance Tab:  CSS selectors & Advanced paint instr. active (slow) |
|--------|
| <img width="1847" height="650" alt="image" src="https://github.com/user-attachments/assets/91e86e91-1209-4865-bcbd-336f792664ed" /> | 
| Timing inflated by the debug environment | 

**After this PR**
Phase 1 is split into two sub-loops. All writes first (1a) and all reads after (1b). So the browser flushes layout only once, regardless of product count, matching the batching pattern already used in phases 2 and 3.

| Performance Tab:  CSS selectors & Advanced paint instr. active (slow) |
|--------|
| <img width="1380" height="555" alt="image" src="https://github.com/user-attachments/assets/c0fefe32-d309-4fc8-a945-1a5f5c12b86e" /> | 
| Timing inflated by the debug environment | 


**Performance results**
In a page with 21 products, 11 of which with variants, the number of reflows dropped from 12 to just 2, resulting on a 82% faster rendering, roughly a 5.5X speedup.

---

###  2: Reduce reflows performance **cost**.

Reflows cannot be entirely avoided, but side-effects can be mitigated in CSS by instructing the browser how to react when this circumstance occurs. This PR add two rules to the products card:

1. `contain`: Tells the browser each product card is a layout containment boundary and inner changes "should not" affect elements outside.
2. `content-visibility`: Tells the browser to try skipping cards outside the viewport. Their layout will be eventually evaluated when cards scroll into view.

**Performance result:**
In a page with 21 products, 11 of which with variants, the performance cost of a single reflow dropped by 22%.

_note: the browser is not obliged to honor these "suggestion" and may behave differently depending by the viewport size, the content and the browser itself._




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

Forward-Port-Of: odoo/odoo#249324

Users with the project_manager role and no access on sale cannot open stock moves

Steps to reproduce:
1. Install Sales, Inventory and Project
2. Create a Sale order for any company with an address and any product and confirm it (a delivery should be automatically created)
3. Go to Settings > Users and open user Marc Demo
4. Set Marc Demo's role on Sales to "No" and on Project to "Administrator"
5. Log in as Marc Demo
6. Go to Inventory > Operations > Deliveries and try to access the delivery previously created
7. An error occurs

Problem:
https://github.com/odoo/odoo/blob/6b2d3af64a076654e04494972acc4c42d7c54bd8/addons/sale_stock/models/stock.py#L32-L38
stock.move's description is computed based on the related sale order lines which will cause an access error because users with role `project.group_project_manager` can only access sale order lines of projects or tasks because of this rule:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale_project/security/sale_project_security.xml#L4-L13
even though the group `stock.group_stock_user` are expected to always have read access to sale order lines because of this right:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale_stock/security/ir.model.access.csv#L6

Note that the issue doesn't happen when the user is a sale user because of this rule that adds the rights on sale order lines:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale/security/ir_rules.xml#L78-L83

This fix also solves the issue for `mrp.group_mrp_user` because they inherit the group `stock.group_stock_user`:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/security/mrp_security.xml#L11-L16

Therefore the rule on `project.group_project_manager` needs to be
overridden when the user is a stock user

Solution:
Create a record rule with a truthy domain to force stock users to have access to sale order lines even if other rules remove this access

opw-5492232

Forward-Port-Of: odoo/odoo#247529

### Steps to reproduce:
- Download Rental and eCommerce apps.
- Install an RTL language (e.g., Arabic) on the website.
- Create a rental and go to website.
- Try to pick a date for the rental.

### Issue:
When the website is viewed in an RTL language, the navigation arrows of the date picker are displayed in the wrong direction. This happens because the date picker is not inside `o_rtl` component, but inside `o-main-components-container` component. So, when `o_rtl` is called in css (for example):
https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/web/static/lib/odoo_ui_icons/style.css#L67-L76
Since the arrows are not inside `o_rtl`, the transformation doesn't apply to them.

### Solution:
The `o_rtl` class has been appended to `o-main-components-container` class in case of a RTL language, so that had the css file contain rules for `o_rtl`, they would be applied automatically.

opw-5498615

Forward-Port-Of: odoo/odoo#249541
Forward-Port-Of: odoo/odoo#246190

### Steps to reproduce:
- Download MRP app.
- Create a product and its corresponding BOM (including at least a single operation)
- Create and confirm a manufacturing order for 1 unit of that product
- Click on the Shop Floor smart button > Click on the header of the MO
- The MO filter applied on the shopfloor search bar is removed

### Issue:
The MO search filter is removed after you click the header of the workorder order. This bug was introduced by another commit https://github.com/odoo/enterprise/pull/94584/changes/c83ab24a8d037a339db8067c7e9794cba5c16eab to remove the filter when a workorder's barcode is scanned. Hence, https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L289-L292
the change resulted in the filter being removed every time the header is clicked. In the case where a user clicks to start the workorder, we need to keep the filter.

### Fix:
Based on https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L6-L8 `onClickHeader()` is called every time a shopfloor record is clicked, which (based on the reference in the previous section) removes the filter, then calls `startWorking()`. By removing `this.env.searchModel.removeMOFilter()` from this method, it's ensured that clicks preserve the user's current search context.
For https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display.js#L248-L250 since the original workflow of removing the filter in case of a barcode scan should be kept, moving `removeMOFilter()` call here with the appropriate reference of `workorder.component.env.searchModel`matches the expected behaviour.

opw-5877418

Forward-Port-Of: odoo/enterprise#107121

Before this commit, live chat visitors in mobile could not add a message reaction due to visual glitch.

This happens because there's an override in livechat to show 3 quick message actions rather than 4, and this patch also applies in mobile where there's only 1 with the "..." button.

The "Add reaction" message action in mobile, when shown as a quick action, is buggy: click on it glitches the visual of message in a way that disrupt the viewing of message... And this doesn't show the emoji picker.

This commit fixes the issue by removing the override of quick action count of live chat visitors. This overrides was added a long time ago when the "Add reaction" and "View reactions" had the same icon, and playing with the amount of quick actions was a way to avoid showing these 2 actions as quick actions with similar icons [1].

Also quick actions in chat window has been tweaked to show 2 actions at most in desktop, which is the best presentation in chat window. Removal of the override let it use this better quick action count.

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

Task-5953287

Before / After
<img width="399" height="767" alt="Screenshot 2026-02-19 at 17 41 21" src="https://github.com/user-attachments/assets/4f1fb8e7-fa0b-4c8c-8f41-552432224064" /> <img width="401" height="771" alt="Screenshot 2026-02-19 at 17 56 20" src="https://github.com/user-attachments/assets/5aadc9df-d858-49ec-b894-d2c424396f54" />

Forward-Port-Of: odoo/odoo#249776
Forward-Port-Of: odoo/odoo#249550

Before this commit: when formatting partially a link, the link is split
at the selection and formatted. This causes duplicated links.

After this commit: we consider links are unsplittable, thus formatting
on links will wrap the selected part in a <font> tag.


commit 2: 
[FIX] html_editor: solve infinite loop of links with color class
Before this commit: we have a fix https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3
which to be able to remove the style classes in the link element

After this commit: We don't consider the style class in the link element
as `hasColor`, because the style classes come from the template code,
which is hard-coded xml. Removing them, the user won't be able to add it
back. For example, on a product page, edit the `Terms and conditions`
link, do nothing and save, the muted color is forced removed.

Note that another fix https://github.com/odoo/odoo/commit/f5fc55f19f89041c8391ff81b127ffce0898f89f is also
removed cause it was a fix for https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3.
The tests belonging to https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3 are
adapted, and those of https://github.com/odoo/odoo/commit/f5fc55f19f89041c8391ff81b127ffce0898f89f are kept
as future safeguards of list coloring.


commit 3:
[FIX] html_editor: extra check on targetnode when splitting blocks
Before this commit: we only check if the current block to be split is
splittable, but not the target node.

After this commit: if the current block is splittable but the current
target node is not, we won't split the block but insert a <br>


commit 4:
[FIX] html_editor: properly fill inlineAncestors when formatting
Before this commit: when the parent node of the current node is
unsplittable, the `inlineAncestors` stays empty.

After this commit: we handle this case and push the parent node in the
list when the parent node is fully selected. We also add a fully
selected predicate in link_plugin for the case when the selection
includes all the content (except for zws) of a non-button link


task-5244810


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

Forward-Port-Of: odoo/odoo#249470
Forward-Port-Of: odoo/odoo#241871

## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.

## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**

When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.

## Cause

The condition for the *I Take It* button to be displayed is the following:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283

The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716

When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636

Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.

opw-5451282

Forward-Port-Of: odoo/enterprise#104919

Steps to produce:
---
- Install sales module.
- Go to Settings and enable Pricelists (make sure we have 2 pricelists
  so that we able to change the pricelist value in quotation).
- Create a new quotation > Add a customer and product.
- Change the pricelist.
- Save the record.

Issue:
---
- After saving the quotation, the `Update Prices` button becomes invisible.

Root cause:
---
- The field `show_update_pricelist`, which controls the visibility of the button, is not present in the view. As a result, when the record is saved, the field is not included in the form data and its value is not properly maintained, causing the button to become invisible.
- The field is removed from the view in this [commit].

Solution:
---
- Added the `show_update_pricelist` field to the view to ensure its value is properly maintained. This allows the `Update Prices` button to remain visible when applicable.

[commit]: https://github.com/odoo/odoo/commit/da4b588b272432095f549c012e0a0d7238f00dc0

**Enterprice PR:** https://github.com/odoo/enterprise/pull/107621

opw-5927659

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

Forward-Port-Of: odoo/odoo#248957

Users with the project_manager role and no access on sale cannot open stock moves

Steps to reproduce:
1. Install Sales, Inventory and Project
2. Create a Sale order for any company with an address and any product and confirm it (a delivery should be automatically created)
3. Go to Settings > Users and open user Marc Demo
4. Set Marc Demo's role on Sales to "No" and on Project to "Administrator"
5. Log in as Marc Demo
6. Go to Inventory > Operations > Deliveries and try to access the delivery previously created
7. An error occurs

Problem:
https://github.com/odoo/odoo/blob/6b2d3af64a076654e04494972acc4c42d7c54bd8/addons/sale_stock/models/stock.py#L32-L38
stock.move's description is computed based on the related sale order lines which will cause an access error because users with role `project.group_project_manager` can only access sale order lines of projects or tasks because of this rule:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale_project/security/sale_project_security.xml#L4-L13
even though the group `stock.group_stock_user` are expected to always have read access to sale order lines because of this right:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale_stock/security/ir.model.access.csv#L6

Note that the issue doesn't happen when the user is a sale user because of this rule that adds the rights on sale order lines:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale/security/ir_rules.xml#L78-L83

This fix also solves the issue for `mrp.group_mrp_user` because they inherit the group `stock.group_stock_user`:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/security/mrp_security.xml#L11-L16

Therefore the rule on `project.group_project_manager` needs to be
overridden when the user is a stock user

Solution:
Create a record rule with a truthy domain to force stock users to have access to sale order lines even if other rules remove this access

opw-5492232

Forward-Port-Of: odoo/odoo#247529

### Steps to reproduce:
- Download Rental and eCommerce apps.
- Install an RTL language (e.g., Arabic) on the website.
- Create a rental and go to website.
- Try to pick a date for the rental.

### Issue:
When the website is viewed in an RTL language, the navigation arrows of the date picker are displayed in the wrong direction. This happens because the date picker is not inside `o_rtl` component, but inside `o-main-components-container` component. So, when `o_rtl` is called in css (for example):
https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/web/static/lib/odoo_ui_icons/style.css#L67-L76
Since the arrows are not inside `o_rtl`, the transformation doesn't apply to them.

### Solution:
The `o_rtl` class has been appended to `o-main-components-container` class in case of a RTL language, so that had the css file contain rules for `o_rtl`, they would be applied automatically.

opw-5498615

Forward-Port-Of: odoo/odoo#249541
Forward-Port-Of: odoo/odoo#246190

### Steps to reproduce:
- Download MRP app.
- Create a product and its corresponding BOM (including at least a single operation)
- Create and confirm a manufacturing order for 1 unit of that product
- Click on the Shop Floor smart button > Click on the header of the MO
- The MO filter applied on the shopfloor search bar is removed

### Issue:
The MO search filter is removed after you click the header of the workorder order. This bug was introduced by another commit https://github.com/odoo/enterprise/pull/94584/changes/c83ab24a8d037a339db8067c7e9794cba5c16eab to remove the filter when a workorder's barcode is scanned. Hence, https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L289-L292
the change resulted in the filter being removed every time the header is clicked. In the case where a user clicks to start the workorder, we need to keep the filter.

### Fix:
Based on https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L6-L8 `onClickHeader()` is called every time a shopfloor record is clicked, which (based on the reference in the previous section) removes the filter, then calls `startWorking()`. By removing `this.env.searchModel.removeMOFilter()` from this method, it's ensured that clicks preserve the user's current search context.
For https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display.js#L248-L250 since the original workflow of removing the filter in case of a barcode scan should be kept, moving `removeMOFilter()` call here with the appropriate reference of `workorder.component.env.searchModel`matches the expected behaviour.

opw-5877418

Forward-Port-Of: odoo/enterprise#107121

Steps to reproduce
------------------

1. Enable Units of Measure and Automatic Valuation.
2. Create:
  Product KIT, stockable, UoM category Unit, UoM = Units.
  BoM for KIT with at least one component whose UoM is in a different
     category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
   Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.

Issue
-----

Validating the receipt raises:

> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…

If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.

Cause of the issue
------------------

Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108

Fix
---

The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.

https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126

  For kits, `qty_received` must be calculated by aggregating component
  moves to accurately determine this status. Since the standard logic
  crashes due to UoM mismatch, the override in `purchase_mrp` is
  necessary to provide the correct quantity for this date selection.

opw-5030761

Forward-Port-Of: odoo/odoo#248883
Forward-Port-Of: odoo/odoo#236276

## Steps to reproduce:

- Configure event registration with only free-text fields (no selection field).
- Open the POS, add an event ticket product, and fill in the registration form.
- Click Payment and validate the order.

## Issue:

- Registration answers were only sent to the backend when at least one selection-type question was filled.
- When no selection field was present, free-text answers were not synced at all.

## Reason:

- The `registration_answer_ids` and `registration_answer_choice_ids` One2many fields on EventRegistration both point to the same `registration_id` Many2one field on EventRegistrationAnswer.
https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/event/models/event_registration.py#L83-L85

- This caused data loss during the POS model synchronization, as entries were overwritten in the `inverseMap`.
https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/point_of_sale/static/src/app/models/related_models/model_defs.js#L59-L75

## Fix:

- Send all registration answers (free-text and selection-based) exclusively via `registration_answer_choice_ids`.


task-5438565

#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.

#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
  - i.  Select both "Parent Company" and "Child Company A" but not "Child Company B"
  - ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")

#### Current behavior:
i.  Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only

#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"

A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.

opw-5385585

Description of the issue/feature this PR addresses:
. When configuring an accrual plan, users may want no carry-over of accrued days, while still ensuring that accrued balances expire or reset on a specific date (for example, at the allocation start or on a fixed annual date).
. This task aims to make the configuration explicit, intuitive, and self-explanatory, without changing the underlying behavior.

Current behavior before PR:
The UI implicitly ties the ability to set an expiry/reset date to enabling carry-over, which misleads users into believing that this is a functional limitation in v19.0. In reality, the system supports this behavior, but only through a non-intuitive configuration that forces users to enable carry-over and then mark it as lost at a milestone.

Desired behavior after PR is merged:
. Remove can_be_carryover boolean field with accrued_gain_action selection
. Always show the carryover_ date selection field
. Hide carry-over options in case of lost accrued time

task-5468596

An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least today, the SAT allows all characters (pointed out in [2]).

This explains why in the past 6 months this feature has been slowly undone [3][4][5], character by character, after customers run into issues.

The approach can not work, so we go back to the name with the accents the user puts on the partner. Users need to put the correct, legally registered name in Odoo. If it doesn't work then they can adapt it as needed. This way the user is in full control, and we don't block them.

This reverts the whole accent sanitization saga:

- Revert "[FIX] l10n_mx_edi - More accented characters accepted by SAT", this reverts commit 46cc41ddd258e80372478a746ea79d154a5931d9.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit dcbd8797667b5be88f48045e48da86ac42db362c.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 32b8333fd3f813ec3188394c2634129e3fbfe31d.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 05ed1fb9059bd1459e38dc00b041cada6bf06ac4.

This also removes the unused frozendict import to make "Check Style" happy.

opw-5915515

[1] https://github.com/odoo/enterprise/pull/95207
[2] https://github.com/odoo/enterprise/pull/107960
[3] https://github.com/odoo/enterprise/pull/96043
[4] https://github.com/odoo/enterprise/pull/106557
[5] https://github.com/odoo/enterprise/pull/107677

Closes odoo/enterprise#107960

Issue
=====

The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors.

Steps to Reproduce
==================

1. Install `industry_fsm_sale` and `l10n_br`.
2. In the US company:
   - Create a Brazilian customer.
   - Set a fiscal position on the customer.
3. Switch to the Brazilian company:
   - Open the same customer.
   - Set a fiscal position on the customer.
4. Still in the Brazilian company:
   - Create a task for that customer in the Field Service app.
   - Add a product to the task.

Result
======

An error is raised because the fiscal position from the US company is used, which is not valid for the Brazilian company.

Root Cause
==========

When reading the fiscal position from the partner, the value is fetched in the environment of the company in which the partner record was originally created (US company). If no company is explicitly specified, the fiscal position is read in that original environment, even when the user is operating under the Brazilian company.

Solution
========

Explicitly enforce the current company context when reading the fiscal position from the partner to ensure the correct company-specific value is used.

opw-5270522

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

## Issue Before This PR:
The fields `used_weight_percentage` and `used_volume_percentage` in the
list view were showing incorrect values. These fields were incorrectly
aggregating totals across all batches, as the calculation of
`estimated_shipping_weight` and `estimated_shipping_volume`
was not handled per batch, resulting in wrong percentages.

## Steps to Reproduce:
- install inventory module and enable settings for
  batch transfers and dispatch management,
- add two batch records with vehicles assigned
  (having weight or volume capacity), and transfers
  having products with weight or volume defined
- Observe different values of weight % or volume %,
  in form and list view.

## Cause of the Issue:
In the method `_compute_estimated_shipping_capacity`
the computation loop referenced all records together,
causing totals to be shared across batches.

## With This PR:
Each batch now computes its own estimated shipping weight and volume correctly,
ensuring correct per-batch values consistent with the form view and
match what users see when opening individual records.

Backport of [commit](https://github.com/odoo/odoo/pull/227166/changes/a709e84d8357a622198a8ac0a0199af9b16f56e7)

With an `l10n_it` company:
- Create an invoice in a foreign currency and export the XML.

In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to the company currency.
`ImportoTotaleDocumento` must be expressed in EUR, as stated in the following document:
https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+(aggiornate+il+1+luglio+2021).pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b

> L'art. 21, comma 2, lettera l) del d.P.R. n. 633/72 specifica che
> “aliquota, ammontare dell'imposta e dell'imponibile con arrotondamento al centesimo di euro”.
> Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo `<Divisa>`
> deve essere obbligatoriamente “EUR”.

> Article 21, paragraph 2, letter (l) of Presidential Decree No. 633/72 specifies that
> “the tax rate, the amount of the tax, and the taxable amount must be stated with rounding to the euro cent.”
> Consequently, if the invoice is issued by resident or established taxpayers, the code to be entered in the `<Divisa>`
> field must mandatorily be “EUR”.

As a result, we now use the **company currency amount** for the `ImportoTotaleDocumento` field
(assuming the company currency is always EUR for `l10n_it`).

Ticket [link](https://www.odoo.com/odoo/project.task/5913088)
opw-5913088

Forward-Port-Of: odoo/odoo#247537

Steps:

- Activate automatic accounting
- Create a product P:
  • Storable, track inventory
  • Set a cost
  • Product category FIFO, automated valuation
- Activate analytic accounting
- Create a distribution model for that applies to expense account
- Create an invoice for product P, set an analytic (different from the
  one set on the model above)
- Confirm
-> On the cogs expense line, the analytic account is the one from the
   product line, it should be the one set on distribution model

Cause:

The analytic distribution is forced to the same value as the product
line at the creation of cogs lines.

Fix:

Adding a helper to know if we need to force the value of analytic
distribution or leave it to the compute method.
This is especially needed for invoices that are originated by a sale order linked
to a project, since we calculate profitability items regarding the
project's distribution.

Note:

This is an issue that has been addressed several times in differents
way, the reason of this fix is that we think that user should rely on
distribution models: if they want a distribution to be applied on the
cogs line, they should create a distribution model that meet their
needs.

opw-5193666

*: purchase_stock

Issue Before This Commit:
======================
In a `multi-step` configuration, while validating a transfer that has no `procurement group`, its next operation (Input → QC → Stock) is merged into an existing transfer that also lacks a procurement group, even when the transfers are manually created and not generated from a Sales or Purchase Order. This results in unrelated transfers being grouped together.

Steps to Reproduce:
======================
- Install the `stock` module.
- Configure the warehouse to use `three-step reception`.
- Create and validate two receipts for Product A (qty 10) with Vendor A.
- `Observation`: the next transfers for both receipts are merged into a single transfer, even though both receipts were created    manually and not generated from any same source document like PO/SO.

Cause of the Issue:
======================
In the `_search_picking_for_assignation()` method, when no `group_id` is defined on a move, the system still attempts to find an existing picking using the `partner_id`. Additionally, in the `_key_assign_picking()` method, moves without a `group_id` are grouped based on their `partner_id`. As a result, validating multiple manually created receipts sharing the `same vendor` causes them to be incorrectly merged into the `same next transfer`, since they do not share a common procurement group.

After this Commit:
======================
The `_search_picking_for_assignation()` method now skips searching for existing pickings when moves lack a `procurement.group`. The `_key_assign_picking()` method groups moves by their `originating picking` instead of the partner, preventing merges between unrelated transfers without a procurement group. This ensures each manual transfer creates its `own next operation` in multi-step routes.

Task-ID: 5242340

__Problem:__

When simulating accruals across a carry-over date, the system showed a wrong available balance.

1. Create an accrual plan:

    - 1 day granted at the beginning of each month

    - reset at the start of the year (carry-over reset)

2. Enable _Allow Negative_ on Paid Time Off.

3. Create a validated allocation starting at the beginning of the year.

4. Take 11 days of leave at the end of the year, approve and validate it

5. Cross the carry-over (Jan 1), then check balance on __Feb 1__:

    - __Expected:__ available 1

    - __Current:__ available −9

__Root cause:__

- Circular dependency between `leaves_taken` compute and future accrual simulation:
    `_get_future_leaves_on()` → creates `fake_allocation` → triggers
    `leaves_taken` → `_compute_leaves()` →
    `employee._get_consumed_leaves()` → `_get_future_leaves_on()` again.
    → Infinite recursion / wrong value injected.

__Fix:__

- Precompute and inject the correct `leaves_taken` value when building the `fake_allocation` before processing accrual plans through a direct helper `_get_leaves_taken_in_period(target_date)` to compute leaves consumed up to a given date for a single allocation, without recursion.

- opw-4918619