**Problem:**
Opening a Project Update activity from the activity menu (the clock icon in the systray) lists every project update of every user, instead of the ones carrying the current user's activities.

**Steps to reproduce:**
1. Schedule an overdue activity on a project update
2. Have a colleague create another project update with no activity
3. Click the clock icon in the systray
4. Under "Project Update", click the "Late" count

**Current behavior:**
The list opens unfiltered and shows all project updates, including the ones of other users and the ones carrying no activity at all.

**Expected behavior:**
The list shows only the updates carrying the user's own activities, restricted to the bucket that was clicked.

**Cause of the issue:**
The activity menu never builds a "my activities" domain. `openActivityGroup` in `mail/static/src/core/web/activity_menu.js` narrows the generic act_window it opens purely through context keys — `search_default_filter_activities_my` plus `search_default_activities_overdue` / `_today` / `_upcoming_all` — and the only domain it forwards comes from `_get_activity_groups`, which is limited to `[('active', 'in', [True, False])]`. A `search_default_<name>` key is resolved against a filter of that name in the model's search view, and is silently dropped when no such filter exists. `project.update`'s search view never declared them, so every key the menu sends is discarded and the action opens on an empty domain.

**Fix:**
`project.project` and `project.task` — the addon's two other `mail.activity.mixin` models — already declare this block of invisible activity filters, as does every other model reachable from the activity menu. Declaring them on `project.update` is what makes the menu's context keys resolvable, and keeps the model consistent with the rest of the codebase instead of special-casing `project.update` on the client side.

opw-6416397

Problem:
When applying color on a selection that spans across partially selected inline elements (e.g. `<p><b>a[b</b>c]d</p>`), container elements whose contents are not fully selected (such as `<b>`) were included in `targetedNodes`. This caused improper color formatting/nesting on partially selected elements.

Cause:
In `ColorPlugin._applyColor()`, `targetedNodes` were filtered by checking `isNodeEditable(node)` and `nodeName !== "T"`, but did not check whether the contents of `node` were fully selected (`areNodeContentsFullySelected(node)`). As a result, partially selected ancestor elements were included in `targetedNodes`.

Solution:
Filter `targetedNodes` in `_applyColor()` using
`this.dependencies.selection.areNodeContentsFullySelected(node)` to ensure only fully selected nodes are targeted when applying colors.

Steps to reproduce:
1. Open html_editor.
2. Insert content: `<p><b>ab</b>cd</p>`.
3. Select `b` inside `<b>` and `c` inside `<p>` (`<p><b>a[b</b>c]d</p>`).
4. Apply text color (e.g. red).
5. Observe "ab" and "c" was colored instead of just "b" and "c".

task-6456443

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

Forward-Port-Of: odoo/odoo#285337
Forward-Port-Of: odoo/odoo#281462

The search order on account move line depends on date, move name and id.
This search result order can be non deterministic because,
when creating account move line from stock valuation, it depends on the order from a set, but sets are unordered.

**Step to reproduce**
Run [test_subcontracting_purchase_bill](https://github.com/odoo/odoo/blob/13b2781978b0edad0df0800404276919b767e32b/addons/mrp_subcontracting_purchase/tests/test_mrp_subcontracting_purchase.py#L268) in:
Single app, community, with demo data.

**Observation**
* The search:
When doing the search since we didn't specify any order,
the search from account.move.line will ordered by:
https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/account/models/account_move_line.py#L23
https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/account/models/account_move_line.py#L1664
Since, for the components the date and move name are the same it will only depend on the aml ids:

* `Account.move.line` creation:
When it validate the receipt (`button_validate`)
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/mrp_subcontracting_purchase/tests/test_mrp_subcontracting_purchase.py#L296

It will mark as done the picking (`_action_done`) and the productions (`button_mark_done`) linked to this picking.
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/stock/models/stock_picking.py#L1429
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/mrp_subcontracting/models/stock_picking.py#L49
Modify the inventory accordingly (`_post_inventory`)
https://github.com/odoo/odoo/blob/869c750f978b1b00a4a04bd61226f0e20d2e7729/addons/mrp/models/mrp_production.py#L2231
while inside of `_post_inventory`, it will process all the production moves, for this it will divided them in set to process them by batch:
https://github.com/odoo/odoo/blob/f0e58b9324af18d0cf0264aec2886d098e997f03/addons/mrp/models/mrp_production.py#L1904-L1911

From this set, it will create the `account.move.line`:
It retrieve the actual stock move with the browse, and call `_action_done`, from where the stock valuation layer will create the `account.move.line`.
https://github.com/odoo/odoo/blob/f0e58b9324af18d0cf0264aec2886d098e997f03/addons/mrp/models/mrp_production.py#L1913
https://github.com/odoo/odoo/blob/f0e58b9324af18d0cf0264aec2886d098e997f03/addons/stock_account/models/stock_move.py#L187
The issue arise because a set read order is non deterministic.

runbot-939794

### Issue:
A warning `IndexError: tuple index out of range` is logged on RunBot when upgrading from 18.0 to 19.0 for employees without any version

### Cause:
`_get_version` on `hr.employee` falls back to `versions[0]` when no version matches the given date
But if the employee has no versions at all, `versions` is empty and `versions[0]` raises an `IndexError`

### Steps to reproduce:
-  Create a database with `hr_attendance` installed in 18.0
- Upgrade to 19.0

Before the fix, a warning is logged during the upgrade

### Notes:
An employee without any version is a transient state during upgrade
`hr/saas~18.4.1.1/end-migrate.py` backfills a version for every employee still missing one (`current_version_id IS NULL`) once the whole upgrade chain is done
Since it only runs at the very end, an employee can still be found without a version by earlier steps (e.g. modules reloading their demo data), which is when this warning was logged
Confirmed on an upgraded RunBot database that employees without a version before the upgrade do end up with one once fully completed

runbot-241187

Steps:
1. Turn on AvaTax for a company (connect it to Avalara).
2. In Settings > General Settings > Invoicing, set the Document Layout to Boxed (Box), just for a clear view.
3. Create a customer invoice:
   - Use the customer with an AvaTax fiscal position and proper address details.
   - Add a product with an AvaTax category.
   - Add a section line (a divider/heading row).
   - Compute Taxes for the AvaTax.
4. Print the invoice as a PDF.
5. Look at the section/divider row. Its cell border does not line up with the other rows. On longer invoices, this can also cause a big blank gap at the bottom of a page.

Cause:
When an invoice is computed by AvaTax, the Taxes column is hidden from the PDF (this is intentional, since AvaTax shows tax differently).

But a different part of the same template decides how wide the section row should be. This part does not know the Taxes column was hidden, so it still counts it. That makes the section row's width wrong by one column, which breaks the table layout in the PDF.

Fix:
Instead of hiding the Taxes column only in one place, fix it at the source: the variable that decides (does this invoice show a Taxes column) now also checks if the invoice is an AvaTax invoice. Every other part of the template that uses this variable (the header, the tax cells, and the section row width) automatically gets the right answer, since they all read from the same place.

Result:
- Section rows on AvaTax invoices now have the correct width.

opw - 6455674