Intended for demo / throwaway databases only

Task-ID: 1856493

Documentation needed some update

* website_sale

Images which were related to a model's field were able to be edited
by a simple click on them. This prevented the use of the "Customize"
menu and was inconsistent with the edition of "normal" pictures which
occured on double click.

task-1859807

 * Split documentation of graph and pivot views
 * Add an alphabetical auto sorting on measures in pivot and graph views

The pivot view should have it's own documentation since it is an
independant view.

We want to improve the user experience with graph and pivot views, the
measures were not sorted in any particular way hence they were displayed
in what looks like a random order. We chose to order them in an
alphabetical, making it more usable.

As pivot and graph measures are now automatically alphabetically sorted,
we need to update the documentation

Pivot view documentation was still inside the graph view documentation
as it was previously only a mode of this graph view.

As the pivot is now an entirely different view, it has the right to have
it's own documentation.

Closes #25662

Done at #25662

[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