[FIX] *: fix some side-effects of https://github.com/odoo/odoo/commit/9de1bc0eef6f5bfaa2a8d745431caa361ae91548

- JS Modals were not correctly built anymore, their .modal-body element
  was duplicated and many without-effect JS lines were introduced (as a
  side effect, the form view design was broken when inside modals)

- Tests were changed to make bugs go unnoticed. For example, the media
  dialog functionnality was entirely broken because the .modal-dialog
  element was not receiving the correct class anymore.

- The JS translation function is _t, not _

- Do not use the <title/> tag as a regular DOM element, it is meant to
  be unique, in the <head/> section

- CSS rules were added to the utils.scss file, which is meant to contain
  functions and mixins, otherwise, the rule is duplicated in every asset

- Some icons were still broken, as missed by https://github.com/odoo/odoo/commit/f90cf060a3cfeb37a67bec83264c0aaab8892b56

- Tests were changed to use [role="dialog"]/footer/header in their
  selectors without any reason, this commit restores some of that to
  avoid rebase conflicts with the BS4 work.

- ...

Note: other elements should still be discussed, like the direct use of
the 'o_form_label' class in views definition... but those do not cause
direct problems.

This field is somewhat generic, as anyone could want to specify it and as it is used by several batch payment methods. It is thus now factorized in the core module.
Enterprise module 'hr_expense_sepa' is thus not needed anymore as its code can be put in hr_expense

Was part of task 33323
Was PR #25562

In the filters menus, the order of groups of filters comming
from the search view arch was not always preserved in the filters menu.
This commit fixes that situation.

forward-port of @4094f755

This commit fixes many synchronization problems between search view bar
and the filters and groupby menus.

forward-port of @94c027ef

This commit allow to create easily a range of periods (related to a field
of date or datetime type) to select in the filters menu.

Two new attributes on elements with tag 'filter' are now usable
in combination in a search view arch:

- date: string.

		A valid field name with associated type date or datetime

- default_period: string (optional).

		To choose in the following list:
			- 'today'
			- 'this_week'
			- 'this_month' (default)
			- 'this_quarter'
			- 'this_year'
			- 'yesterday'
			- 'last_week'
			- 'last_month'
			- 'last_quarter'
			- 'last_year'
			- 'last_7_days'
			- 'last_30_days'
			- 'last_365_days'

Example:

<filter string="Creation Date" name="period_generator" date="create_date" default_period="this_quarter"/>

Note: the attribute 'domain' can not be used for such filters.
The generated domains are dynamic and can be saved as such
via the favorites menu.

task-10532

It is now possible to easily filter data using periods of time
(e.g. Creation Date: This Week). This adds greater flexibility to the search
view and has made some old filters become useless. In this commit, we alter
the search views in order to profit of the new framework possibilities.

This commit allow to create easily a range of periods (related to a field
of date or datetime type) to select in the filters menu.

Two new attributes on elements with tag 'filter' are now usable
in combination in a search view arch:

- date: string.

		A valid field name with associated type date or datetime

- default_period: string (optional).

		To choose in the following list:
			- 'today'
			- 'this_week'
			- 'this_month' (default)
			- 'this_quarter'
			- 'this_year'
			- 'yesterday'
			- 'last_week'
			- 'last_month'
			- 'last_quarter'
			- 'last_year'
			- 'last_7_days'
			- 'last_30_days'
			- 'last_365_days'

Example:

<filter string="Creation Date" name="period_generator" date="create_date" default_period="this_quarter"/>

Note: the attribute 'domain' can not be used for such filters.
The generated domains are dynamic and can be saved as such
via the favorites menu.

In this commit, we implement a function which allow to combine
a list of domains into a single normalized using a 'OR' or an
'AND' operator.
We also refactor slightly py_utils.

In this commit, we implement a function which normalize a domain
represented as a py.js syntax tree.

In this commit, we implement a function which format a py.js abstract
syntax tree into a string.  This is really useful whenever we need to
manipulate python expressions.

The pyeval name is quite confusing, given that there is already an eval
and an evaluate function in py.js, and that the web.pyeval exports two
evaluate functions.

Since this file is more about odoo specific customization to py.js, it
is renamed in py_utils to better express its intended use.

Some functions that were in web.pyeval were actually "odoo independant".
To make them easier to manage/understand, this commit move them in the
library py.js, as an extra file.

Closes #25625

- Create 2 Companies A & B
- Set User B in Company B
- Record some `mail.activity` for User B on a lead belonging to Company
  B.
- With a manager user in Company A, go to Kanban view of leads and
  remove filters => all leads, including leads in Company B, are
  displayed

An access error occurs.

`read_progress_bar` method, tries to access the field `activity_state`
which is: `states = record.activity_ids.mapped('state')`. The state of
a `mail.activity` is using the tz of the partner. To read the
`activity_state` of a lead, one needs to access
`record.activity_ids.user_id.partner_id.tz`
=> multi-company security rules raised

opw: 1850984, 1859470

Suppose there is a one2many field embedded in a one2many,
(say we are viewing record A with one2many field B itself with a one2many C).
Furthermore, there is a second page of the one2many field B.
If an onchange is applied on B, then the server replies with a 1 command for all
B records attached to the currently viewed object A.
This includes a list of commands [[5], [4, C_id]*] for each B record,
in particular B records that are on the second page.
Since they are on the second page, they might not have been fetched by the
frontend; in that case the corresponding C_ids are thus unknown.
As a consequence, on save the frontend sends a command 0 to create the records
for all unknown C_ids.
Since it doesn't have any value to give to the 0 command, the row creation
usually crash in the backend.

Another wrong behaviour is fixed at the same time: if the server sends an update
on the list of C ids with 4 commands.
In that case, if the record has not been prefetched, we have no way to know
if the list changed or not.

To solve this, when we receive the 4 commands by the server, we send back 4
commands.

coauthored by @aab-odoo

opw 1835936

Before this commit, the kanban view ignored the fact that a field widget
could be asynchronous.  Worse, some preliminary support was done in
kanban record, but this would crash if an async widget was used.

With this commit, we properly synchronize the kanban
records/columns/renderer.  If for some reason a widget needs to be
added to the DOM before it is ready, it can simply returns an empty
value in the willStart/start methods.

Before this commit, there was a traceback in the following scenario:

Let's have a kanban view with groupby and a domain.
If we clear the domain then clear the groupby, there could be a crash.

This crash occurs because when we clear the groupby, it performs a `reload`,
and assumes that the datapoint contains grouped data. However, if this
computation takes some time, it is possible to overwrite the datapoint so that
there is no longer grouped data.

This commit fixes the issue by enforcing at most 1 execution of the method
`reload` active at any time. Consequently, successive reloads operations are
now much slower.

Note that it uses the single non-reentrant mutex on the basic_model to enforce
this rule, which means:

  - No more concurrent `reload` and `save`.
  - If an execution having the mutex in `reload` come accross the same mutex,
    it is blocked forever. This is hopefully not the case at the moment,
    however a reentrant mutex should be considered in the future.

The barcodes modules had documentation only available on apps.odoo.com,
following a recent change, odoo modules are not displayed on
apps.odoo.com anymore.

Thus this commit merges the documentation onto the module description so
it is available on the module page.

opw-1846035
closes #25621

Clicking outside the new content options should close the overlay.
Every options are triggering a JS event (mostly opening a modal) that works
fine.

But the 'New Job offer' options is simply a href link which is not going
through anymore since there was a call to `preventDefault`.

opw-1860196

As `pre-` migration scripts may use the registry, we must ensure that
all fields are set up before execution in order to have a consistent
registry.

This is required when loading a registry which contains modules to
install/upgrade without `-u` flag. In this case, the setup was only done
*after* module loading.

Method was using self instead of line in the loop for.

introduced in rev: https://github.com/odoo/odoo/commit/ba5918ffcbe5fe9155308c53e014e5e93c588ca6

To have a better encoding timesheet, we want for the user:
1/ when selecting project first, the task proposed will be
the ones in the project. When changing project, it reset the
task to empty.
2/ when selecting the task first, the project will be the
one from the task

Add grouping possibility on model make for vehicles in the fleet.
Deleted redundent controll on make image for vehicles if model changed.
fixed _name_search for FleetVehicle

project : RD for Dummies
task : [Fleet] Allow to filter/group by Make on vehicles

PURPOSE
=======

1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models

Specification
=============

1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
   renamed, removed, created in python instead of as demo data
   ...

Closes #25512