**Steps to reproduce:**
1. Install Accounting
2. Import a new invoice with more than 1000 lines (xlsx file found in ticket attachments)
3. Test the imported records

**Issue:**
- `RecursionError: maximum recursion depth exceeded`.

**Cause:**
- In a previous commit (3e32d7b9eace62dfa7334009707a93967906c726) aimed at fixing stale analytic distribution totals, the assignment loop in `_compute_discount_allocation_needed` was changed from iterating over `self` to `self.move_id.line_ids`.
- While this ensured all lines generated updated distribution ratios, it violated the compute logic: assigning values to records outside the current compute batch (`self`).
- By executing `line.discount_allocation_dirty = True` on external sibling lines, the method forced the ORM to trigger out-of-band `write()` calls. These writes re-triggered dependency checks (`_field_will_change`), which invoked the compute method again, leading to a recursive loop.

**Fix:**
1. Revert the assignment iteration back to `for line in self:`.
2. To preserve the intention of the previous commit (ensuring all lines recompute their shared distribution pool when one line changes), modify the method's `@api.depends` to be `move_id.line_ids.discount` and `move_id.line_ids.analytic_distribution`.

By declaring these relational dependencies, modifying a single line now batches all sibling lines into `self` from the start. This allows the lines to synchronize properly without triggering new ORM writes, eliminating the recursion.

opw-6451854

Forward-Port-Of: odoo/odoo#282050

### Steps to reproduce:

- Enable "Lots & Serial Numbers" in the Inventory settings
- Create a storable product tracked by lots
- Create a lot for that product and leave it without any quantity
- Open the lot form > cog menu > Scrap
#### > ValueError: Expected singleton: stock.location()

### Cause of the issue:

A lot is only given a `location_id` when all its positive quants lay in a single location, so a lot with no quant at all has none: https://github.com/odoo/odoo/blob/8b8852f1c3ae5b78a4a3e99c99eacab83f0be5c9/addons/stock/models/stock_lot.py#L169-L172 The `action_scrap` nevertheless always forwards that value to the scrap move, so the form is opened with `default_location_id` set to `False`: https://github.com/odoo/odoo/blob/8b8852f1c3ae5b78a4a3e99c99eacab83f0be5c9/addons/stock/models/stock_lot.py#L415-L426

Now, the issue is that the `_onchange_lot_ids` of the new stock move then evaluates the reservation of a move whose source location is still empty which raises the traceback because of a `self.ensure_one` required on the location to determine if the move `should_bypass_reservation`: https://github.com/odoo/odoo/blob/8b8852f1c3ae5b78a4a3e99c99eacab83f0be5c9/addons/stock/models/stock_move.py#L1515 https://github.com/odoo/odoo/blob/8b8852f1c3ae5b78a4a3e99c99eacab83f0be5c9/addons/stock/models/stock_move.py#L1989-L1992 https://github.com/odoo/odoo/blob/8b8852f1c3ae5b78a4a3e99c99eacab83f0be5c9/addons/stock/models/stock_location.py#L414-L416

Note that if the default key was not present, the traceback would not be triggered and the scrap would be performed from the `default_stock_location` of the company:
https://github.com/odoo/odoo/blob/4c4219a7d9d51f703b15e83ab755faf1f2c8a71d/addons/stock/models/res_company.py#L21-L22

Indeed the issue is that the `default_get` looks the context key up by *membership*, so that a falsy `default_location_id` is still returned as a default value for the field if provided:
https://github.com/odoo/odoo/blob/8b8852f1c3ae5b78a4a3e99c99eacab83f0be5c9/odoo/orm/models.py#L1313-L1317 And therefore will not be computed in the first onchange: https://github.com/odoo/odoo/blob/8b8852f1c3ae5b78a4a3e99c99eacab83f0be5c9/addons/web/models/models.py#L1974-L1988

Note:

The `stock.lot.action_scrap`, and this `default_location_id` line with it, were introduced by 1c7d80a10b5d, which replaced the `stock.scrap` model by scrap `stock.move` records. That commit is only present from saas-19.2 onwards, so earlier versions are not affected.

opw-6441937

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

Forward-Port-Of: odoo/odoo#280666

Steps:
- Install sale_management
- Make sure you have 100 quotations with 1 activity each
- Open activity view
- Default pager displays `1-100/100`
- Activity count display `To-do 80`

ActivityController uses `useModel` which passes the raw `component.props` to
`model.load()`, including the limit from `ir.actions.act_window` (default 80).
This value ended up in `fetchActivityData` via `params.limit || this.initialLimit`,
overriding `ActivityModel.DEFAULT_LIMIT` (100).

The records list was not affected because `RelationalModel._getNextConfig` never
reads `params.limit` (limit is not a `SEARCH_KEY`), so it always loaded 100
records correctly. But `fetchActivityData` used 80, causing a mismatch between
the records shown and the activity counts in the column headers.

```js
export const SEARCH_KEYS = ["comparison", "context", "domain", "groupBy", "orderBy"];
```

The fix strips `params.limit` in `ActivityModel.load()` before passing params to
`fetchActivityData`, so it falls back to `this.initialLimit (100)`. The pager
`onUpdate` handler calls `fetchActivityData` directly with its own `params.limit`
and is not affected.

However, `ActivityController` never forwards `limit` to the model. This
is why we always have `ActivityModel.DEFAULT_LIMIT (100)` without taking
into account actions's limit. To fix this we have to add the limit via
`this.props.limit`, as `ListController`.

`useModelWithSampleData` already had the correct behavior by calling
`model.load(getSearchParams(props))` which filters out non-search params like
limit. In 19.0 useModel was updated to do the same, so the issue does not
exist there.
Link to 19.0 fix: https://github.com/odoo/odoo/pull/211697

opw-6281125

Forward-Port-Of: odoo/odoo#281227
Forward-Port-Of: odoo/odoo#273929

## Issue
When filtering projects using the "Timesheets >100%" filter, some projects with negative remaining hours (and with their `is_project_overtime` field set to True) won't be displayed, even though their expected hours are completed.

This happens with projects which have tasks set to the "Done" or "Cancelled" state. The timesheets entries in those tasks are not taken into account when searching using the "Timesheets >100%" filter.

## Steps to reproduce
1. Install *Task Logs* (`hr_timesheet`)
2. Create a Project P (with Timehseets enabled)
3. Set the allocated hours of the project to 3:00 (3 hours)
4. Create two tasks:
    - T1: State "In progress", and one timesheet entry of 2:00 (2 hours)
    - T2: State "Done", and one timesheet entry of 2:00 (2 hours)
5. Back to the project view, set the filter to "Timesheets >100%"
6. **Project P is not shown, even though the total time spent on the project is 4 hours, completing the allocated hours set on the project.**

## Cause
The `_search_is_project_overtime` method filters out the tasks in "closed" states (Done/Cancelled) when computing the amount of time spent on the project.

https://github.com/odoo/odoo/blob/126b5bdd1e85771549198976f8570cd2ff167608/addons/hr_timesheet/models/project_project.py#L103-L114

This does not match with the behavior of the `_compute_is_project_overtime`, which does not take into account the state of the tasks to determine the value of the field:

https://github.com/odoo/odoo/blob/126b5bdd1e85771549198976f8570cd2ff167608/addons/hr_timesheet/models/project_project.py#L85-L94

This leads to a confusing behavior, where a project can have its `is_project_overtime` field set to True, but will still not be shown when using the "Timsheets >100%", even though that filter is defined as `[("is_project_overtime", "=", True)]`.

The compute method was updated by https://github.com/odoo/odoo/commit/d4252825f52a3172420dcda0ea394e42da9f8853, but the related search method was left unchanged, leading to this slight incoherence between the two methods.

opw-6422173

Forward-Port-Of: odoo/odoo#282338
Forward-Port-Of: odoo/odoo#281997

Steps to reproduce
---
1. Create and confirm a sale order.
2. Create a down payment invoice on it and post it: the down payment line reads "Down Payment (ref: INV/... on ...)".
3. Open that invoice and use Reverse and Create Invoice, then post the newly created draft down payment invoice.
4. Open the sale order: the down payment line has lost its reference and now reads only "Down Payment", and that empty label also carries over to the down payment section when generating the final invoice.

Issue
---
The down payment line description is built by `_get_downpayment_description`, which only produces the "Down Payment (ref: ... on ...)" label when exactly one customer invoice is linked to the down payment `sale.order.line`, guarded by `len(invoice) == 1`.

https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/sale/models/sale_order_line.py#L484-L509

Reverse and Create Invoice runs `account.move.reversal.modify_moves`, which copies the reversed invoice with `include_business_fields=True`, so the copied line keeps its `sale_line_ids` and the new draft invoice is attached to the very same down payment line as the reversed original.

https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/account/wizard/account_move_reversal.py#L142-L149

That down payment line then references two `out_invoice` moves (the reversed one and the re-issued one), so `len(invoice) == 1` is false and the label silently falls back to the bare "Down Payment", losing the reference that the final invoice's down payment section reuses. Going back to the sale order to raise a fresh down payment instead creates a new line, which keeps a single invoice and is why the slower flow is unaffected. The `len(invoice) == 1` guard was introduced in ba954604e529. Discarding the reversed invoice (`payment_state == 'reversed'`) leaves the active re-issued invoice as the single match, so its reference is shown again; when the only linked invoice is itself reversed, the fallback keeps displaying it so existing descriptions are preserved.

opw-6353384

Forward-Port-Of: odoo/odoo#282481
Forward-Port-Of: odoo/odoo#277802

Steps to produce:
---
- Install the Sales and Inventory modules.
- Enable Allow Spontaneous Returns in Settings.
- Create a product and a sales order for it, then confirm the order.
- Open the delivery from the smart button and validate it.
- Preview the sales order, click return, increase the quantity, select a
  return reason, and download the return label.
- Open the sales order chatter.

Issue:
---
The chatter message posted after downloading the return label displays HTML tags as plain text instead of rendering line breaks.

Cause:
---
In [commit], `_build_return_log_message()`[1] builds the message as a plain str, concatenating literal HTML tags (`<br/>`) with dynamic content (product names, picking names, and the return reason).

The [caller] then posts the message using `Markup("%s") % return_message`. Since return_message is a plain str
rather than a Markup object, MarkupSafe treats it as untrusted input and escapes the entire string during interpolation, causing the HTML tags to be displayed literally.

Solution:
---
Build the message as a Markup object directly in `_build_return_log_message()`, using `Markup("<literal template>") % value` for each fragment. This ensures that the HTML structure is trusted while all dynamic values (product names,
picking names, and the return reason) are safely escaped by MarkupSafe during interpolation.

The method now returns a Markup object, allowing the caller to post it directly without wrapping it again in `Markup("%s") % return_message`, which would otherwise escape the already-safe HTML.

[commit]: https://github.com/odoo/odoo/commit/5f490ffc36a1156b927f2cf4f9b0aa00a83394d5
[1]https://github.com/odoo/odoo/blob/6521b207713c641172b13ac929aeeb1c20f09de8/addons/sale_stock/controllers/return_order.py#L130-L154
[caller]https://github.com/odoo/odoo/blob/6521b207713c641172b13ac929aeeb1c20f09de8/addons/sale_stock/controllers/return_order.py#L119-L120

Before:
---
<img width="645" height="101" alt="image" src="https://github.com/user-attachments/assets/54782171-ee64-4601-bfd9-e62621ab705f" />

After:
---
<img width="576" height="161" alt="image" src="https://github.com/user-attachments/assets/6b1ae04f-b35b-4aae-aa6d-88b7337a0100" />

opw-6367175

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

Doing an euclidean division on floats with the native operators is unreliable: because of IEEE-754 representation errors, `value1 % value2` can return a spurious remainder (e.g. `50.4 % 16.8 == 16.799999999999997` instead of 0.0) and `int(value1 / value2)` can truncate the quotient one step too low (e.g. `int(0.3 / 0.1) == 2` instead of 3). `float_div` returns the `(quotient, remainder)` pair free of those errors.

The key is to never run a lossy `%` or `//` on the raw floats. Instead both operands are first snapped onto the precision grid with `float_round` and then scaled to integers: since a grid-snapped value is a multiple of `rounding`, dividing it by `rounding` counts how many grid steps it spans. That division is still noisy (`4.35 / 0.05 == 86.99999999999999`), so the result is passed through `builtins.round` to coerce it to the exact integer step count. The euclidean division itself is then a plain integer `divmod`, which is exact, and the remainder is scaled back to real units. This is why the correction is applied to the inputs and not to the output: rounding the result of a native `%` would only round an already-corrupt value, and would still misreport the quotient in the corner cases the util exists to handle.

Dividing by `rounding` is meaningful for any precision, not only powers of ten: the grid step can be `0.05`, `0.25`, `0.5`, `0.03`, ... and `value / step` counts the steps in every case. This mirrors the normalize/denormalize scheme `float_round` already uses internally.

The util shares `float_round`'s inherent limitation: the scaled step count must stay representable as an exact `float` integer, so exactness is lost past ~2**53 grid steps (extreme magnitudes at a fine precision). This is the IEEE-754 double-precision ceiling and is well outside any realistic quantity or price range.

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

Forward-Port-Of: odoo/odoo#280883
Forward-Port-Of: odoo/odoo#277160

Steps:
- Install sale_management
- Make sure you have 100 quotations with 1 activity each
- Open activity view
- Default pager displays `1-100/100`
- Activity count display `To-do 80`

ActivityController uses `useModel` which passes the raw `component.props` to
`model.load()`, including the limit from `ir.actions.act_window` (default 80).
This value ended up in `fetchActivityData` via `params.limit || this.initialLimit`,
overriding `ActivityModel.DEFAULT_LIMIT` (100).

The records list was not affected because `RelationalModel._getNextConfig` never
reads `params.limit` (limit is not a `SEARCH_KEY`), so it always loaded 100
records correctly. But `fetchActivityData` used 80, causing a mismatch between
the records shown and the activity counts in the column headers.

```js
export const SEARCH_KEYS = ["comparison", "context", "domain", "groupBy", "orderBy"];
```

The fix strips `params.limit` in `ActivityModel.load()` before passing params to
`fetchActivityData`, so it falls back to `this.initialLimit (100)`. The pager
`onUpdate` handler calls `fetchActivityData` directly with its own `params.limit`
and is not affected.

However, `ActivityController` never forwards `limit` to the model. This
is why we always have `ActivityModel.DEFAULT_LIMIT (100)` without taking
into account actions's limit. To fix this we have to add the limit via
`this.props.limit`, as `ListController`.

`useModelWithSampleData` already had the correct behavior by calling
`model.load(getSearchParams(props))` which filters out non-search params like
limit. In 19.0 useModel was updated to do the same, so the issue does not
exist there.
Link to 19.0 fix: https://github.com/odoo/odoo/pull/211697

opw-6281125

Forward-Port-Of: odoo/odoo#281227
Forward-Port-Of: odoo/odoo#273929

When searching on the Website site, using the main search on the navbar, it opens a list view with the results (`website.list_hybrid`) which raises the warning on the logs (2 times):
"Unknown directives or unused attributes: {'t-key'} in website.list_hybrid"

![Task 79454 - Issue 434 - Image of Warnings](https://github.com/user-attachments/assets/f5a3100b-c617-4c38-a8b5-f42427a4317c)

This happens after the attribute `t-key` was added to the template [\[1\]] because the template is only used in QWeb. The validation for them doesn't include the `t-key` [\[2\]] as one of the "iter_directives" nor has a `_compile_directive_*` method to check and remove it from the validation as it's done with the `t-as` and `t-foreach`.

This also causes the raise of the warnings on tours that use the tour method `searchProduct` (of the module `website_sale`) because it uses the first input with the name of search and happens to be the search on the navbar.

![Task 79454 - Issue 434 - Search Input](https://github.com/user-attachments/assets/923f5d63-5cfb-4c0b-a563-0eabc04882bb)

[\[1\]]: https://github.com/odoo/odoo/commit/7b1d82aa
[\[2\]]: https://github.com/odoo/odoo/blob/f52cfb09/odoo/addons/base/models/ir_qweb.py#L1400

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

Forward-Port-Of: odoo/odoo#179017

Currently, with images enabled for quotation reports and if the product name is long enough, it overflows through the column border a bit before breaking to the next line.

This seems to be caused by some incompatibility between wkhtmltopdf and d-flex, adding `col` to the product name container forces it to respect column boundaries.

This commit also adds `text-break` as having a long uninterupded string in the description would end up stretching the column and making the next ones disapear.

<img width="811" height="266" alt="image" src="https://github.com/user-attachments/assets/90043c88-d03f-4324-9935-e669f6a256ab" />

<img width="964" height="431" alt="image" src="https://github.com/user-attachments/assets/2b8e8a6c-6fd5-4813-8160-d94bbb5490d1" />


### Steps to reproduce:
- Enable Display Product Images in the setting
- Create a product with an image
- Create a quotation with said product and add a description that is long enough to break to the next line
- Print said quotation
- You will notice that before the line breaks it will overflow to the next column 
(you might need to tweak the description a bit by removing or adding a few lines)


opw-6367076

Steps to reproduce:
1. Install `l10n_pe`
2. Create and set the current company to the Peru company
3. In mobile  view, try to create a contact
4. Fill in the identification number type to RUC

Issue:
- The field of VAT is collapsed and not visible

Cause:
- The VAT div `vat_div` is displayed as a flex row (`o_row d-flex`) so the 'add identifier' button sits on the same line as the VAT field. 
https://github.com/odoo/odoo/blob/7d2d41fdef3446ca118290c1b31287887c0794db/addons/account/views/partner_view.xml#L169-L171
Localizations based on `l10n_latam_base` also put an identification type field (e.g. RUC, DNI) in that same row, before the VAT field. 
https://github.com/odoo/odoo/blob/7d2d41fdef3446ca118290c1b31287887c0794db/addons/l10n_latam_base/views/res_partner_view.xml#L14-L21
That identification type field carried the `oe_inline` class, which matched an unrelated, pre-existing mobile-only rule forcing any inline many2one to `width: 100% !important`. 
https://github.com/odoo/odoo/blob/7d2d41fdef3446ca118290c1b31287887c0794db/addons/web/static/src/views/form/form_controller.scss#L999-L1001
Inside the flex row this left no space for its sibling, collapsing the VAT value input.

<table>
  <tr>
    <th width="50%">Before</th>
    <th width="50%">After</th>
  </tr>
  <tr>
    <td width="50%">
      <img src="https://github.com/user-attachments/assets/12b1774f-2c60-4c89-a348-ccf514528552" width="100%">
    </td>
    <td width="50%">
      <img src="https://github.com/user-attachments/assets/3f1571f1-8e88-41d3-89bb-b9e2ce1e85fc" width="100%">
    </td>
  </tr>
</table>


Solution:
- Drop the `oe_inline` class from the identification type field in `l10n_latam_base`'s partner view.

opw-6375655

Steps:
- Install sale_management
- Make sure you have 100 quotations with 1 activity each
- Open activity view
- Default pager displays `1-100/100`
- Activity count display `To-do 80`

ActivityController uses `useModel` which passes the raw `component.props` to
`model.load()`, including the limit from `ir.actions.act_window` (default 80).
This value ended up in `fetchActivityData` via `params.limit || this.initialLimit`,
overriding `ActivityModel.DEFAULT_LIMIT` (100).

The records list was not affected because `RelationalModel._getNextConfig` never
reads `params.limit` (limit is not a `SEARCH_KEY`), so it always loaded 100
records correctly. But `fetchActivityData` used 80, causing a mismatch between
the records shown and the activity counts in the column headers.

```js
export const SEARCH_KEYS = ["comparison", "context", "domain", "groupBy", "orderBy"];
```

The fix strips `params.limit` in `ActivityModel.load()` before passing params to
`fetchActivityData`, so it falls back to `this.initialLimit (100)`. The pager
`onUpdate` handler calls `fetchActivityData` directly with its own `params.limit`
and is not affected.

However, `ActivityController` never forwards `limit` to the model. This
is why we always have `ActivityModel.DEFAULT_LIMIT (100)` without taking
into account actions's limit. To fix this we have to add the limit via
`this.props.limit`, as `ListController`.

`useModelWithSampleData` already had the correct behavior by calling
`model.load(getSearchParams(props))` which filters out non-search params like
limit. In 19.0 useModel was updated to do the same, so the issue does not
exist there.
Link to 19.0 fix: https://github.com/odoo/odoo/pull/211697

opw-6281125

Forward-Port-Of: odoo/odoo#281227
Forward-Port-Of: odoo/odoo#273929

### Steps to reproduce:

- Create a product with a bom and 2 operations
- Create an MO for 1 unit of that product
- Confirm the MO
- On the bom, delete the second operation and modify the first operation on anything else than the company, name or workcenter
- Go back to the MO, click the "Update Bom" button
> The second operation is not unlinked and the first operation is not updated

### Cause of the issue:

The `action_update_bom` updates the move raws and operations of the MO via the `_link_bom`:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L1214-L1218 For draft MO's all the work of these updates is done via the compute methods and by deleting all the records unrelevant to the new bom: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2603-L2626 And, in that case all the workorders that are not linked to an operation of the bom are expected to be deleted. However, when the MO is not in draft, the update of operations is expected to be performed here: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2647-L2664 However, since the operation of the bom has been deleted, the workorder that is expected to be deleted is not linked to any operation and hence does not satisfy the condition to be deleted:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2663-L2664
Concerning the non update of operations, it happens because the MO's operation are only updated on the three fields: `company_id`,
`workcenter_id`, `name`:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2647-L2664
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2628-L2629
However, many other changes can and are actually relevant.

### Note:

Prior to commit 80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 operations were archived on boms rather than deleted:
https://github.com/odoo/odoo/blob/4a5270218fe6fd7d30edb6d684b3340dc7423bab/addons/mrp/views/mrp_routing_views.xml#L53-L55 As such they would still be linked to an operation (but unrelated to the present values of the bom) and hence would fall into the condition of being unlinked from the MO.

Since the bom operations are no longer archived there is no way to determine if an operation used to be linked to a bom and we therefore need to chose between deleting all operations unrelated to the present bom or to keep them all (when the MO has been confirmed).

Enterprise: https://github.com/odoo/enterprise/pull/120709

opw-6285878
opw-6261738

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

Forward-Port-Of: odoo/odoo#273875
Forward-Port-Of: odoo/odoo#269747

**Steps to reproduce**
- Open any MO
- Click on 'catalog'
- Click on the three dots button of any product
- Try to edit
-> Traceback: `"product.product"."state" field is undefined.`

**Cause**
The `move_raw_ids` field on the MO form sets a context with `form_view_ref: 'mrp.view_mrp_stock_move_operations'`, so that editing a component's `stock.move` line in place opens that dedicated view: https://github.com/odoo/odoo/blob/20db2910d16fa6ebd07794fb9ed3fb1c8f57b0fc/addons/mrp/views/mrp_production_views.xml#L411-L417 The 'Catalog' button lives inside that same field, and calls `action_add_from_catalog_raw`, which delegates to the mixin's `action_add_from_catalog`: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/product/models/product_catalog_mixin.py#L17 Which conserve the `'form_view_ref'` from context: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/product/models/product_catalog_mixin.py#L28 and that action requests its form view with `view_id=False`: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/product/models/product_catalog_mixin.py#L25 Which will try to load `view_mrp_stock_move_operations`, since: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/odoo/addons/base/models/ir_ui_view.py#L3002-L3005 `_get_view` never checks that the resolved view's `model` matches the model it was asked for, so it returns `view_mrp_stock_move_operations`for the `product.product` model: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/mrp/views/stock_move_views.xml#L41 https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/stock/views/stock_move_views.xml#L128 `state` doesn't exist on `product.product`, hence the crash.

opw-6433620

Forward-Port-Of: odoo/odoo#279811

When the quantity of a make-to-order manufacturing order is changed, its finished move is copied to propagate the extra quantity downstream. In some cases (after splitting then merging back productions) that copy is not merged back, so the order ends up with two finished moves for the same product.

On validation, two things then go wrong:
- _post_inventory writes the produced quantity on each finished move,
  so both get the full quantity and the production is doubled
- mrp_account._cal_price prices the finished move and calls
  ensure_one(), which raises "Expected singleton" for an average/fifo
  product, so "Produce All" fails

Split the produced quantity across the finished moves with unit_factor (like _set_qty_producing already does), and price them as a whole instead of expecting a single finished move.

Steps to reproduce:
- Create a BoM for product A with the MTO route, and a component B
- Create a Sale Order for 30 units of A, confirm it
- Split the MO into 3 productions of 10, merge two of them
- On the third, Update Quantity 10 -> 15, then Produce All
- The product should be produced once (15, not 30), with A valued in
  average/fifo it instead of an error.

opw-6242504
opw-6310972
opw-6307025
opw-6354739

Forward-Port-Of: odoo/odoo#269254

Steps to produce:
---
- Install `sales` module.
- Go to Settings and enable `Units of Measure and Packaging`.
- Set a long name for `units` UoM.
- Create a Sale Order and add a product via the catalog.

Issue:
---
- Long UoM names are not fully visible in the catalog view.

Root cause:
---
- The quantity input uses `flex-shrink-0`, preventing it
  from shrinking when space is limited by a long UoM name.

Solution:
---
- Allow the quantity input to shrink by removing the
  `flex-shrink-0` constraint, giving the UoM name more
  space to remain visible.

Before:
---
<img width="395" height="46" alt="image" src="https://github.com/user-attachments/assets/33984db4-4c54-477d-b1db-dd0a8191a4a4" />

After:
---
<img width="399" height="57" alt="image" src="https://github.com/user-attachments/assets/b0326295-eea3-4aca-ab44-7c581bd5b9e7" />

Enterprise PR: https://github.com/odoo/enterprise/pull/121139

opw-6253382

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

Forward-Port-Of: odoo/odoo#267118

**Steps to reproduce:**
1. Install Accounting
2. Import a new invoice with more than 1000 lines (xlsx file found in ticket attachments)
3. Test the imported records

**Issue:**
- `RecursionError: maximum recursion depth exceeded`.

**Cause:**
- In a previous commit (3e32d7b9eace62dfa7334009707a93967906c726) aimed at fixing stale analytic distribution totals, the assignment loop in `_compute_discount_allocation_needed` was changed from iterating over `self` to `self.move_id.line_ids`.
- While this ensured all lines generated updated distribution ratios, it violated the compute logic: assigning values to records outside the current compute batch (`self`).
- By executing `line.discount_allocation_dirty = True` on external sibling lines, the method forced the ORM to trigger out-of-band `write()` calls. These writes re-triggered dependency checks (`_field_will_change`), which invoked the compute method again, leading to a recursive loop.

**Fix:**
1. Revert the assignment iteration back to `for line in self:`.
2. To preserve the intention of the previous commit (ensuring all lines recompute their shared distribution pool when one line changes), modify the method's `@api.depends` to be `move_id.line_ids.discount` and `move_id.line_ids.analytic_distribution`.

By declaring these relational dependencies, modifying a single line now batches all sibling lines into `self` from the start. This allows the lines to synchronize properly without triggering new ORM writes, eliminating the recursion.

opw-6451854

Forward-Port-Of: odoo/odoo#282050

**Steps to reproduce:**
* Create a **French** parent company and a branch.
* Activate **Electronic Invoicing (PDP)** for the parent company.
* Switch to the branch while keeping both the **parent company** and the **branch** selected in the company switcher.
* Go to **Settings → French Localization → Activate Electronic Invoicing**.
* Activate **Electronic Invoicing (PDP)** for the branch.
* Select the **Participate in the pilot phase** checkbox and try to save settings.

**Observed behavior:**
* A traceback occurs with the error: `psycopg2.errors.SyntaxError: syntax error at or near ")"` on `IN ()` in the SQL query inside `_force_update_l10n_fr_f10_moves`.

**Cause:**
* `_force_update_l10n_fr_f10_moves` searches for receivable/payable accounts using `company_ids IN companies.ids`.
* A branch company has no accounts assigned directly to it — accounts belong to the parent company — so the search returns an empty list.
* Passing an empty tuple to `IN %(account_ids)s` generates `IN ()`, which is invalid PostgreSQL syntax.

**Fix:**
* Replace `('company_ids', 'in', companies.ids)` with
  `('company_ids', 'parent_of', companies.ids)` in the account search
  inside `_force_update_l10n_fr_f10_moves`.
* This ensures that accounts owned by a parent company are correctly
  found when the given companies are branches, since branch companies
  inherit their parent's chart of accounts.

opw-6394650

The Sale Details report (report.point_of_sale.report_saledetails,
get_sale_details) repeatedly searches account.payment filtered by
pos_session_id while building the payments breakdown: it runs one such
search per (session x payment method) pair. Since pos_session_id had no
index, every one of those searches was a sequential scan over the whole
account_payment table, which degrades badly on databases with a large
payment history.

Adding index='btree_not_null' lets PostgreSQL resolve each lookup with an
index scan. This is the same index already added in saas-18.3 by
e5e3a3f7bf3770fe2bba11b501870d4fb7ef2e51.

Measured on a real customer database (Odoo 18.0), Sale Details report for
one PoS config over a full month:

  Dataset: 29 sessions, 1,317 orders, 212,160 account_payment rows.

  Per-lookup query plan (EXPLAIN SELECT id FROM account_payment
  WHERE pos_session_id = X):
    before: Seq Scan on account_payment   (cost=0.00..27263.00)
    after:  Index Scan using account_payment_pos_session_id_index
                                           (cost=0.29..11.84)

  get_sale_details, called directly and timed:
    before: 144.0 s  (of which 1,628 account.payment searches = 139.6 s, 97%)
    after:    5.5 s
    => ~26x faster

Methodology: get_sale_details was called directly on the model. The ORM
cache was invalidated (env.invalidate_all()) before the "after" run so the
improvement cannot be attributed to caching. The index creation was the
only change between the two runs (before: index dropped; after: index
created, 0.2 s). The count/time of account.payment searches was captured
by instrumenting Model.search during the "before" run.



This supersedes #276284, which got closed automatically after a bad force-push on the branch and cannot be reopened. As requested there by @pivi-odoo, the field now uses index='btree_not_null', the same diff as e5e3a3f7bf3770fe2bba11b501870d4fb7ef2e51 in saas-18.3.

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