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.

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

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

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.

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.

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.

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

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.

- Create a user A
- Create a lead, assign to A
- Deactivate user A
- Duplicate the lead

A notification email is sent to A (user assigned to the lead).

Since the user is archived, he should not receive any email since it
might contain sensitive information.

opw-778825

After entering a value in a many2one, if one clicks somewhere else, a popup
is opened to suggest the user to create (or not) a new record with the entered
value.

Before this rev, closing this popup resulted in an unclear situation where the
input was still set with the entered value but the new record hadn't been created.

This commit fixes this by clearing the input value if the record is not created.

See task#36055

Before this commit, an opp created from a contact via the portal was assign to
himself instead of the commercial_partner_id.

So the saleperson was not assigned to the opportunity, and the opp created was
not for the company but for the contact only.

That make sense to share the opp to the company and assign the saleman directly.

Thanks to GBR for the reporting.

[FIX] *: do not use groups when extending an asset bundle
Using groups when declaring an extension of an asset bundle leads to a
different generated asset bundle according to the user's group. This
is not something we want because a dynamic asset bundle's content
means that it could (and it does) trigger unwanted cache invalidation.

website_event, website_blog, website_forum and website_sale add
functions to . These functions are bound to
server side qweb nodes protected by groups. We can always add the
functions; if a user tries to use the routes he should receive a
traceback because of lack of access rules

website_blog adds a  module, but is guarded by
the presence of a node in the DOM. We use the same logic to guard the
module added by website_sale with the  node.

website_gengo is working as expected.

Closes #20724

Use case to reproduce:
- Set a product to be expensed
- Set the expense_policy to something else than no
- Do a delivery order with a picking
- Validate the picking
-> Delivered quantity to 0 and impossible to create an invoice
if the invoice_policy is delivered_quantity

It happens due to this commit 48ea59d4
What does it do:
- The move could be generated by an expense.
- If the move has 'no' as expense policy thus we won't add it in the invoice
Problem we can't guess if the move come from an expense or not (limitation).

This commit add an onchange on can_be_expense is order to set the expense
policy back to 'no' when the user uncheck it.

Courtesy of amoyaux

opw-777139

When opening the POS in this specific case:
- Under Mozilla Firefox
- auto printing the receipt is True
- invoicing is True

Before this commit, when issuing an invoice for a customer, a Traceback was thrown to the user and the invoice was not downloaded.
This was because the invoiced parameter resolved before the printing action was.

After this commit, we constain the invoiced parameter to be resolved when the action returns.
There is no traceback, and the invoice is downloaded

OPW 777647

closes #20570

`tax_amount` is not defined here, making it impossible to remove an
order line...

- Create a tax:
  Fixed amount: 10
  Price included
- Add it by default to a product costing 100
- In a SO/PO/Invoice, add 2 units of the product

The total price is 210 instead of 200.

opw-779696