**Issue:**

Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself.

**Cause:**

The security rules for approvers (`timesheet_line_rule_approver` and `timesheet_analysis_report_approver`) only check project-level follower access and ignore task-level access.
https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76

https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L108-L117

**Steps to reproduce:**

1. Create a private project (`privacy_visibility == 'followers'`)
2. Give another user (e.g., Marc Demo) "All Timesheets" rights and only "User" project access
3. Add Marc Demo as a follower of a task in that private project
4. Have another user log time on that task
5. Log in as Marc Demo

Marc cannot see the other user's timesheets, neither on the task form nor in reporting.

opw-5022877

Forward-Port-Of: odoo/odoo#224025

This is a cleaning pass after the `mass_mailing` [refactoring].

### Stop using `web.assets_frontend` for mailings

For multiple reasons:
- loading this bundle implied that all frontend JS and SCSS were loaded for a
  mailing, while the mailing actually only uses css, and only a fraction of it.
- this bundle is crowded with assets from all modules that are totally
  irrelevant to `mass_mailing`. i.e. not loading it prevents issues where
  `website` (or any other module) style assets modified `mass_mailing` assets in
  a way that was not desirable.

This will drastically improve loading time when starting a new mailing for the
first time, and will also speed up the `convert_inline` process since a lot less
style rules need to be parsed.

This implies that the `snippets preview dialog` can no longer load
`web.assets_frontend` by default. Instead a resource was introduced for each
module to introduce their own previewing assets through a plugin.

### Improve UX for an empty mailing

Ensure that a user typing directly in the `o_editable` element will not result
in a corrupted content, and that the UX for an empty email hints at the user
what to do.

This results in a better experience when a user uses the `empty theme` for a new
mailing.

### Fix snippets
- clean snippets options (remove duplicates, redundant, ineffective
options).
- ensure that no editable phrasing content sits next to flow content (which is
  not well supported in the editor).
- ensure that style assets for snippets correctly use the `mass_mailing` bundle.
- ensure that snippets use the proper technical classes.
- ensure that when `col-x` is specified, `col-md-y` is specified too, to avoid
  bumps in the interface when the user tries to redimension columns.

[refactoring]: https://github.com/odoo/odoo/commit/82969dc5c6c36a7a91194cf15b33c9abb560a8e7

task-5078825

Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Thomas Josse <thjo@odoo.com>

When changing the expense policy of an expense product, the
compute of analytic distribution of all expenses linked to the product
is triggered.

Steps:

- Have an expense product X with expense policy 'at_sales'
- Create several expenses with an expense product X and  any analytic account
- Create an analytic distribution model that link the expense account of
  X with a specific analytic account AA
- Create a new expense for product X, the analytic account AA should be set
  from the distribution model
- Go to the form view of product x and change the expense policy to
  'cost'
- Go back to the expense list view
-> All expenses having the product X have the AA account

Cause:

`sale_order_id` has been added to the `depends` of `hr_expense._compute_analytic_distribution`
by 2b3bf5e0fe31d4b4ef6b487da493657f695b14e1 but this wrong since we have
the `sale_expense._onchange_sale_order_id` that add the
`analytic_dostribution` field to the fields to be computed.
The compute is triggered since we change `product_id.expense_policy`,
which triggers the `_compute_can_be_reinvoiced` which triggers
the `_compute_sale_order_id`

Fix:

With this commit, we emove the depends on the compute and we also adapt
`test_compute_analytic_distribution_expense` in a way that it triggers the onchange
as we do in the original flow.

opw-4998899

Forward-Port-Of: odoo/odoo#226864
Forward-Port-Of: odoo/odoo#224226