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