### Issue:
Given a specific configuration, the `SwitchCompanyMenu` will not display all the companies a user can access. Suppose we have a company hierarchy with the following: `Company 1 > Company 2 > Company 3` (where 2 is a branch of 1, and 3 is a branch of 2). If a user has access to C1 and C3, but not C2, the menu selector will only display C1, rather than a hierarchy of all 3 companies with C2 disabled.

This menu has been improved between versions, but the logic behind how we determine which companies to display remains consistent. We loop over each root company from `companyService.allowedCompaniesWithAncestors`, add it, and then add its children. Depending on whether the child company is accessible, it will be disabled (but still displayed) in the hierarchy list.

`companyService` pulls its company information from the `session['user_companies']` dict that is created from `session_info`. For each of the `allowed_companies`, we build the `child_ids` from the intersection of each `user.company_id.child_ids` and `user.company_ids`. So we only add the child if it itself is an allowed company, which C2 would not be. C1 is now considered a root company with no children in our loop, so C2 is skipped. C2 isn't a root company either, so it will never be seen, and therefore neither will C3.

### Solution:
A similar case was addressed in #138942, where given the same company hierarchy as above, the user instead has access to C2 and C3, but not C1. This PR adjusted how we build the `child_ids` for `disallowed_ancestor_companies` (C1 in this case), properly setting the children for us to loop through. We can use this same logic for the `child_ids` of `allowed_companies`, ensuring we can properly loop through the disallowed children of allowed companies.  Additionally, we need to adapt the `CompanySelector` component, which previously grabbed all children even if they were disallowed.

opw-4880477

Forward-Port-Of: odoo/odoo#228438
Forward-Port-Of: odoo/odoo#217001

Problem:
Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`).

Cause:
In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the referenced sibling was connected to the live DOM (`.isConnected`).
When that check failed, the fallback was `parent.append()`. On some Firefox versions, mutation events list the parent removal *after* its children’s, meaning the parent is reinserted first while the children’s siblings still exist but are detached. Because `.isConnected` returned false, the fallback `append()` misplaced nodes and broke the order.

Example (processed in reverse order):
```js
[
  { type: 'remove', id: 'p', parentId: 'root', node: { tagName: 'P' } },
  { type: 'remove', id: 'b1', parentId: 'p', nextId: 'b2',
    node: { textValue: 'b' } },
  { type: 'add', id: 'b1', append: 'x', node: { textValue: 'b' } },
  { type: 'remove', id: 'c1', parentId: 'p', node: { textValue: 'c' } },
  { type: 'add', id: 'c1', append: 'x', node: { textValue: 'c' } },
]
```
During revert:
- Child removals (b1, c1) are processed first.
- Their sibling nodes exist but are detached → .isConnected false.
- Fallback append() used → "b" inserted after "c" → acb.
- `<p>` restored last with children in wrong order.

Solution:
Remove the `.isConnected` condition.
`before()` and `after()` work even on detached nodes, preserving the original child order regardless of browser mutation sequence.

Steps to reproduce:
- Open todo.
- Have this:
```html
<p>a[]</p>
<p>b<br>c</p>
```
- Press Delete.
- Observe "b" and "c" are not in the right order.

opw-5139795

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

Forward-Port-Of: odoo/odoo#233582

On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items.

### Steps to reproduce:

On a small screen size (Zebra scanner, Iphone 4,..)
* Open barcode app
* Go on  Operations -> Receipts
* Apply a filter so that the list becomes empty. 
-> the image is over the barcode button and the text.

### Observation:

Our image (in div .o_view_nocontent) has position absolute, anchoring it to the top part of the screen where the search bar is located (in div .o_control_panel). The issue is that in barcode there is another element where the button to scan is located (o_kanban_tip_filter), and since the image is absolutely positioned relative to the top rather than this element, it ends up overlapping the button and the text, preventing interaction.

### Why the fix:

The solution we chose is to change the position of the image to relative, for the image to not hide the text. Another possible solution was to make the image (more specifically .o_view_nocontent .o_nocontent_help) ignore all input, allowing them to go through the image and reach the button below.

opw-5123880

Forward-Port-Of: odoo/enterprise#98243

Steps to reproduce the current behaviour:

- Update the DEMO user to be a website "restricted editor" and sales
"admin" who cannot bypass HTML field sanitization.

- As ADMIN, add a YouTube video to a product page > Save.

- As DEMO, try to update the content on the product page > You cannot
(a dialog informs you that you cannot edit the content because an admin
edited it previously).

Explanation:

Starting from [1], an HTML field can be flagged as `sanitize_overridable`
which allowed users with the `base.group_sanitize_override` group to
skip the HTML field sanitize process.

If such users added some content that is not considered "sanitize
friendly" (e.g. YouTube iframe), a restricted user won't be allowed to
add content in the fields, since the sanitizer will remove the original
content from the DOM.

For this case, the code from [2] added an implementation to consider the
field as none editable and warn the user once he tries to update it.

Implementation:

The goal of this commit it to fix the current limitation for video
upload that currently prevents non admin users to edit a website record
once an admin adds a video on it...

The idea of the fix is the following:

- We already have a technical fallback when uploading a video to save
the iframe `src` to an attribute: `data-oe-expression`.
- The public widget is now destroying the video iframes so they are
never saved in the DOM.
- A non-lazy code will build the iframes immediately on page load.
- The public widget can always create the iframes if they are not
already created (for compatibility).

[1]: https://github.com/odoo/odoo/commit/cf844e34dd0ce4830eb99fd0fa5b6b9cb58c867c
[2]: https://github.com/odoo/odoo/commit/cb80c15d3db49ede3c93171abcaa9064b88822c6

task-3757205

Forward-Port-Of: odoo/odoo#232871
Forward-Port-Of: odoo/odoo#175717

Previously, `position: static` was added on `.o_form_sheet` in modal 
forms to fix an issue where the ribbon looked ugly (not pinned to the 
top right) due to the absence of borders in modals. See commit: https://github.com/odoo/odoo/commit/1ac2ff5b7dd64ccfe1bfb9c3fb7bb8a758e887d7

However, when a statusbar is present, this rule caused the ribbon to 
merge into the statusbar, making its display worse.

In addition, on scrolling in a modal, the statusbar and
the form contents were getting merged.

This commit refines :
- the selector so that `position: static` is only
applied when a modal form has a ribbon but no statusbar. When a
statusbar exists, the ribbon remains visually separated from the
statusbar.
- the statusbar background-color logic so that inside modals
it uses the proper `$o-view-background-color`, ensuring a
clean separation even on scrolling.

task-4873636

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

Forward-Port-Of: odoo/odoo#226074