Since [1] (and its follow-up commits), the softphone became the "UI active element" once it opens. This was required to solve multiple keyboard navigation issues that occurred while being on the app switcher with the softphone opened. It also simply improved navigation any time the softphone is used, allowing it to close on ESC, etc. This is also consistent with what is being done at [2] where the softphone will get closer to modal behavior.

However, it came with a bug: dropdown inside and outside the softphone were not closed anymore if clicking outside the softphone. E.g.:
- Open the user dropdown menu
- Click outside => it closes
- Open the softphone
- Open the user dropdown menu
- Click outside => It does not close anymore

This commit adds a test about it. The fix lies in the dropdown closing logic in the community counter-part of this PR.

[1]: https://github.com/odoo/enterprise/commit/df1772e877a508150fd3f549526dec9d867354be
[2]: https://github.com/odoo/enterprise/pull/111337

task-6055692

When we are at the appointment details page, and have the option allow_guests turned on, and go to the editor for translation, we encounter the issue.
Steps To Reproduce:
1. Create an appointment.
2. Go to the "Options" tab, and click on "Allow Guests".
3. Go to the web page for the appointment, select the data and time.
4. Now, on the details page, go to any other language than the default, and click on edit/translate.
5. The issue occurs.

The issue occurs when the regex tries to match the placeholder where the guests are added, which is enabled by the allow_guests. It contains strings  with newline characters. The regex fails to take into consideration for these newlines and breaks causing the issue to appear.

To fix the issue, we'll use regex to account for the new lines.
Also the fix adapts [this commit](https://github.com/odoo/odoo/commit/bc30d2592d4a7913eddf30bac8be2d94b6c22ad4) to work with the [website refactoring](https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2)

opw-5412775

Forward-Port-Of: odoo/odoo#249195

In Chromium-based browsers, the mass_mailing theme selector attempts
to resize the mass_mailing iframe to match the size of the theme
selector wrapper. This allows the theme selector to take as much screen
space as possible while reducing unnecessary scrollbars.

However, the resizing may cause "scrollbar flickering" issues on
Chromium-based browsers, due to Chromium scrollbars taking up "physical"
width to the right of the scrollable elements. In some instances, a
scrollbar appearing causes the theme selector to scale down from the
lost width just enough that this scrollbar becomes no longer necessary,
causing the theme selector to be resized up, causing the scrollbar to
appear, which causes the theme selector to scale down...

Steps to reproduce:

- On a Chromium-based browser, try to create a new mass_mailing.
- Resize the window's height so that the bottom of the window almost
  touches the bottom of the form.

Fix:

The theme selector will no longer resize itself down if that resize were
to remove scrolling from the form, except in the following edge case:

If the difference between the ranges is larger than 20 pixels
(arbitrary value), we resize anyways, as it's a large enough difference
that it shouldn't trigger flickering.

This prevents occasional oversized empty areas under the theme selector
when a fullscreen window gets sized down

--

10156c10b09dc502a40253d64e2505e817a520bf removed the overflow: hidden; property
away from the body.o_web_client element. As a result, the convert_inline
iframe is able to affect the total height of the page when its height
is higher than the page's height, resulting in the entire page
seeming to have additional padding at the bottom. This is especially
visible when convert_inline has been used at least once, as the iframe
will have a height of 1300px.

This commit adds overflow: hidden; and position: relative; styles to
the convert_inline component div, removing them from view while still
allowing the inlining process to proceed.

Steps to reproduce:
- Create a new mailing
- Select the Events theme
- Reduce window size to below ~1000 px
- Scroll down

task-6002993

Forward-Port-Of: odoo/odoo#253673

Steps to reproduce the bug:
- Unarchive the MTO route
- Create a storable product P1:
    - Route: MTO + Manufacture
    - BoM:
        - Component: 1 unit of X1

- Create a storable product X1:
    - Component: 1 unit of C1

- Create a manufacturing order for 1 unit of P1
- Confirm the MO -> A child MO is created

- Try to cancel the MO for P1

Problem:
A traceback is triggered:
IndexError: tuple index out of range

'origin_picking': moves.picking_id[0],

Explanation:
When the parent MO is cancelled, all the moves linked to this MO are
cancelled (finished moves and raw moves). While cancelling them, an
activity of type "cancel" is logged on the pickings linked to these
moves (if any), in order to warn the user that actions may be required
on those pickings.

However, we do not check whether the moves actually have a picking
linked before logging the activity. The code directly tries to access
the first picking linked to the move, which triggers the traceback when
there is none:
https://github.com/odoo/odoo/blob/796316c341c4346152ad9610c30679f47aaa2ff8/addons/mrp/models/stock_move.py#L442

When cancelling an MO, the method `_log_manufacture_exception` is already
called and logs an exception activity on the child MO.

Bug introduced by:
https://github.com/odoo/odoo/pull/254636/changes/7c68c3dbb29eaad4e09d59ef7c86bd525969caec

Forward-Port-Of: odoo/odoo#257011

The fix introduced in https://github.com/odoo/odoo/pull/216737 can lead to "over-eager" filtering when an external email address matches a localpart (left part) alias in a input email list contains internal emails (aliases to filter) AND external email addresses (should not be filtered).

The `_find_aliases` method is used to identify internal system emails (aliases, bounces, catchalls) to prevent mail loops and ensure correct recipient filtering during notification grouping.

Before this fix, when the `mail.catchall.domain.allowed` system parameter was set, the logic for local-part aliases (where `alias_incoming_local` is True) failed to correctly associate the local part with the allowed domains. This resulted in external email addressed being returned by the system, potentially leading to incorrect notification routing.

We now use a more robust approach:
- Pre-filter local parts based on the allowed domains to reduce DB load.
- Utilize Python Sets for O(1) lookups of static and local aliases
- Explicitly validate the (local_part, domain) combo during the final filtering.

Example Scenario:
- Config: mail.catchall.domain.allowed = "test1.com,test2.com"
- Alias: "info" (alias_incoming_local=True)
- Input: ["info@test1.com", "info@test3.com"]

### Output Before Fix:
["info@test1.com", "info@test3.com"]
(The function failed to recognize info@test3.com as an external alias to be ignored based on the `mail.catchall.domain.allowed` config)

### Output After Fix:
["info@test1.com"]
(Correctly identifies the internal alias tob filtered while ignoring the external one)


OPW-5469264
OPW-5504201

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

Forward-Port-Of: odoo/odoo#257266
Forward-Port-Of: odoo/odoo#244272

Steps to reproduce:
---
- Install `Sales` module.
- Create a Sale Order.
- Add a section with products.
- Add a subsection under it with products.
- Enable `Hide Prices` on the section.
- Enable `Hide Composition` on the subsection.
- Preview the Sale Order.

Issue:
---
- Prices are still visible in the subsection (grouped view) even though `Hide Prices` is enabled on the parent section.

Root cause:
---
- The variable `show_section_total` was defined only within the main rendering block and not reused in the grouped (`t-else`) block.
- The grouped section summary (used when `collapse_composition=True`) did not respect the parent section's `collapse_prices` setting, causing prices to be displayed.

Solution:
---
- Moved `show_section_total` definition outside the main conditional block so it can be reused in both rendering paths.
- Applied `t-if="show_section_total"` to price fields in the grouped section summary to ensure consistency with the parent section's price visibility.

Before:
---
<img width="1030" height="232" alt="image" src="https://github.com/user-attachments/assets/1ac05e5e-6841-420f-909f-994690656cc0" />

After:
---
<img width="1023" height="232" alt="image" src="https://github.com/user-attachments/assets/921ae337-4d53-433a-a42b-bdc437181889" />



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

Forward-Port-Of: odoo/odoo#256447
Forward-Port-Of: odoo/odoo#255464

Delayed translation (draft version from change of main language that
needs to be updated on each modified secondary language) on website
were added or disabled with:

- 2d08f97c0778469b409fca23f2be5f5a98ce3df8 (October 2023) in 17.0 added
  the delay translation feature
- 0e0a74f8c5fc9f45311e629a76608c6c986d635d (December 2023) in 17.0
  disabled the feature
- 03a85b13b2c46ef7174123d902e95d5103031c6c (September 2025) in 19.0
  enabled the feature again

Some website editor users may not expect the behavior (eg. changing a
background image, then needing to edit all secondary language so the
drafted change is saved).

For now we have not found a satisfying way to prevent delay translation
for simple use case that should not break translations: eg. removing a
snippet, changing attributes, ...

Because if we did special case, it would then become unexpected:

- will we need to update translations
- if there was a previous change that needed translation update, then we
  do a change that would not need translation update, what should we do

So this PR for now gives the option to create a ir.config_parameter:

- key: website.disable_delay_translations
- value: 1

That would disable the delay_translations feature for all websites if
the user doesn't want the feature.

opw-5187670
opw-5240423
opw-5250497
opw-5254832
opw-5344412
opw-5347408
opw-5419427
opw-5424761
opw-5481352
opw-5892371
opw-5931549

Forward-Port-Of: odoo/odoo#257370
Forward-Port-Of: odoo/odoo#243490

Problem:
The toolbar does not open when using Cmd+Shift+Arrow to select text on macOS.

Cause:
On macOS, when the Cmd key is held down, the `keyup` event is never fired for other keys. The toolbar relies on `keyup` for Arrow keys to re-enable `onSelectionChangeActive` and trigger the toolbar update, so it never opens.

See section ("Issue 3 - keyup event put on hold for other keys"): https://web.archive.org/web/20160304022453/http://bitspushedaround.com/on-a-few-things-you-may-not-know-about-the-hellish-command-key-and-javascript-events/

Solution:
Track when an Arrow key is pressed while Cmd is held (`pendingArrowKey`) and use a `selectionchange` listener as a fallback to re-enable the toolbar. The `selectionchange` event fires reliably on macOS even when `keyup` is suppressed. A `isMouseDown` guard ensures the listener does not interfere with the existing mousedown/mouseup flow.

Steps to reproduce:
1- Type some text
2- Use Cmd+Shift+Arrow (left or right) to select text 3- Observe the toolbar does not appear

task-6013408

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

Forward-Port-Of: odoo/odoo#257166
Forward-Port-Of: odoo/odoo#253293

### Steps to reproduce:
- Download Payroll app
- From the top bar 'Employees' > 'Employees', create a new employee
- Select the created employee > click 'Work Entries' smart button, add 2 Attendance work entries on different days, with different creation days (either wait 24h between creations, or adjust one create_date in DB)
- Click on any day, you'll find the "Replace by Attendance" smart button replicated

> If you activate debug mode and click on any cell > **UncaughtPromiseError > OwlError**

### Cause of issue:
https://github.com/odoo/odoo/blob/72be98d705e225f663b65e289e11d0b8642ec6f8/addons/hr_work_entry/static/src/views/work_entry_calendar/work_entry_calendar_model.js#L30-L58 `formattedReadGroup` is called with both `work_entry_type_id` and `create_date:day`. If the user has created several work entries of the same type on different days, we would get multiple group results having the same `work_entry_type_id`. These duplicated records later produce an Owl crash because the button list uses `t-key="workEntry.id"`. https://github.com/odoo/odoo/blob/72be98d705e225f663b65e289e11d0b8642ec6f8/addons/hr_work_entry/static/src/views/work_entry_calendar/work_entry_multi_selection_buttons.xml#L16-L17

### Fix:
Since the goal of the above method is to extract the favorite work entries to later use in smart buttons and `userFavoritesWorkEntriesIds.map((r) => r.work_entry_type_id?.[0]).filter(Boolean)` extracts all the entries' `work_entry_type_id` (including duplicates), the easiest way to get rid of these duplicates is to create a `Set`.

opw-5953671

Forward-Port-Of: odoo/odoo#253387
Forward-Port-Of: odoo/odoo#252478