Closes #20801

The groups were set only on the view which does not prevent abuses.
The fact that users can bypass the groups on the view is not critical as the
changes are logged but this should be improved nevertheless.

In master, proper record rules should be set.

Closes #20427

Here is a situation where we had a problem:
- a form view with a one2many field, which has no inline views
- the (non inline) list view has a field A, and is not editable
- the (non inline) sub form view has fields A and B, with an onchange on
  B which modifies A

In that case, the user could do this:
- go to edit mode
- click on 'add' a new one2many line
- change the value of B in the form view, this changes the value of A
- click on save to close the modal form view
- click on the new o2m record to reopen the modal form view
- rechange B
=> the onchange does not work

The explanation is that when we reopen the modal, we update the known fields
information, but we had to perform a fieldviewget to fetch the list
view, so we have a full knowledge of the fields.  However, the code did
not update the fields info (because it uses _.default), which means that
the onchange information contained in the form view is lost.

Note: the test system had to be adapted to more closely simulate what
actually happens.  In particular, the onchange flag is no longer added
by the mock server, since it should be done by the data manager, like
'real' code.  This change broke the basic model tests, which had to be
modified accordingly, by setting manually the onchange flag.

Commit[1] tried to improve the usability of the pick + pack + ship + a
fixed procurement group scenario by erasing the origin value on the
groupped ship that refered wrongly to only the first downstream document
(and in fact refered to multiple).

We forgot the scenario into which we add a sale order line. In this
scenario, we also go through `_assign_picking` and, if an existing open
picking is found, we also wiped its partner and origin value, which was
indeed wrong.

We fix this scenario by being more precise on the erasing condition.

[1] 4a5f0765

Before this commit, an issue occured when you tried to
create a new record in a editable grouped list view.
A new line was created with an undefined group.

Editable grouped list views are not supported.
So now, we have to switch on the form view when
you click on create. This behavior is already implemented
when you open an existing record.

In 11.0, this part of the code has been removed.

When choosing the shipping address in the cart, if a tax has been mapped
by a fiscal position, the subtotal was not correctly computed.

opw:778405

Closes #20782

Since 3d04e448, the reports must start with a `article` class, not `page`.
The report was not adapted.

Fixes #20066

adapting #20279 to v10

Before this commit, when starting a livechat session as a public user and continuing as a portal user, the livechat crashed
(the poral user couldn't see the channel created before as Admin)

After this commit, the conversation is kept and security insured by the uuid in the cookie

OPW 775568

closes #20281

Snippet options were not receiving proper data parameter on
instantiantion due to a websitepocalypse wrong adaptation. Those
data are parameters to tweak an option behavior, directly defined
on the option's <div/> in the XML. By mistake, they were now taken
on the child <li/> element (main DOM element of the option).

A visual example of the bug is the overlay colorpicker displaying
"Background Color" as a title instead of "Overlay Color".

Before this revision, only the FormView allowed to reuse the same datapoint.
This was only used when opening a FormViewDialog when opening the form view
of record in a one2many field.

However, this could be useful in other places for other views. In Studio for
example, we need to instantiate a x2m view without the parent view ; we thus
need to be able to reuse the same model for all basic views.

A domain could contain the key `parent` (in an embedded subview), like:

    domain="[('display_name', '=', parent.display_name)]")

This is currently not handled by the DomainSelector.

This will probably be handled in a future version but for this stable version,
this case that triggered an error is now catched and an error message is
displayed in the widget.

This was causing a traceback when opening a domain with `parent` in the edition
of a subview with Studio.

The method `_process_jobs` provides an alternative API to process the cron
jobs, that does not catch exceptions and log them.  This makes the processing
of cron jobs easier for scripting.

The "Event" API is not the same between IE9 till IE11 and all the other
browser (eg: IE Edge, google chrome, firefox, ...).

For example here is a seemingly accepted polyfill to have it working the
'same' on most browsers using CustomEvent:

https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent/CustomEvent#Polyfill

This commit just trigger the event with jQuery which attains the same
result but work everywhere.

opw-780056
closes #20759

Courtesy of translator teams

Thoses -> those
Add model description

Courtesy of translators for report

In case we are not uploading a file but add a slide based on google doc url
or youtube link, post['datas'] is not set and the code will crash.

Javascript don't check the onError, so the user never see the error and wait
 that nothing happend.

Leftover of 78ac6de5 code about mail gateway was moved to
mail_alias.py but mail_thread.py file was not removed.

You could try to check followers on a model not inheriting from mail alias
mixin. In that case current code would check followers on a void mail
alias mixin record, meaning no followers found. Instead we now
differentiate the class method from the method checking record properties.

Mesage should be message otherwise it is not displayed in the logs.

With da136d83 we have modifiers on every elements but when saving them
for dashboard they have to be stringified to be used.

Also a part of a previous code was still present that removed context
and domain from a saved dashboard when modifying it.

opw-779071
closes #20725

Here is a scenario that could cause an issue:
- open a form view with a many2one
- click on edit button
- click on small external button for many2one. this opens a modal form
  view
- click on save in the modal (without changing anything)
- click on save in the main record
- exit form view. this opens a discard dialog

There were two issues here:
- saving the modal dialog automatically marks the many2one field as changed.
  This was necessary to force reloading the data, because editing a sub value
  in the modal form view could have changed the display_name of the manyone
  field.  However, this is not necessary when no change was done.
- when saving a record, the _isDirty flag was reset to false only if an
  actual rpc was done.  However, it may happen that the flag is set to
  dirty (for example, when modifying a value inside a many2one), but the
  main record has no changed fields.

In this commit, we also remove the on_save handler in the
formviewdialog.  This is a small refactoring in a stable version, but no code
currently use it, and I believe that it will make the code much easier
to maintain (the previous code was really awkward), so I think that the
tradeoff is acceptable.

This commit improve the daily use of activities by delegating activities
management to the document. Activities are already managed on document
through the UI either in form view or in kanban view.

and rename the alarms by email for a better name

Makes sense to be translated as general and useful to have it as data.

Fixes #20634
Closes #20644

Bug brought by f45edfbe

Before this commit, the debug manager crashed when clicking on "set defaults" on a view fetching a fieldDependency.
This was because the "options" key on the field was not set when the field originated from the fieldDependency of a widget.

After this commit, the data_manager ensures that key is present

OPW 780071

closes #20730

To make it translatable

ERROR: column reference "action" is ambiguous

This commit closes #13839

An error occurred if the domain or context applied on a view
opened in a dialog needed to be evaluated (e.g. if they contained
something like [['some_field', '=', uid]]). For instance, create
a custom filter with such a domain for the Contact model, then go
to Contact, create a new one, and on the parent_id many2one, click
on search more. Before this rev, no eval context was given so the
domains and contexts couldn't be evaluated, and it crashed.