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.

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

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.

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.

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

The `sale_stock.tour` failed in the case the admin was not
part of the group
`product.group_stock_packaging`
or the group
`sale.group_mrp_properties`

because then the sale order was working with the editable list,
which does not open a dialog,
while the test was relying on the dialog to be opened,
in order to close it.

The fix is simply to pass the fact to close the dialog if
there is none.

opw-779308

In Enterprise:
- Go in Settings > Technical > Mail > Templates
- Edit a template
- In the editor, upload an image
- Choose "Upload image without optimization"

You are sent back to the app switcher.

opw-778918

Location and Company are non-stored fields. Therefore, grouping by these
fields leads to a traceback.

opw-779564

Only products without company can have taxes of different companies

Closes #20256 
Fixes #20250

The link does not work anymore.
Even when it was, it did not provide any information as can be seen in
https://web.archive.org/web/20160608025556/http://www.buckaroo-payments.com:80/business/customers/online-payment/

Fixes #16987

Do not try to run `action_assign` on the next move if it is done or
cancelled. The issue is that `action_assign` will first unlink the
existing pack operations before creating new ones, and the system
forbids to unlink these ones.

To reproduce this issue:
1. Create a product, routes manufacturing and MTO
2. Create SO with that product
3. Go to DO and force assign then cancel the delivery
4. Go to Manufacturing order created and produce

opw 778897

Suppose a tax of 20% with price_included = True and apply this tax on 399.99:
- base = 399.99 / 1.2 = 333.32500000000005
- tax_amount = base * 0.2 = 66.665
- round(base) + round(tax_amount) = 333.33 + 66.67 = 400.0 (!= 399.99: WRONG)

-opw: 777925

In 7eab8e26 res.partner was converted
to the new API, at that point company_type was changed from a stored
field manually synchronised with is_company (through create/write
overrides) into a proper computed field.

However to make it "editable" it was simply marked as
"readonly=False", which means even though UI-wise it looks editable
editing it does not actually do anything (things work in the partners
form because there's also an onchange which updates is_company on the
fly).

Fix by implementing an inverse function and actually do this
correctly.

Fixes #20623

- Go to Maintenance Requests, Create
- Go to 'Equipment' field, 'Create and edit'
- Go to 'Product Information' tab
- Click on 'Vendor' field, 'Create and edit'

'Is a Vendor' field is False

opw-779200

The /web/signup controller was also supposed to get the special frame
header, like all sign-in/up pages.

Fields `amount_type` on `account.tax` and `account.tax.template` are
already defined in the `account` module.
Redefining them here (with the same parameters) breaks every other
module that would have used `selection_add=` on those fields.

Actually, it is the case in `account_tax_python`, and thus, all the
localizations/customizations that depend on it were broken by this one.

~ Old API backport of 5d0d80af ~

Fields `amount_type` on `account.tax` and `account.tax.template` are
already defined in the `account` module.
Redefining them here (with the same parameters) breaks every other
module that would have used `selection_add=` on those fields.

Actually, it is the case in `account_tax_python`, and thus, all the
localizations/customizations that depend on it were broken by this one.

(issue spotted by 11.0-nightly)

Closes #19812 #20596

Remove weird special case: when the first field of the first line of a one2many
is empty, replace this first field by the comma-separated names of the lines,
and discard the other lines.

Fine tuning of this commit: 51d072db

When clicking on the group of the Inventory at Date, the
product.price.inventory must follow the same order as the
read_group in stock.history.

opw:747857