The current query to delete unnecessary records from `res.device.log` must be run on all records in the table.
This means that the entire table will be placed in the psql buffer. This can degrade performance if autovacuum is very frequent.

This commit introduces a fix so that a seq scan does not have to be performed on the table to carry out the cleanup.

We can use an `USING` if the condition on the joined table (L2) significantly reduces the volume before the join.
This will avoid having the corresponding rows from the first table (L1).

Pseudo query:
```sql
DELETE FROM L1
USING L2
WHERE
    <L2_selective_filter>
    AND L1.<device> = L2.<device>
    AND L1.last_activity < L2.last_activity
```

If `<L2_selective_filter>` is very selective, PostgreSQL will use L2 as the "base" table for the join.
PostgreSQL will therefore not place the entire table in the buffer.

With:
```
d: device
c: cron
t: time
```
```
d t1 - insert
d t2 - insert
d t3 - insert

c t4 - cleanup (delete d t1 and d t2)

d t3
d t5 - insert
d t6 - insert

c t7 - cleanup (delete d t3 and d t5)

d t6
d t8 - insert

c t9 - cleanup (delete d t6)

d t8

c t10 - cleanup

d t8
...
```
In the example, cron t9 cannot look at the time window between the moment it runs and the last cron t7. The proof is that the device inserted in t6 must be deleted because a device t8 has been inserted.

It is not possible to cleanup between two crons because older lines can still be deleted by a later cron if a more recent line has been inserted after the previous cron.

So if a device is inserted between the time of the current cron (t0) and the previous cron (t-x), it is necessary to scan the entire table to cleanup the previous devices.
Therefore, it is possible to create a filter so that devices for which there has been no new insertion in the table between the two crons (t0 and t-x) do not need to be checked.

Pseudo query becomes:
```sql
DELETE FROM L1
USING L2
WHERE
    L2.last_activity >= <last_cron_time>
    AND L1.<device> = L2.<device>
    AND L1.last_activity < L2.last_activity
```

Task-5951999

Forward-Port-Of: odoo/odoo#263625
Forward-Port-Of: odoo/odoo#249738

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/7fa6ba6291 [REL] 19.2.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4ddf97f4ca [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/958ae7d17c [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5ec347d6eb [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/a939d63d5c [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/31baa52ff4 [FIX] composer: remove forced reflow in content editable [Task: 6199661](https://www.odoo.com/odoo/2328/tasks/6199661)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Problem:**
The "Custom Dates" and "Specific Date" comparison options are missing from the Comparison dropdown in accounting reports.

**Steps to reproduce:**
1. Go to Accounting > Reporting > Profit & Loss
2. Click the Comparison dropdown
3. Only "No Comparison", "Previous Period", and "Same Period Last Year" are visible — "Custom Dates" is missing

**Current behavior:**
Custom date comparison options are not rendered.

**Expected behavior:**
"Custom Dates" (for range reports) and "Specific Date" (for single date reports) should appear in the Comparison dropdown.

**Cause of the issue:**
The date filter refactor (40484f985f5) restructured how the date mode is stored in options. Previously, `options.date.mode` held 'range' or 'single'. After the refactor, this key no longer exists — the mode is now stored as a boolean in `options.filter_date.range_mode`.

The comparison filter template still checks
`controller.cachedFilterOptions.date.mode`, which is now undefined, so both the range and single conditions always evaluate to false and the custom comparison options are never rendered.

**Fix:**
The comparison template was the only consumer not updated during the refactor. Aligning it to the new data path restores the options without any behavioral change.

opw-6070402

Steps to Reproduce
---
- Assign a flexible working schedule to an employee (no leaves)
- Open Project > Tasks > Gantt view grouped by Assignee
- The employee's weekends and off-hours are grayed out

Current Behavior
---
Flex employees with no approved leaves in the viewed date range have incorrect grayed-out days in the Project Gantt view.

Expected Behavior
---
Flex employees should have no grayed-out days except approved leaves and public holidays.

Issue
---
When a flex employee has no leaves in the viewed period, `_get_unavailable_intervals()` returns an empty dict for that resource. `_gantt_unavailability()` then falls back to `company_leaves`, producing incorrect gray intervals. The same case is already handled in `planning` (ref PR), but `project_enterprise` was not covered.

Fix
---
Add a guard in `_gantt_unavailability()` to return no unavailabilities for flexible resources absent from `leaves_mapping`.

Related : https://github.com/odoo/odoo/commit/5f1cd39944134ffa2c30c331f8a5daca56446d78 
task - 5063071

Forward-Port-Of: odoo/enterprise#113247

Before this commit, when right-clicking on a link in a message of type email, this shows the message actions rather than the browser context menu.

We expect to display the browser context menu, as there are many handful feature of browser context menu for links. This was handled in earlier fixes [1][2], but these fixes were not working with messages of type email.

This didn't work because messages of type email are inside a shadow DOM, so `ev.target` is necessarily the shadow root and not the specific targeted element. This commit fixes the issue by using `ev.composedPath()` to pick the 1st element, so that this exposes the inner-most element inside the shadow DOM that has been right-clicked. This lets us ignore the showing of message actions in right-click when this comes from a link.

opw-6110949

[1]: https://github.com/odoo/odoo/pull/244252
[2]: https://github.com/odoo/odoo/pull/258681

Before / After

<img width="441" height="243" alt="before" src="https://github.com/user-attachments/assets/f274e8d2-66af-442e-9a31-27ea1ce4d9bd" />
<img width="605" height="513" alt="after" src="https://github.com/user-attachments/assets/3e241e83-93d0-47e6-970c-b5e5f339417d" />

Forward-Port-Of: odoo/odoo#263622

## Issue
When opening the *Hierarchy* view of Employees > Departments, if at least one department has a manager set, a traceback appears before the view.

## Steps to reproduce
1. Install *Employees* (`hr`)
2. In Employees > Departments, add a manager to a department
3. Open the *Hierarchy* view
4. **A traceback appears:**

```
Caused by: TypeError: Cannot read properties of undefined (reading 'toMillis')
    at get uniqueId (http://localhost:8192/web/assets/cbd2032/web.assets_web.min.js:21370:74)
    at Many2OneAvatarEmployeeField.template (eval at compile (http://localhost:8192/web/assets/cbd2032/web.assets_web.min.js:1387:421), <anonymous>:25:122)
...
```

## Cause
The traceback is yielded from the `get uniqueId` getter from the `Many2OneAvatarEmployeeField` component:

https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/hr/static/src/views/fields/many2one_avatar_employee_field/many2one_avatar_employee_field.js#L38-L40

where `write_date` is undefined. This getter was added by https://github.com/odoo/odoo/commit/3732ca85b03bea9eabfb05cc306ce0bf5bac88d4, which handled the case of undefined `write_date` for the related Kanban component:

https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/hr/static/src/views/fields/many2one_avatar_employee_field/kanban_many2one_avatar_employee_field.js#L49-L52

A similar solution is applied in this problematic getter.

opw-6128837

**Description of the problem**
Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the backspace behavior would be incorrect, because the cursor would move across a zero-width non-breaking space (Zwnbsp) without deleting the first character to the left.

**How to reproduce**
In the `html_editor`, create a button. Click on its very left edge, then press backspace. An error is thrown.

**Why the problem happens**
1. Traceback when backspace is pressed
`LinkPlugin.handleDeleteBackward` assumes that `previousSibling` is an element node, and calls the `matches` method. However, when clicking on the very left edge of a button, the cursor is positioned such that the left sibling (`previousSibling`) is a text node. Text nodes do not implement `.matches()`, leading to the crash.
2. No deletion of the character to the left of the cursor
`DeletePlugin.isVisibleChar` handles the edge cases where backspace is pressed while the cursor is positioned to the side of a button, and defines the visibility of Zwnbsp to determine how much is deleted. The padding Zwnbsp to the left of a button are considered as visible, such that the user can delete an empty button without removing also the first character on its left. Anyway, the current code does not actually check if the button is empty, thus it applies to more cases than necessary. Probably this has never been observed before, because it takes a very precise click to the left edge to position the cursor between a button and its left Zwnbsp.

**Fix**
1. Prevent the crash in `LinkPlugin`
`LinkPlugin.handleDeleteBackward` now ensures that `previousSibling` is an element node before calling `matches`, otherwise it returns.
2. Fix backspace behavior in `DeletePlugin`
`deletePlugin.isVisibleChar` now considers as visible only the Zwnbsp positioned to the left of an empty button. This way, if the user clicks on the very left edge of a button (which moves the cursor outside the button, to the left), pressing backspace actually deletes the character on the left.

task-6102282

Forward-Port-Of: odoo/odoo#258858

#### Issue:
Clicking `Unassign` from the stock reception report could raise a traceback
when the outgoing move source document was empty.
``ValueError: Expected singleton: mrp.production()``

Please note that this is not expected in standard Odoo, where reception report moves
should normally be linked to a source document, such as an MO, SO, or picking.

This case seems specific to the client database and may be due to a customization, but handling it makes the reception report more robust.
#### Cause:
The reception report built report lines from `source = (move._get_source_document(),)`
and checked `if not source`. Since the tuple itself is truthy, moves whose
`_get_source_document()` returned an empty recordset were not filtered out.

For example if `out_move._get_source_document()` returns `mrp.production()`, then
`source = (mrp.production(),)` is still truthy, so the report keeps the line
even though the source document is empty.

later `action_unassign()` called `_remove_reference()` on that empty source
document, which crashed on `ensure_one()`.

#### Fix:
Added a helper function that skips moves where `_get_source_document()` is empty.
Also skip reference synchronization in `_action_assign()` and `_action_unassign()`
when the source document is empty just for more protection.

opw-6174870

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

Forward-Port-Of: odoo/odoo#263366

Steps to see the issue:
- Add a shape to an image
- Remove it

=> Image element in the DOM still has some data related to the shape.
This commits adds a shared method to `ImageShapeOptionPlugin` to clean
shape-related data when we apply a shape, or remove it, the method
mirrors the behavior we had before the [html builder refactoring].

Also, commit [1] fixed the issue when the builder transfered shape or
hover related data to incompatible images, when replacing an image with
a shape/hover on it. However if these data attributes had already been
saved prior to that commit, it would stay there indefinitely. The same
could happen with hover effects attributes. Therefore, we add a
resource that we call before saving data to clean any stale image data.

Example of a CORS protected image: [2]

[1]: https://github.com/odoo-dev/odoo/commit/137a6d7e59e1d788745c3b796a14839e52a8c5bc
[2]: https://tinyjpg.com/images/social/website.jpg

[html builder refactoring]: github.com/odoo/odoo/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5172640

Forward-Port-Of: odoo/odoo#263662
Forward-Port-Of: odoo/odoo#259226