If account.move and account.move.line have big data then domain with  create problme ORM create sub query like this

```
SELECT
    account_move.id
FROM
    account_move
WHERE
    (
        account_move.l10n_in_gst_return_period_id = 23
        OR (
            account_move.move_type IN ('in_invoice', 'in_refund')
            AND account_move.invoice_date >= '2025-11-01'
            AND account_move.invoice_date <= '2025-11-30'
            AND account_move.company_id IN (1)
            AND account_move.state = 'posted'
            AND (
                account_move.l10n_in_gst_treatment NOT IN ('composition', 'unregistered', 'consumer')
                OR account_move.l10n_in_gst_treatment IS NULL
            )
            AND account_move.id IN (
                SELECT
                    account_move_line.move_id
                FROM
                    account_move_line
                WHERE
                    EXISTS (
                        SELECT 1
                        FROM account_move_line_account_tax_rel AS account_move_line__tax_ids
                        WHERE account_move_line__tax_ids.account_move_line_id = account_move_line.id
                    )
            )
        )
    )
ORDER BY
    account_move.date DESC,
    account_move.name DESC,
    account_move.invoice_date DESC,
    account_move.id DESC
```

See this EXPLAIN for big database
```
Gather Merge  (cost=165759176482.82..2983665158687.50 rows=36 width=30)
   Workers Planned: 2
   ->  Incremental Sort  (cost=165759175482.80..2983665157683.32 rows=18 width=30)
         Sort Key: account_move.date DESC, account_move.name DESC, account_move.invoice_date DESC, account_move.id DESC
         Presorted Key: account_move.date
         ->  Parallel Index Scan Backward using account_move__date_index on account_move  (cost=59.28..2983665157682.51 rows=18 width=30)
               Filter: ((l10n_in_gst_return_period_id = 23) OR (((move_type)::text = ANY ('{in_invoice,in_refund}'::text[])) AND (invoice_date >= '2025-11-01'::date) AND (invoice_date <= '2025-11-30'::date) AND (company_id = 1) AND ((state)::text = 'posted'::text) AND (((l10n_in_gst_treatment)::text <> ALL ('{composition,unregistered,consumer}'::text[])) OR (l10n_in_gst_treatment IS NULL)) AND (SubPlan 1)))
               SubPlan 1
                 ->  Materialize  (cost=58.84..1601427.18 rows=4994548 width=4)
                       ->  Merge Semi Join  (cost=58.84..1556944.44 rows=4994548 width=4)
                             Merge Cond: (account_move_line.id = account_move_line__tax_ids.account_move_line_id)
                             ->  Index Scan using account_move_line_pkey on account_move_line  (cost=0.44..1339780.32 rows=26611459 width=8)
                             ->  Index Only Scan using account_move_line_account_tax_rel_pkey on account_move_line_account_tax_rel account_move_line__tax_ids  (cost=0.43..88678.65 rows=4994548 width=4)
```
So removing this from domain and put it as condition it's faster

Forward-Port-Of: odoo/enterprise#110334
Forward-Port-Of: odoo/enterprise#109795

## Short functional explanation of the error
When editing attendances of a schedule for which we checked the box `Define Amount of Hours per Day`, the resulting average hours per day and hours per week fields aren't computed correctly.

## Reproduction Steps
1. Go to Employee > configuration > Working Schedules.
2. Create a working schedule. Check the box Define Amount of Hours per day and in the Working Hours tab, remove all intendances.
3. Add a line for Monday, set the day period to Full Day and the duration in hours to 4.
4. Repeat the operation for tuesday and wednesday.

### Expected behavior
As we have 3 days during which we work 4 hours, the average hours per day should be 4, and the total hours per week should be 12.

### Unexpected behavior
The average hours per day and hours per week don't show the correct numbers.

## Origin of the issue
We compute the hours per week with this method:
https://github.com/odoo/odoo/blob/ae9fd7cc7d434d4b222c81aa58515c57d7426b65/addons/resource/models/resource_calendar.py#L690-L696 However, when we check the box `Define Amount of Hours per Day`, we don't set the attendances starting and ending hours. Instead, we work with duration hours.
Therefore, when the box is checked, we have to compute the weekly hours with the field `duration_hours`, and not `hour_from` / `hour_to`.

__
opw-5885571

Forward-Port-Of: odoo/odoo#248627

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

Forward-Port-Of: odoo/odoo#246295

**Steps to reproduce:**
- Install Expenses
- Activate "Incoming Emails" in the settings
- Configure the expense Alias
- Configure an "Incoming Mail Server"

- Create a Branch for a company
- Create a User:
  * Email Address: [an existing email address]
  * Allowed Companies: [the parent company + the branch company]
  * Default Company: [the branch company]
  * User Types: Internal User
- Create an employee for the user in the parent company

- From the email address, send a PDF to the expense alias

**Issue:**
The expense is not created in the database due to a UserError: "Incompatible companies on records".

**Cause:**
When the email is received and treated, the system tries to create an expense.
From the email address, it retrieves an employee that is linked to the expense.
For the company of the expense, if a user is linked to the employee, it takes the default company of the user.
Otherwise, it takes the company of the employee.
In this case, the company set on the expense is the default company of the user (i.e. the branch company) and the employee set on the expense belongs to the parent company ; which triggers the UserError during the company check.

**Solution:**
Always use the company of the employee, even if there is a user linked to the employee.

opw-5346809




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

Forward-Port-Of: odoo/odoo#253313
Forward-Port-Of: odoo/odoo#249415

Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form `o-color-[n]` with n some integer)

Those colors are a bit special (see full discussion on the opw)
- Their existence is described in module `web`
- Their CSS definition is implemented in module `html_editor`
- Reports don't use them at all We probably don't want reports' style to be influenced by the presence or lack thereof of the html_editor module, which was originally made to customize the interface.

Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.

This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.

After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#251446

Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)

Those colors are a bit special (see full discussion on the opw)

    Their existence is described in module web
    Their CSS definition is implemented in module html_editor
    Reports don't use them at all We probably don't want reports' style to be influenced by the presence or lack thereof of the html_editor module, which was originally made to customize the interface.

Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.

This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.

After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.

see odoo/odoo#251446

opw-5892573

Forward-Port-Of: odoo/enterprise#109206

## Description

The `Tracking` interaction's `setup()` method reads order tracking info from the HTML `data-order-tracking-info` attribute and passes it directly to `_trackGa()` → `gtag()`. Since the DOM `dataset` API always returns strings, `gtag()` receives a JSON string instead of an object, causing GA4 to silently drop all purchase event parameters (`transaction_id`, `value`, `items`, etc.).

Compare with `onAddToCart()` in the same file, which receives its data via `CustomEvent.detail` (already a JS object) and works correctly.

**Impacted versions:**

- 19.0

**Steps to reproduce:**

1. Configure a Google Analytics key in Website > Settings
2. Add a product to cart and complete checkout
3. On `/shop/confirmation`, inspect the dataLayer or GA4 debug view

**Current behavior:**

- `add_to_cart` event fires with correct ecommerce parameters (object)
- `purchase` event fires with a JSON **string** instead of an object — GA4 silently drops the parameters

**Expected behavior:**

- `purchase` event fires with a parsed object containing `transaction_id`, `value`, `currency`, `tax`, `items`

**Fix:**

Add `JSON.parse()` to convert the data attribute string back to an object before passing it to `gtag()`.

---

I hereby confirm I have signed the Odoo CLA (included in this PR as `doc/cla/corporate/comma.md`).

Forward-Port-Of: odoo/odoo#253074

Trying to find out why I kept having a bunch of leftover `tmpsomethingsomethign_chrome_odoo` leftovers I realised #203412 had a bit of an error in the location of the
`atexit.callback(browser.stop)`: the temporary directory for the user data dir is created as soon as the browser is instantiated, but the cleanup is only recorded after a successful `navigate_to`, so if that (or a previous step e.g. authentication) fails then the tempdir is never cleaned up.

Rather than just move the call up the body and re-introduce conditionals to `stop` to handle more partial initializations though, use the magic of ~~buying two of them~~ `ExitStack` to record cleanup requirements dynamically as the `ChromeBrowser` initialises.

This initially used a bunch of `ExitStack.callback` calls with ad-hoc cleanup, but turns out most of these cases are better as CMs:

- replace `mkdtemp` / `rmtree` by `TemporaryDirectory`, which Just Works as a CM
- add context-manager methods to the screencaster classes (also remove `stop` which is redundant with `__exit__`) so they Just Work as CMs
- convert `_chrome_start` and `_open_websocket` to `@contextmanager`... for obvious reasons

This makes the relation between setup and cleanup clearer, as well as more self-contained in case we want to move stuff to a submodule eventually. It also ensures cleanups run in the correct order, and avoids having to deal with partial initializations.

Keep `ChromeBrowser.stop` because it seems unnecessary to edit those out for now, but have it just `close` the exitstack (which runs all the registered cleanups).

NOTE: it might make sense for `browser_js` to just use `ChromeBrowser.cleanup` instead of having its own exitstack, not entirely sure... Alternatively it might make sense for ChromeBrowser to *take* a CM as parameter... and / or for ChromeBrowser to *be* a CM?

Forward-Port-Of: odoo/odoo#253035

Previously, we created a contrast-adjusted color for the `btn-outline` classes to ensure readability. This was also applied to manual colors selected via Theme tab, which made some inconsistencies with standard `btn`.

This commit fixes that by providing the contrast-adjusted color only on default palettes, and use the manual color as is when selected in the Theme tab.

task-5392258

| State | Before | After |
|--------|--------|--------|
| Normal | <img width="261" height="122" alt="image" src="https://github.com/user-attachments/assets/482ed97f-303c-4332-a748-1130a9ee5db7" /> | <img width="261" height="124" alt="image" src="https://github.com/user-attachments/assets/5e0b14ba-677a-480e-8aad-85c13f3a5f6e" /> | 
| Hover | <img width="261" height="124" alt="image" src="https://github.com/user-attachments/assets/87cec4fc-521c-4b36-84d3-81460cefa68c" /> | <img width="259" height="123" alt="image" src="https://github.com/user-attachments/assets/b17c309d-2b64-4dc2-a33b-e576831647e0" /> | 

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

Forward-Port-Of: odoo/odoo#239584

Before this commit, the "Threads" action in Discuss app had its popover width that would take the browser width.

This happens because, althought there's a classname to limit its size (`o-mail-Discuss-threadActionPopover`), this was applied on a part of popover and was ignored due to `mw-100 w-100`.

This commit fixes the issue by replacing the classname `.o-mail-Discuss-threadActionPopover` with 2 CSS rules for all action panels in popover:

```
.popover:has(ActionPanel) => max-width
.popover .ActionPanel-content => max-height
```

These 2 rules handle popover sizing as desired: fixed width for all these popovers, and max-height on the content part of the action panel. This fixes the problem of limited width for both 'Threads' and 'Invite People' popovers, in addition to handle scrollable content thanks to max-height.

Before / After
<img width="911" height="384" alt="Screenshot 2026-03-10 at 16 12 23" src="https://github.com/user-attachments/assets/f4b77fdb-f946-4d71-904a-d0b273fbe955" />
<img width="915" height="398" alt="Screenshot 2026-03-10 at 16 12 10" src="https://github.com/user-attachments/assets/b2e461e7-a39a-4698-bae0-421d9d87eccb" />

Forward-Port-Of: odoo/odoo#253100

This issue occurs on Single App and Single L10n, without demo data

### Summary
This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the stock.group_production_lot setting to be active. Specifically, it validates that the sum accurately reflects the Unit of Measure (UOM) across various packagings.
https://github.com/odoo/enterprise/blob/93e3c6f13fbab8d54694648d04908e451f1e97fc/stock_barcode/static/tests/tours/tour_test_barcode_flows_picking.js#L6472-L6498

### Observation
The grouping logic is contingent on the stock.group_production_lot setting. If this setting is inactive, the system fails to group lines, preventing the calculation of the aggregate total.

Without the production lot group active, the conditional checks will bypass the grouping process:
https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L53 https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L224-L225 

When the demo data are enabled [the group is implied](https://github.com/odoo/odoo/blob/8a7ca8beac521f41faf79a6022935fdbb605de76/addons/stock/data/stock_demo.xml#L185-L187)


### Impact
When stock.group_production_lot is disabled:
 - Lines remain ungrouped.
 - The total sum of the grouped line is never generated.
 - The test fails as it cannot find or validate the expected sub-line totals.

This issue originate from the 18.3 forward port of this [commit](https://github.com/odoo/enterprise/commit/84d4b1f144e8a437fe76ec5ef3bc9799cdf993b0) 
runbot-241109

Forward-Port-Of: odoo/enterprise#108908

The previous compute method loaded all moves records into memory, which caused an out-of-memory issue for large number of record. Replaced the logic with read_group aggregation to perform the calculation using sql and reduce memory usage.

Note: the issue is faced during 16.0 version too but as 16.0 is no more supported for bug fix. So, doing it from 17.0 version. 

```
Traceback (most recent call last):
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 657, in mock_view_tree
    self.mock_web_search_read(model, view, [domain], fields_list)
  File "/tmp/tmpkvo8a96w/migrations/base/tests/test_mock_crawl.py", line 691, in mock_web_search_read
    data = model.search_read(domain=domain, fields=fields_list, limit=80, order=filter_order(model))
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5074, in search_read
    result = records.read(fields, **read_kwargs)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3038, in read
    return self._read_format(fnames=fields, load=load)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3219, in _read_format
    vals[name] = convert(record[name], record, use_name_get)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 6007, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1222, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1404, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4276, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 98, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in _compute_value_residual
    posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in filtered
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5496, in <listcomp>
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/enterprise/16.0/account_asset/models/account_asset.py", line 293, in <lambda>
    posted_depreciation_moves = record.depreciation_move_ids.filtered(lambda mv: mv.state == 'posted')
  File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1187, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3245, in _fetch_field
    self._read(fnames)
  File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3351, in _read
    self.env.cache.insert_missing(fetched, field, values)
  File "/home/odoo/src/odoo/16.0/odoo/api.py", line 1123, in insert_missing
    field_cache.setdefault(id_, val)
MemoryError
```

opw-5921410
upg-3891767

Forward-Port-Of: odoo/enterprise#109008

*: website_sale
Commit [1] added a UI block when doing a reloadable operation, and
unblocked it once the action finished. However, if the action didn't
complete, `ui.unblock` would never be called, leaving the UI blocked
indefinitely.

To reproduce the issue in website_sale:
- Install Website & eCommerce
- Go to /shop page
- Open a product page
- Open the editor
- Click on the main product image
- In the "Images" section > Click on "Add more" in the Extra media field
- Popup shows up but it loads indefinitely

Fix this by always calling `ui.unblock` regardless of the reload
outcome. Also move the media dialog opening to `load`, which runs before
the UI is blocked, passing the selected media as `loadResult` to `apply`.

[1]: https://github.com/odoo/odoo/commit/453b7eb8e038ee8e8a54de16fc1a45fb2fab573a
Co-authored by: Robin Lejeune (role) <role@odoo.com>

opw-6003505, opw-6006393, opw-6016898, opw-6013484, opw-6014383

Forward-Port-Of: odoo/odoo#253025
Forward-Port-Of: odoo/odoo#252755

Main issue:

Prior to this commit, updateValue would guarantee that `body_arch` and
`body_html` were always updated in sync (to avoid an inconsistent state where
the user thinks they updated the mailing, and they see the new html in the
editor, but the email html is obsolete and would be sent as is).

However this caused another issue, that the user would lose their work when
switching tab in the Notebook, because computing the `body_html` may be slower
than the view patch to switch tab (`updateValue` is interrupted). In such a
case, neither `body_arch` nor `body_html` was updated on the record, and when
the user comes back to edit them, they see that all changes were lost.

To prevent this, a new strategy is adopted:
- `body_arch` is now updated as soon as possible to save the latest user
  changes
- `body_html` is set to an empty string to avoid inconsistencies, and in order
  to trigger `convert_inline` automatically the next time the
  `mass_mailing_html_field` is instanced without any user action.
- after `convert_inline`, if `updateValue` was not aborted, the record is
  updated again with the new value for `body_html`

Minor issues:

1) Prior to this commit, the iframe would flicker during `convert_inline`
because it was done inside that very iframe, and the `convert_inline` needs a
specific width (1320px) for it to work properly, meaning that if the iframe was
not at that specific dimension, it was resized temporarily for that process.
This commit introduces hooks to execute the `convert_inline` process in a
separate iframe, outside of the user view, which removes this flickering.

2) Prior to this commit, assets for readonly/basic editor/builder were all
loaded inside the iframe, and then toggled on/off depending on which were
needed. Since the `convert_inline` process is moved in another iframe, it's as
good time as any to deprecate this toggling (as it could be a bit unreliable and
could cause some flickering when unloading/reloading the style). There is now a
separate asset bundle for the 3 use case, and only one of them is loaded per
iframe depending on the needs.

3) Prior to this commit, `body_html` was hard-coded as a dependency of the
`mass_mailing_html_field`, and that dependency lacked the `required` attribute,
which should depend on the value of `body_arch`. The dependency is now added in
the related views, and the field is now generic. This also prevents the user
from leaving the view if `convert_inline` could not be completed successfully.

4) Prior to this commit, switching to another view through `doAction` could
throw an error if the field was dirty, as the `form view` would be destroyed
before `commitChanges` had the time to be completed. Now, `commitChanges`
promise is properly awaited by the `action_service` if the field is dirty before
`doAction` (unless `forceLeave` is true).

5) Prior to this commit, the record was updated through a `blur` event on the
iframe window. However, it means that every time the iframe looses focus when
the users interacts with the builder, a popover or the form status indicator,
that blur event would fire, triggering the `convert_inline` process. This commit
reduces the amount of such updates by only triggering the update outside of
these elements, as we don't need to update the record value while the user is
still actively editing the mailing.
Blur handlers/props are deprecated with this commit and will be removed further
down the line.

6) Ensure that in the rare case where a `html_field` value is exactly the same
on different records, the `html_field` state key is updated (triggers a
wysiwyg/mass_mailing_iframe reset).

7) Remove an erroneous part in `onWillUpdateProps` of `mass_mailing_html_field`
which could display the theme selector again on the same record just after
selecting a theme if props were updated.

8) Ensure `withBuilder` getter of `mass_mailing_html_field` properly reads the
state activeTheme every time it is used (if it does not, it could cause issues
with the reactivity, since reading on the state is required for a property
subscription).

9) Remove a useless `onWillUpdateProps` of `mass_mailing_iframe` which was never
used because when `props.showCodeView` changes, the iframe is always destroyed,
so there is no need to update its state.

10) Deprecate usage of `<meta http-equiv="X-UA-Compatible" content="IE=edge"/>`,
to be removed further down the line, as it is useless in the modern web.

11) Ignore errors during a builder "Operation" that was not finished before the
editor was destroyed. In `mass_mailing`, the editor is expected to be
destroyable synchronously to work inside an Odoo view, unlike in `website`.
What's already in the DOM just before destruction will be updated on the
`record`, and the rest of the operation will be lost. However, an attempt is
made to wait for ongoing operations at the start of the
`HtmlField.commitChanges`.

12) Ensure correct visibility option state
Prior to this commit, the `dataAttributeChangeAction` selected item depended on
the domain value computed during the last template rendering, compared to the
current edited element value. The issue is that when an edited element receives
a new `data-filter-domain`, the selected options are evaluated before the
component can register the new domain in its state, so the wrong values are
compared. In this particular case, since we only need 2 values (on/off), an
acceptable trade-off is to choose the selected item ("always visible" vs
"conditionally") based on the Boolean value of the attribute.

13) Remove deprecated assets toggle test
The toggle assets feature was deprecated in a prior [commit1].
The test is removed as its outcome is non-deterministic, because it depends on
the `target` property of `event` returned as a promise resolution value by
`loadBundle`, however the browser can set that target to `null` after the event
was dispatched, so relying on the target value to keep track of the inserted
link is not reliable.
Since that `toggle` feature is not used anymore, it is not needed to run a test
for it. The feature will be removed in the latest `dev` branch.

[commit1]: https://github.com/odoo/odoo/commit/a0aa581636e257894c6c7e87c3793edebecad303

14) Prevent crash on commitChanges if editor is not ready
Prior to this commit, various checks in `commitChanges` did not take into
account that the editor could be instanced but not ready yet (meaning that
plugins are not available, and it is not possible to extract the editable
content).
This commit ensures that `commitChanges` can not crash if called when the editor
is not ready.

15) Properly keep track of dirtiness
mass_mailing changes related to [commit2], which added a way to keep track of a
specific change handled during one `commitChanges` call. The field should stay
dirty if it received changes during a `commitChanges` execution.
In mass_mailing specifically, there were 2 other situations with invalid
tracking of dirtiness:
a) A new record with no change could not be discarded as it was incorrectly
marked as dirty since the `inlineField` value is "".
After this commit, the field is marked as dirty only if the edited field value
is not "" while the `inlineField` value is "", which is the problematic
situation where both values are desynchronized. A new record with both values at
"" is not marked as dirty anymore.
b) Setting a new theme in mass_mailing did not communicate properly with the
relational model about dirtiness.
After this commit, using `setThemeHTML` triggers `onChange`, and the record
update properly tracks that change to communicate with the
`FormStatusIndicator`. The field `isDirty` property stays at `true` though,
because it still needs to execute `convertToEmailHtml` to compute the
`inlineField` value, and it needs the `editor` for that. A `commitChanges`
occurs `onEditorReady` to execute this computation, at the end of which the
field is finally set as not dirty.

[commit2]: https://github.com/odoo/odoo/commit/378580735c785bdcf8b184342834d2b3ddaaaedd

16) Prevent crash with null selection
`document.getSelection()` returns `null` when the selection is not in the
document. However the selection plugin `isSelectionInEditable` function only
support a selection object or `undefined` as an argument, and will crash with
`null`.
This commit ensures that a valid value is provided to the plugin function to
prevent crashes where the selection is moved outside of the `mass_mailing`
iframe before `normalize_handlers` execution.

task-5976348

Forward-Port-Of: odoo/odoo#250883

Scenario:

- be on odoo SaaS instance
- be on non-translated page with enough content to do 4 requests
  to /html_editor/generate_text (that are done in chunk of 2000
  characters per request currently)
- open the editor and use "Translate to {lang}" (ai translation)

Result: you see a message "Connection lost. Trying to reconnect..." and
after waiting 10-20 seconds, no translation are inserted in the page.
In reality the requests after the 3 first ones were cancelled (with
error 429 too many requests) by nginx, and the 3 first ones worked
correctly but their result was not used because of the error of the
other ones.

Fix:

- decrease the number of concurrent request from 5 to 3 which is the
  current default for this route on SaaS

- adapt the code so if there is errors on one request, successfull
  requests will still be applied with the text "Translation Error.
  {number} text blocks were skipped during translation. Please try
  again." for the blocks that were missed.

This way even if there is an error, the translation is not totally
blocked and doesn't need to be restarted from zero (making it impossible
in the original scenario).

Side note: the number of text blocks not translated was a multiplication
of the total number of text blocks by the number of failed response.
This fix adapts it to just the total of words substrating the number of
translation applied.

opw-5892402

Forward-Port-Of: odoo/odoo#250611

During migration, the `l10n_pl` end-migrate script was loading
 for every company using the `pl` chart template, including child companies.

However, account codes must be [unique](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_account.py#L1033) across parent and child companies.
Since the chart is already loaded for the root company, reloading it for child companies cause duplicate account code errors during migration.

To prevent this, restrict chart loading to root companies only, which is consistent with how account code uniqueness is enforced.

**Steps to reproduce:**
1. Create a database in 17.0
2. Install `account_accountant` and `l10n_pl`
3. Create a child (branch) for the company using the `pl` chart template
4. Migrate the database to 18.0
5. Migration fails with duplicate account code validation errors

**Traceback**
```py
Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/service/server.py", line 1366, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-13>", line 2, in new
  File "/home/odoo/odoo18/community/odoo/tools/func.py", line 97, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/odoo18/community/odoo/modules/registry.py", line 129, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/odoo18/community/odoo/modules/loading.py", line 523, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 222, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/odoo18/community/odoo/modules/migration.py", line 259, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/odoo18/community/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
    Template._load_data({'account.account': Template._get_account_account('pl')})
  File "/home/odoo/odoo18/upgrade/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
    return super()._load_data(data, *args, **kwargs)
  File "/home/odoo/odoo18/community/addons/account/models/chart_template.py", line 677, in _load_data
    created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals, ignore_duplicates=ignore_duplicates)
  File "/home/odoo/odoo18/community/odoo/models.py", line 5531, in _load_records
    records = self._load_records_create([data['values'] for data in to_create])
  File "/home/odoo/odoo18/community/odoo/models.py", line 5435, in _load_records_create
    records = self.create(vals_list)
  File "<decorator-gen-196>", line 2, in create
  File "/home/odoo/odoo18/community/odoo/api.py", line 498, in _model_create_multi
    return create(self, arg)
  File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 987, in create
    records._ensure_code_is_unique()
  File "/home/odoo/odoo18/community/addons/account/models/account_account.py", line 1064, in _ensure_code_is_unique
    raise ValidationError(
odoo.exceptions.ValidationError: Account codes must be unique. You can't create accounts with these duplicate codes: 01.000.100, 01.000.200, 01.000.400, 01.000.900, 02.000.100, 02.000.200, 02.000.300, 02.000.900, 03.000.100, 03.000.200, 03.000.300, 03.000.400, 03.000.500, 03.000.600, 03.000.700, 03.000.800, 03.000.900, 03.050.100, 03.050.200, 03.050.300, 03.050.900, 07.010.200, 07.010.300, 07.010.400, 07.010.500, 07.010.600, 07.020.100, 07.020.200, 07.020.300, 07.030.100, 07.030.200, 08.000.100, 08.000.200, 08.000.300, 08.000.400, 08.000.500, 10.000.100, 10.000.200, 10.000.900, 13.000.100, 13.000.200, 13.000.900, 14.000.100, 14.000.200, 14.000.900, 14.050.100, 20.000.100, 20.000.200, 20.000.300, 21.000.100, 22.000.100, 22.010.100, 22.010.200, 22.010.300, 22.020.100, 22.020.200, 22.020.300, 22.030.100, 22.030.200, 22.030.300, 22.030.400, 22.030.500, 22.030.600, 23.000.100, 23.000.200, 23.000.900, 24.010.100, 24.010.200, 24.020.100, 24.020.200, 24.030.100, 24.030.200, 24.030.300, 24.030.400, 24.050.100, 24.090.100, 24.090.200, 24.090.300, 24.090.900, 28.000.100, 29.000.100, 29.010.100, 29.020.100, 30.000.100, 30.000.200, 30.000.300, 30.000.400, 30.000.500, 30.000.600, 30.000.700, 30.000.800, 30.000.900, 31.010.100, 31.060.100, 31.090.100, 33.000.100, 33.000.200, 33.000.300, 33.000.400, 33.000.500, 33.000.600, 34.010.100, 34.020.100, 34.020.200, 34.020.300, 34.020.400, 34.060.100, 34.070.100, 39.000.100, 40.000.100, 40.010.100, 40.010.200, 40.010.300, 40.010.400, 40.010.900, 40.020.100, 40.020.200, 40.020.300, 40.020.400, 40.020.500, 40.020.600, 40.020.700, 40.020.900, 40.030.100, 40.030.200, 40.030.300, 40.030.400, 40.030.500, 40.030.600, 40.030.700, 40.030.800, 40.030.900, 40.040.100, 40.040.200, 40.050.100, 40.050.200, 40.050.300, 40.050.900, 40.090.100, 49.000.100, 49.000.200, 49.000.300, 49.000.400, 50.000.100, 50.000.200, 50.010.100, 50.010.200, 52.010.100, 52.070.100, 53.000.100, 53.000.200, 55.000.100, 55.000.200, 58.000.100, 60.000.100, 60.010.100, 60.020.100, 62.000.100, 62.010.100, 64.000.100, 64.010.100, 65.000.100, 65.010.100, 70.000.100, 70.000.200, 70.000.300, 70.000.400, 70.010.100, 70.010.200, 70.010.300, 70.010.400, 73.000.100, 73.000.200, 73.000.300, 73.000.400, 73.010.100, 73.010.200, 73.010.300, 73.010.400, 74.000.100, 74.000.200, 74.000.300, 74.010.100, 74.010.200, 74.010.300, 75.000.100, 75.000.200, 75.000.300, 75.000.400, 75.000.500, 75.000.600, 75.000.700, 75.000.900, 75.010.100, 75.010.200, 75.010.300, 75.010.400, 75.010.500, 75.010.900, 76.000.100, 76.000.200, 76.000.300, 76.000.400, 76.000.900, 76.010.100, 76.010.200, 76.010.300, 76.010.900, 79.000.100, 79.000.200, 79.000.300, 79.000.400, 79.000.500, 80.000.100, 80.000.200, 80.000.300, 80.000.400, 81.010.100, 81.020.100, 81.030.100, 81.040.100, 82.000.100, 83.000.100, 83.000.200, 83.010.000, 83.010.100, 83.010.200, 84.010.000, 84.020.100, 84.020.200, 85.010.100, 85.020.100, 85.020.200, 85.020.300, 86.000.100, 87.000.100, 87.000.900
```

**Fix:**
- Load `account.account` records only for root companies during When the chart template loads for `pl` localization.

opw-5932421
upg-3895331

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#250654

Versions:
---
Reproducible on 18.0+
Fix targets 16.0 to keep the code consistent across versions

Issue:
---
Due to this issue, a line with zero subtotal amount will be discarded
in quotation document upload.

Steps to reproduce:
---
1- In sale app, upload a quotation document without line amount. (You could use the one attached in the ticket)
2- As you see, lines are discarded.

Cause:
---
This regression is introduced in https://github.com/odoo/odoo/pull/245862, to prevent lines with zero amount in accounting. The https://github.com/odoo/odoo/pull/245862 targets 16.0. However, the `sale_edi_ubl` is introduced on 18.0.

Fix:
---
Instead of `_retrieve_line_vals` (`_import_fill_invoice_line_values` on 16.0) returning `None` when `price_subtotal` is not present, it can keep returning `dict` with an extra key `price_subtotal`, and filter out unwanted line in `_retrieve_invoice_line_vals` itself.

opw-5977735

Forward-Port-Of: odoo/odoo#253149
Forward-Port-Of: odoo/odoo#251463

Currently, if we try to update the existing `l10n_it_edi_attachment_file` with the signed data received during the submission of an invoice (Invoices for Italian Public Administration businesses must be signed, handled on the IAP side), it fails.

The problem is that in this specific flow, the 'attachment' variable contains a binary rather than attachment_data.

Unfortunately, I could not find a complete flow to reproduce the issue, as there is no flow that sends an invoice to SdI while the l10n_it_edi_attachment_file variable is already set in the move, except maybe via manual import of an attachment into the invoice.

Expected flow:
- User creates a move with `l10n_it_edi_attachment_file` (unspecified how)
- User sends the move to SdI for a Public Administration partner
- IAP signs the attachment and sends it back to Odoo
- Odoo raises an error because it tries to use dictionary features on a binary field
- Odoo does not save the transaction ID, and if the user tries to resend the move, a Duplicate Error occurs from the SdI side.

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

Forward-Port-Of: odoo/odoo#252966

steps to reproduce:
-------------------
1. Install Time Off
2. Go to Configuration > Accrual Plans
3. Create an accrual plan:
   * Set the accrued gain time to "At the start of the accrual period"
   * Set the carry-over time to "At the start of the year"
4. Create a milestone:
   * Set the number of accrued days to 1
   * Set the accrual frequency to "monthly" and the carry over to "None.Accrued time reset to 0"
5. Go to Management > Allocations
6. Create an allocation:
   * Set the start date to 2025-01-01
   * Set the accrual plan to the one created above
7. Use future allocations to check accruals

current behavior:
-----------------
- On 2026-01-01 --> accrued days = 1  (correct)
- On 2026-02-01 --> accrued days = 1  (should be 2)
- On 2026-03-01 --> accrued days = 2 (delayed accrual, off by one month) 

cause of the issue:
-------------------
Commit 30c7011 introduced a condition that accrues time off on the carry over date:
https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/hr_holidays/models/hr_leave_allocation.py#L559

This incorrectly evaluates accruals across the carry over period instead of restricting to the current month, causing February accruals to be skipped.

**Reason February accruals are skipped:**
https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L559-L561
https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L541-L544

* After January, the last_executed_carryover_date is set to 2026-01-01.
* Therefore, February uses last_executed_carryover_date = 2026-01-01.
* The condition evaluates as true for February:
```python3
last_executed_carryover_date <= allocation.nextcall <= carryover_period_end
2026-01-01 <= 2026-02-01 <= 2026-02-01
```
As a result, the February accrual is skipped.

**Why it works correctly in March:**
* After February, the last_executed_carryover_date is updated to 2027-01-01.
* March now uses this updated date:
```python3
last_executed_carryover_date <= allocation.nextcall <= carryover_period_end
2027-01-01 <= 2026-03-01 <= 2027-02-01
```
The condition is not satisfied, so accruals are processed correctly.

solution:
----------
Add a condition to check if the loop has already run for the current carryover 
period. This ensures the system avoids applying the carryover twice,
allowing subsequent accruals to process as expected.


opw-5020834

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

Forward-Port-Of: odoo/odoo#253409
Forward-Port-Of: odoo/odoo#227646

**Steps to reproduce:
1. Install invoicing app
2. Add French language in the settings
3. Create a customer with language set as French
4. Create a product and define french translations of the name and the description in Sales tab
5. Create an invoice for that customer and choose the product you created
6. You will find the translated product name and description under the product name
7. Edit the description, save and preview the invoice
8. The invoice line will contain [Product Name EN] [Product Name FR] [Product Description FR]

**Description of the issue:
When creating an invoice for a customer whose language differs from the user's account language, manually editing the product description on an invoice line causes the original product name to be prepended to the description. The same issue happens in a RFQ in Purchase.

**Expected behaviour:
User can edit the product description in the invoice line and the output in the invoice should only be the translated name and description, without the original product name.

**Why this happens?
1. When the product is selected in the invoice line, the label is loaded from _compute_name method in account_move_line, which holds the translated name and description.
2. After editing the description and escaping the field (clicking outside it), the parseLabel method is called, which prepends the original name to the label, making the invoice output as [original name] [translated name] [translated desc.]

**The fix
Added translated_product_name computed field to follow a similar flow as the sale quotation which is already working as intended. Fix is done in Invoice and Purchase.

opw-5480494

Forward-Port-Of: odoo/odoo#248401

When a delivery address is selected as the customer in the POS UI and an invoice is generated from the POS order, it results in two different `partner_id` being set on the `pos.order` and the `account.move`. It is expected, as a delivery address cannot logically be used as an invoicing address.

Anglo-saxon accounting registers the COGS with additional account.move.line on the invoice and, when using real time valuation, the balance of these lines is calculated from values found on the corresponding `stock.move`.

Currently, the `stock.move` cannot be found if the `partner_id` on the `pos.order` and the `account.move` are different. The system then falls back on the `standard_price` of the `product_id`, which is incorrect. In version 19+, the `product_id` used to calculate the unit price is fetched from the `stock.move` but, because it's an empty recordset, the balance of the COGS is 0 and the lines are not created.

An easy fix could be to remove this check of equivalence between the two `partner_id`. The invoice is created directly from the POS order anyway. I am not sure why it is necessary. Am I missing something?

Steps to reproduce:
1. Create a product with fifo and automated valuation. Make sure that the product type is storable.
2. Validate one purchase and its delivery for the product (qty 5, unit price 5).
3. Validate another purchase and its delivery for the product (qty 5, unit price 10).
4. Configure the point of sale to allow invoicing.
5. Open a pos session then sell 1 item of the product. Select a delivery adress as the customer and generate an invoice.
6. Since the product is fifo, this means that the cost of goods sold is 1 * 5.
7. The correct expense account line should have balance of 5.0.
8. The correct output account line should have balance of -5.0.
9. The COGS lines instead have a balance of 8.13 and -8.13 which corresponds to the standard price of the product at the time of the invoice.

Related ticket: opw-5467877

Forward-Port-Of: odoo/odoo#245208

Steps to reproduce:
1. Create a new SO/PO/Invoice and add a product.
2. Add a new section below the product.
3. Open the catalog and click the Remove button for the added product.

Issue:
- The product is not removed from the SO/PO/Invoice.

Cause:
- When removing the product, the 'No section' entry is also removed if it becomes empty.
- As a result, `this.env.searchModel.selectedSection.sectionId` point to the first remaining section in the order.
- Because of this incorrect reference, the wrong `section_id` is passed in the params, and `update_order_line_info` does not update the intended order line.

Fix:
- Use `this.env.selectedSectionId` instead of `searchModel.selectedSection.sectionId` to ensure the correct `section_id` is always passed.

After applying this fix, `test_catalog_vendor_uom` tour was failing because in tour execution the kanban records are mounted before the search panel finishes initializing the selected section. As a result, the initial section state is not yet stabilized when the price is asserted.

To address this:
- Update the tour to explicitly wait until the "No section" entry is marked as selected in the search panel before asserting      the product price, ensuring the catalog is fully initialized.

opw-5960140

Forward-Port-Of: odoo/odoo#250103

When browsing an eCommerce in any language but English and trying to filter on an attribute with more than 8 values and at most 20, the "View more" and "View less" options are not translated

Steps to reproduce:
1. Install eCommerce
2. Create a product with one attribute that has 9 to 20 values and publish the product to the eCommerce (the attribute should have radio display type and should be visible in the eCommerce)
3. Add a language (e.g. French) and translate the eCommerce's website
4. Open the website and set the language to French
5. In the left column, open the filter for the attribute previously created
6. Click on "Voir plus"
7. "View less" is not translated, if you click on it, "View more" is not translated anymore

Issue:
The translation for "View more" is generated because it is present in the template `filter_radio_and_multi_attributes` but when we update the text in website_sale.js, the terms are not translated anymore

Solution:
Use `_t` to translate the "View more" and "View less" terms

opw-5985712

Forward-Port-Of: odoo/odoo#252828

Claimed credit notes (DTE 61) were being polled indefinitely by the _l10n_cl_ask_claim_status cron. The SII endpoint listarEventosHistDoc does not support DTE 61 and always returns codResp 3 "Tipo de documento no corresponde". Since the response never contains event data, l10n_cl_claim is never set, the record permanently matches the cron domain, and polling repeats every 4 hours forever.

Root cause: the cron domain included out_refund move types, but the SII endpoint used to fetch claim events does not support credit note document types. There is no point querying the SII for claim details on credit notes through this endpoint.

Fix: restrict the cron domain to out_invoice only

Before: claimed credit notes matched the cron domain, _get_dte_claim was called on every run, SII returned codResp 3, l10n_cl_claim stayed False, record never exited the domain.

After: credit notes are excluded from the cron domain entirely and are never polled, stopping the infinite loop.

opw-5933833

Forward-Port-Of: odoo/enterprise#109995

… request

ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects the invoice with errors like:
`Code 1814: Campo Cmp.Items.Pro_precio_uni invalido. El valor debe tener 12 enteros y 6 decimales como máximo.`

To ensure compliance, values are formatted before sending the request to ARCA.

**Precision rationale**
ARCA WS documentation mentions 4 decimal places, while the WS error message itself refers to 6 decimals, and in practice the service accepts up to 6 decimals without rejection.

In this implementation, we intentionally use 2 decimal places. The reason is consistency with the rest of the monetary amounts in the invoice: line totals, invoice total, taxes, and related amounts are all rounded to 2 decimals, even in cases where the documentation allows higher precision (e.g., 3 decimals).

Before the changes in rounding precision, the stable version already rounded values according to line rounding. In real-world accounting scenarios, the vast majority of use cases operate with 2 decimal places. Keeping this behavior ensures consistency across calculations and avoids discrepancies caused by mixed rounding strategies.

For a stable release, this was considered the safest and most predictable option, even though the WS technically allows higher precision.

Stable version changes are covered in the following commits:
https://github.com/odoo/odoo/pull/243987/changes/8a21ec45f9d72a7c80d9c1f8398fe01e298ae775
https://github.com/odoo/odoo/pull/246347/changes/79ceeed707ef274f19a04e741f6cb8ac60c44321


<img width="780" height="435" alt="image" src="https://github.com/user-attachments/assets/9f25a0e8-b9d2-4ad2-bbcf-e988c7f8a4c9" />

[WSFEX - Manual de desarrollador](https://www.afip.gob.ar/ws/WSFEX/WSFEX-Manualparaeldesarrollador.pdf)

Forward-Port-Of: odoo/enterprise#110218
Forward-Port-Of: odoo/enterprise#106509

Current behavior
---
When confirming 1 SO with 2 products with 1 BoM and 1 Rerouting Rule with 0 min/max, with warehouse rule pbm (2 steps: Pick then manufacture), it creates a picking transfer with only 1 MO attached.

Expected behavior
---
The picking transfer should have 2 MO's.

Steps to reproduce
---
1. Create 2 Products with different BoM's, keep per-product routes empty. 
2. Set reordering rules for both to route: Manufacture.
3. Go to warehouses config and set manufacture rule to 2 step (pick -> manufacture)
4. Confirm a SO with those 2 products.

Cause of the issue
---
If we don't have any Make-to-Order routes for a product, the Make-to-Stock default rule of the warehouse would be used. 
In such case, all MO's related to such OP (orderpoint/warehouse) would be linked into one picking. The stock.picking model uses related fields to compute product_ids, which calculates relation using next(...) in the ORM. This takes only the first MO's stock move and ignores the second, hence ignoring other production groups.

Fix
---
Instead of using related fields, use compute to access every relavent production ids.

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

Forward-Port-Of: odoo/odoo#249996

## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.

---

## How to reproduce:


https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8


- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10 
- => Indirect Demand Qty for CMP is not shown (because it's 0)

---

## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ... 
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ====================================================================== 
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
    self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
 ```

---

OPW-5979738

Forward-Port-Of: odoo/enterprise#110374
Forward-Port-Of: odoo/enterprise#109693

## Issue
Users who do not have the "write" right access on `product.template` cannot print product labels.

## Steps to reproduce
1. Install *Sales* (`sale_management`)
2. In Settings > User & Companies > Users, make sure Marc Demo does not have any write access on `product.template`
3. Log in as Marc Demo
4. In Sales > Products > Products, open a product and click *Print Labels* from the cogwheel menu
5. **An Access Error is shown, saying that the operation is allowed for the `Products/Create` group.**

## Cause
[This commit](https://github.com/odoo/odoo/commit/95ace0a694eaf83329b50e6b89f774f0c59fec5e) removed Products-related rights from the `base.group_user`. This made a difference in terms of access rights, as the `IrActionServe.run` method checks for the "write" access by calling `_can_execute_action_on_records`:

https://github.com/odoo/odoo/blob/d15685304f479541879fabd55ea1cae4252a2a90/odoo/addons/base/models/ir_actions.py#L1230-L1239

When a `group_ids` field is added to the action, this check is no longer performed.

opw-5914988

Forward-Port-Of: odoo/odoo#248672

When writing to a PoS config, it will automatically set an
`advanced_employee_ids` if none is set. But it will take any employee
that is part of `point_of_sale.group_pos_manager`. If the employee
selected is not part of the same company as the PoS config, and the
current user doesn't have HR employee access it will trigger an ir.rule
that block the user from opening the settings.

Steps to reproduce:
-------------------
* Create a new company
* Create a new user that only have access to this company and no HR
  access
* Create a PoS in the new company
* Login as the new user
* Try to open the settings
> Observation: You will get an access error because the employee set in
  `advanced_employee_ids` is from the other company

Why the fix:
------------
We make sure that when automatically setting the advanced_employee_ids
we filter out the ones that are not from the correct company. If no
employee exist that satisfies the requirements, we take a user from the
`group_pos_manager` and create an employee for him.

opw-5885417

Forward-Port-Of: odoo/odoo#252402