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

The channel invitation has a new feature to generate a new link.

Before this commit, this was placed as an icon button next to the copy clipboard. While this looks like a good placement at first, there is some UX issues: this doesn't feel as natural as before to copy link in clipboard.

This happens because the save to clipboard was the last item, therefore it felt extremely easy to just click on it. With the new button, the generate new link is at the end, and so we are more prone to click on the renew link button than the save to clipboard. Even with the primary button, the placement of save to clipboard requires more precision than we'd expect from such a heavily used button.

This commit fixes the issue by moving the "Generate a new link" below, with the "Access restricted to" text. Justifications are:
- Other positions next to input felt off, whether swap order with save to clipboard or renew button as prefix of input.
- This button is niche, so being below matches more the niche usage of the feature.
- Overall UI of channel invitation feels more balanced.
- Moving to bottom allows to put plain text on button, making it clearer what this button means.

Before / After
<img width="626" height="243" alt="Screenshot 2026-02-23 at 15 42 46" src="https://github.com/user-attachments/assets/01bbf9b6-6fda-4981-8191-a09598e98af8" /> <img width="618" height="251" alt="Screenshot 2026-02-23 at 15 42 25" src="https://github.com/user-attachments/assets/21a797c7-c61e-404f-afe0-fcb4eefe177e" />

When prepating initial value to track value changes, do it as sudo. Indeed user access rights should not prevent from checking tracking.

Use case: hr employee update triggers an update on version records. On version model sign requests are tracked, but their access is limited to sign members. Tracking should not crash at that point.

When finalizing, "new" value of tracking is also computed as sudo. We hence ensure that all values (pre and post) are computed the same way and independently from implemented ACLs.

Reproduce steps: run 'test_employee_deletion'. It was not visible before adding a manual flush, as cr was still in "no tracking" mode (precommit data kept from creation in setupclass).

Task-5935695 ([mail, various] Cleanup and test tracking usage) Prepares Task-3645865 ([mail] In-body tracking)

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

**Issue:**

Non-admin users get an AccessError as follows

```doesn't have 'create' access to: - Default Values, Based on (Purchase Order Suggest) (ir.default: 45)... ```

when using the Purchase Order Suggest wizard.

**Cause:**

The `ir_default_user_rule` record rule restricts non-admin users to only create/modify ir.default records where
  `user_id = user.id`

However,  in  `_save_values_for_vendor` method:

https://github.com/odoo/odoo/blob/6b8a8196c63275eead6709bb20002df0be12a059/addons/purchase_stock/wizard/purchase_order_suggest.py#L199-L204

 `ir.default.set()`  is called without setting the `user_id` parameter, which defaults to an attempt to create a global default: what only admins can do.

**Steps to reproduce:**

- create a non-admin user with purchase user permissions.
- log  in as that user and create a Purchase Order
- add products to the catalog and click "Suggest.
- configure suggest parameters and click "Compute" (Note: compute is only enabled when estimated_price > 0)

An AccessError occurs

opw-5076647

Forward-Port-Of: odoo/odoo#236743
Forward-Port-Of: odoo/odoo#227643

In [1], a refactoring of the POS framework was done, but in the process some overlooked behaviors induced a complete loss of the answers given in the registration process, as long as they do not include an answer to a 'selection' question.

STEPS
=====

0. Create a new event with a few questions (no 'selection' one)
1. Add tickets so that you can buy one in the POS
2. Go in the POS (reload data if needed)
3. Buy a ticket and fill the attendee form (answer to all questions)
4. Continue the POS flow and pay for your ticket.
5. Go back to the back-end and event > attendees
6. Check your new attendee: no answers are linked to the record.

ISSUE
=====

TLDR - Two fields have the same comodel on event.registration. This breaks the use of inverseMap as both are loaded in the pos. As they are treated sequentially when connecting related records, hidden side effects occur when both are not set.

Details:

This effect is due to two main issues. First, after [1], we compute the whole model reference relations using processModelDefs method, that accounts for inverse relations of o2m, m2o fields and provides an inverseMap to be used in several places, notably on creation or deletion of relational records from the POS.

However, pos_event presents a peculiar situation, as registrations have two o2m fields, both loaded in _load_pos_data_fields, that are linked to the model event.registration.answer: registration_answer_ids and registration_answer_choice_ids, a subset of the first, just with a domain to only include answers of 'selection' questions.

Meaning that the inverseMap will only use one of the two, in this case registration_answer_choice_ids. In turn, this means that any update of registration_id on the answer model will update that field, even if the original update was done on registration_answer_ids...

Secondly, one could notice that this should still work, as the inverseMap is used in all places, we should just update the records through the field registration_answer_choice_ids.

So why does it not work and why are all answers removed? Because both fields are loaded in _load_pos_data_fields, and in _sanitazeRawData we use getFields to know which fields to update and to connect (for relations on the model), both being returned.

This means that independantly of the create values for the registration in addProductToOrder in pos_event, the 'framework' will still have two fields to connect and will do so sequentially, one field at the time.

But in the _connect logic, if a field has no value given at creation, then the 'CLEAR' command is used, as this would mean we remove the content of the relational field. But in this case, this means that as both answer fields try to update registration_id through registration_answer_choice_ids, if no value is given at creation in that field, then we clear existing ones, for instance those we just linked through the creation values in the first field registration_answer_ids, as we basically empty registration_id on those records. The answers will also be deleted of the indexedDB because of the condition in databaseTable (no linked registration -> can be removed)

FIX
===

Remove registration_answer_choice_ids from the loaded data, as it is not used anywhere except in the registration creation values. As it is a subset of the other field registration_answer_ids, only keep that one instead. Update the creation values to only use that field.

Note that this seems to highlight a limitation when it comes to having more than one o2m field on a model loaded at the same time in POS.

[1] odoo/odoo@a80a39f2ad16baf474553574c79d55948f86c453

Task-4919080

Forward-Port-Of: odoo/odoo#231293

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

_
## Short functional explanation of the error
When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly.

## Reproduction Steps
1. Go to attendances.
2. Click on configuration and scroll down to the Extra Hours section. Set a Tolerance Time in Favor of Company of 15 minutes.
3. Create 2 attendances for the same employee: one attendance from 8 to 15 for example, and a second one from 16 to 18:12.

### Expected behavior
As the overtime entered is 12 minutes, which is inferior to the company tolerance time of 15 minutes, no extra time should be computed.

### Unexpected behavior
12 minutes of overtime are computed.

## Origin of the issue
Let's say we enter 2 different shifts for the same day. Our work day should be 8 hours, and the sum of both shifts reaches 8 hours or more. We shouldn't have any overtime. However, in the code, the overtime is negative. This is compensated by, in our case, the post-work time: in our case, our overtime duration will be equal to -1, but our post-work time will be equal to 1.2. Both cancel each other, and in the end we obtain 0.2 of overtime, which corresponds to our 10 minutes overtime. However, in this code: https://github.com/odoo/odoo/blob/afcbd98594c9f7007f03a343ea40ea122b955459/addons/hr_attendance/models/hr_attendance.py#L374-L380 it isn't computed that way: because post-work time is 1.2, which is above our company tolerance time of 15 minutes (0.25 in the code), we will always be in the case where we exceed the tolerance time.

Hence, we have to "flatten" the overtime duration and the post-work time before reaching that piece of code.

note: the same bug exists for the employee tolerance time, which
is corrected in this commit.
__
opw-5136861

---

Forward-Port-Of: odoo/odoo#244339
Forward-Port-Of: odoo/odoo#242517

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

**Issue:**

Non-admin users get an AccessError as follows

```doesn't have 'create' access to: - Default Values, Based on (Purchase Order Suggest) (ir.default: 45)... ```

when using the Purchase Order Suggest wizard.

**Cause:**

The `ir_default_user_rule` record rule restricts non-admin users to only create/modify ir.default records where
  `user_id = user.id`

However,  in  `_save_values_for_vendor` method:

https://github.com/odoo/odoo/blob/6b8a8196c63275eead6709bb20002df0be12a059/addons/purchase_stock/wizard/purchase_order_suggest.py#L199-L204

 `ir.default.set()`  is called without setting the `user_id` parameter, which defaults to an attempt to create a global default: what only admins can do.

**Steps to reproduce:**

- create a non-admin user with purchase user permissions.
- log  in as that user and create a Purchase Order
- add products to the catalog and click "Suggest.
- configure suggest parameters and click "Compute" (Note: compute is only enabled when estimated_price > 0)

An AccessError occurs

opw-5076647

Forward-Port-Of: odoo/odoo#236743
Forward-Port-Of: odoo/odoo#227643

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

Steps to reproduce:
1. Install `contacts`
2. Create an individual contact with a phone number
3. Try to edit the phone number on the mobile

Issue:
- Unable to edit in mobile view

Cause:
- On mobile devices, the utility buttons (Call, SMS, WhatsApp) inside the phone widget consume significant horizontal space. Due to the flex layout, this forces the actual phone input field to shrink too much, making it hard/impossible to view or edit the number.

Solution:
- Hide the text labels of the utility buttons to save space, showing only the icons
- make input's width 100% on mobile screens in partner form

<table>
  <thead>
    <tr>
      <th>Before</th>
      <th>After</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="center">
        <img
          src="https://github.com/user-attachments/assets/a620d417-119e-4e28-a62b-f63031e72598"
          alt="Before"
          width="500"
        />
      </td>
      <td align="center">
       <img width="500" height="354" alt="image" src="https://github.com/user-attachments/assets/6adc4c77-767d-491d-a468-8463c0f77666" />
      </td>
    </tr>
  </tbody>
</table>

opw-5489021

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

### Issue:
Having a calendar with a timezone different from utc and looking at the planning gantt view, the hours displayed in the "Total" row are wrong.

### Steps to reproduce:
- Have an employee with a calendar in "Europe/Brussels" and working from 8 to 17
- In planning add a line for this employee
- Display the gantt view on a day
- Create a shift for this employee from 8 to 17
- In the "Total" row, the first hour is not counted

### Cause:
To compute the values displayed in the Total row, we take the intersection of the shift and the working hours from the calendar. ([src](https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L318)) But the working hours from the calendar are given in UTC for this computation (without conversion), this result in a discrepancy between the actual hours of the calendar (with timezone conversion) and the one given to compute the total row.

### Solution:
`resource_work_intervals()` returns the work intervals with the calendar hours and the resource timezone.

In our case, only the hours are interesting (the previous code replaced the timezone by UTC). We need to convert them from the calendar timezone to UTC. So the first thing to do is remove the timezone from `resource_work_interval` then we localize it in the calendar timezone and to finish we convert it to UTC.

opw-5564749

In the `industry_fsm_report` and `quality_control_worksheet` modules, worksheet fields created during onboarding was moved from XML to Python (https://github.com/odoo/enterprise/commit/d619aa4d0d042be3f899b777081b7fb90f851c84). They were noupdate=1 before moving to Python ([quality_control_worksheet](https://github.com/odoo/enterprise/blob/d619aa4d0d042be3f899b777081b7fb90f851c84/quality_control_worksheet/data/quality_worksheet_demo.xml#L3), [industry_fsm_report](https://github.com/odoo/enterprise/blob/d619aa4d0d042be3f899b777081b7fb90f851c84/industry_fsm_report/data/fsm_report_demo.xml#L3)).

The issue is without this patch, the dbs which loaded those fields in version `19.0` will have referencing xmlid because of this PR #84602, with noupdate=0. On the other side as they do not have record in xml files, during the upgrade to > 19.0 it will introduce an issue like this:

```
odoo.upgrade.util.exceptions.UpgradeError: 💥 It looks like you forgot to call `util.remove_field` on the following fields: x_project_task_worksheet_template_2.x_worker_signature
2026-02-15 20:17:38,149 23 INFO db_3904048 odoo.service.server: Initiating shutdown
```

tbg-2468

Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one.

**Steps to produce:**
* Install Sales, Project
* Products > Virtual Home Staging > Create On Order > Project and Task
* Create and confirm quotation with that product.
* Tasks > Empty Sale Order Item Field

**Observed Behavior:**
* Sale Order is still linked to the task despite sale order line has been unlinked from that task.

**Root cause:**
* Compute method [1] only detaches the sale order if the customer has been changed.

**Solution:**
* Only detach the sale order when there are no sale order items and the record is not a field service task.
* Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed.

[1]:
https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 
[2]
https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194

Related community PR: https://github.com/odoo/odoo/pull/241446

opw-5215989

Forward-Port-Of: odoo/enterprise#107716
Forward-Port-Of: odoo/enterprise#103487

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

The CFDI 4.0 field CondicionesDePago is derived from the payment term name, but its rendered value depends on the language context active at XML generation time. Even when the user language is Spanish, this field may still be rendered in English (e.g. "Immediate Payment") due to context loss during the CFDI rendering process or during XML regeneration.

This behavior becomes especially problematic in scenarios with PAC intermittency. A stamping request may be successfully processed by the SAT but time out in Odoo, and a subsequent retry can regenerate the CFDI using a different language context. As a result, two CFDIs with identical fiscal data but different textual content (English vs Spanish) can be generated, potentially leading to duplicated CFDIs registered in the SAT.

To ensure deterministic and compliant XML generation, the payment term name is now explicitly evaluated under the es_MX context when rendering the CFDI. This guarantees stable Spanish content for Mexican CFDI textual fields, regardless of user language or transient context changes during the EDI flow.

This follows the same rationale as odoo/enterprise@f75a04fa954d, where a lost language context during XML rendering caused inconsistencies between the XML and the expected Mexican CFDI content.

Forward-Port-Of: odoo/enterprise#105588

When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others

Steps to reproduce:
-------------------
1. Create a Product A tracked by lot, create lot 111 and add 1 unit to location A and another one to location B
1. Create a sales order
2. Add two units of the product to the sale order
3. Confirm the sales order
4. Open the transfer, make the transfer retrieve the product from several location with the same lot.
5. Save the transfer
6. Open the sales order in POS
7. Load the SN/lots
-> Two line of qty 1 appear for the product A but only the first one has the lot number

Additional Issue:
8. Change the number of the product for the first line to 2 and erase the second line
9. Confirm and Pay
10. Close POS
11. Open move lines for this product (Inventory>product>In/out)
-> It moves 2 product from one location (when there is only product)

Observation:
-------------
When loading the SO in POS, we will retrieve the SO: https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L104 While retrieving the SO, we will also retrieve the SOL, with additional information: https://github.com/odoo/odoo/blob/d9b2e5ee730a4e79586bfd3f09adfb794d2dc1f3/addons/pos_sale/models/sale_order.py#L79 -> Issue is that when several moves_line have the sale lot_id.name, their quantity will be overwritten.

Addition Issue :
When closing pos, all the move will be processed, when processing those moves, the origin only check if the quantity is more than 0 and not if there is enought units. https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/point_of_sale/models/stock_picking.py#L293-L297

opw-5347992