Steps to reproduce:
--------------------------
1. Install l10n_ch_hr_payroll_elm_transmission.
2. Switch to a Swiss company.
3. Create an employee and create a user with HR rights but without Payroll rights.
4. Log in with this new user.
5. Update any value on the employee form (e.g., marital status or add a tag).

Issue:
-----------
Updating the employee raises the following error:
```python
You do not have enough rights to access the fields "slip_ids" on Employee (hr.employee). Please contact your system administrator.

Operation: read
User: 2
Fields:
- slip_ids (allowed for groups 'Payroll / Officer: Manage all contracts')
```

Cause:
---------
After this 4416eda, open payslips are recomputed automatically on every employee update:
https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/l10n_ch_hr_payroll_elm_transmission/models/hr_employee.py#L210-L213
`slip_ids` is restricted to payroll users:
https://github.com/odoo/enterprise/blob/8f7a43eebdc8f7f46f9d61ab7084e036c20f778e/hr_payroll/models/hr_employee.py#L14 As a result, when an HR user without payroll rights updates an employee,
accessing slip_ids raises an **AccessError**.

Solution:
-----------
Use sudo() when accessing slip_ids so HR users can update employee records 
without issue.

**NOTE:**
The issue has been resolved from version saas~18.4 with the following commits:
279f09a9587674c035c514f966788a4dddfe9794 and  75d66d8

opw-6210358

Forward-Port-Of: odoo/enterprise#120019
Forward-Port-Of: odoo/enterprise#117387

Libmagic version 0.46 (currently available in Debian Trixie/Forky and Ubuntu Resolute) introduced a regression regarding ZIP file detection. While it correctly identifies a ZIP file when reading directly from a file path, it fails when reading the exact same content from a buffer, returning a generic 'application/octet-stream' instead.

Because `guess_mimetype` primarily evaluates buffers, this upstream bug breaks MIME type detection for ZIP files (and related formats like docx, xlsx, etc.) in Odoo environments running this libmagic version.

Since we cannot directly fix the library itself, this commit adapts Odoo's `guess_mimetype` to fallback to our custom implementation when libmagic returns the generic 'application/octet-stream' to workaround this library's bug.

Upstream libmagic fixes:
- https://github.com/file/file/commit/f1adef05b8a85be50d28965b1fd21fcceacf7a4e
- https://github.com/file/file/commit/60b2032b96fc185b37fb0f2152e834efb2edad6e

Upstream python-magic issue:
- https://github.com/ahupp/python-magic/issues/354

runbot-938197

Forward-Port-Of: odoo/odoo#269506

Problem:
- `s_three_columns` is not rendered correctly in Outlook Desktop when the equal-height option is enabled.
- Button padding, border radius, and background color are not rendered properly in Outlook Desktop.

Solution:
- Set the `height` attribute on `td.card-body` along with `valign` so columns keep the same height in Outlook Desktop.
- Use `v:roundrect` to support rounded corners (`arcsize`) and background colors (`fillcolor`), making buttons render consistently with the editor in Outlook Desktop.

Before:
<img width="1249" height="1297" alt="image" src="https://github.com/user-attachments/assets/828bc42b-1e21-404c-a5ae-81d4ee688802" />
After:
<img width="1249" height="1309" alt="image" src="https://github.com/user-attachments/assets/263a1c30-fe86-4e40-b3c2-476abc2bf84a" />

Steps to reproduce:
- Add the `s_three_columns` snippet with one card containing more content than the others.
- Add some buttons.
- Send or preview the email in Outlook Desktop.
- Observe that column heights and button styling are not rendered correctly.

opw-6044725

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

Forward-Port-Of: odoo/odoo#269791
Forward-Port-Of: odoo/odoo#269274

**Steps to reproduce:**

- Enable "Track orders edits" in the settings
- Enable "Log in with Employees"
- Go to the Restaurant, log in with employee A
- Go to a table, order 3 Sushis
- Go back to the floor plan and change to employee B
- Go back to the table and change the qty of 3 Sushis to 2 Sushis
- Go to the order in the backend and check the chatter
- It will indicate that employee A did the change, but it was employee B

**Why the fix:**

We always used the cashier set on the order to determine who should be put in the chatter, regardless of who is actually connected at that point.

We now use the session's current employee to write who did the change in the chatter.

We do not change the order's employee, because it will be done once the order has been paid.

In the case where we are not logged in but pos_hr is installed, the employee_id might be the id of a res.user, and
browsing it might return the wrong value. To avoid this, we check if the value exists as a hr.employee before assigning the name.

The way we return the value has been changed because the linter wasn't happy about it.

opw-6213504

**Problem:**
On the /shop page, the "Fill" option in the web editor (cover/contain toggle on product card images) appears clickable but has no visible effect on the product thumbnails.

**Steps to reproduce:**
1. Install website_sale and open /shop.
2. Open the web editor and select the shop page.
3. Locate the "Fill" button group in the right panel (with the two svg icons).
4. Click the alternate option to switch between cover and contain.
5. Observe that the product card thumbnails do not change appearance.

**Current behavior:**
The toggle flips the `o_wsale_context_thumb_cover` class on the products table (and the activation of the `products_thumb_cover` view), but the product images keep rendering with `object-fit: contain` regardless of the toggle state.

**Expected behavior:**
The image fill mode follows the toggle:
- "cover" option active   → product image uses `object-fit: cover`
- "cover" option inactive → product image uses `object-fit: contain`

**Cause of the issue:**
The product image template renders the img with the `object-fit-contain` utility class, and the local SCSS rule declares
`.object-fit-contain { object-fit: contain !important; }`. The CSS variable `--o-wsale-card-thumb-fill-mode` (set to `cover` by `.o_wsale_context_thumb_cover`) does cascade down to the img, but the non-variable, `!important` rule on the utility class always wins, so the variable-driven rule
`object-fit: var(--o-wsale-card-thumb-fill-mode, contain)` is silently overridden and the toggle becomes inert.

**Fix:**
Making the `.object-fit-contain` rule read the same CSS variable lets the existing toggle mechanism take effect without changing any template or removing the utility class. Outside the `.o_wsale_context_thumb_cover` context the variable is undefined, so the `var(..., contain)` fallback preserves the prior `contain` behavior for any other consumer of the class. This keeps the change to a single SCSS line, with no XML touched and no other CSS class semantics altered.

opw-6231432

Forward-Port-Of: odoo/odoo#268302
Forward-Port-Of: odoo/odoo#266717

PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index.

The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is started with the `--unaccent` flag during database creation.
However, it is also possible to start `odoo-bin` with an existing database where the `unaccent` extension is already installed, but the function was never marked as `IMMUTABLE`.

In that case, `unaccent` can still be used in conditions such as `WHERE` clauses, but it cannot be used in functional indexes.

`has_unaccent()` actually has three possible states:
```py
class FunctionStatus(IntEnum):
    MISSING = 0    # function is not present (falsy)
    PRESENT = 1    # function is present but not indexable (not immutable)
    INDEXABLE = 2  # function is present and indexable (immutable)
```
Therefore, checking only `if has_unaccent()` before creating an index using `unaccent` is not enough. The index should only be created when `has_unaccent()` returns `FunctionStatus.INDEXABLE`.

task-6307060

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

### Steps to reproduce:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120051