Other modules that was overriding old name method was just ignored.
Drop retro compatibility fixes in next freeze (saas-14) and stop
useless renaming.

This commit closes #13865

The field was a stored computed field without dependencies, and therefore it
was never (re)computed. Add a simple dependency on the model `ir.model.data`
to make the recomputation everytime a view is modified. Moreover, when views
are created from modules, delay the recomputation of view fields until their
`ir.model.data` record is created.

Note: in 10.0, the layout has changed and it is not a problem anymore.

account_analytic_analysis doesn't exists anymore.

This commit closes #13867

When a account statement is validated, it's not possible to cancel a statement line.
To cancel a line from a validated statement, you must first reset to new the statement.
In this way, it's not possible to have a validated statement with unreconciled lines.

opw:690766

Missing arguments in method call, which causes crash.

On a PO linked to a purchase tender, changing the quantity on a PO line
will trigger a recompute of the unit price. However, this recomputation
will take into account the unit price of the supplier pricelist, not the
unit price on the purchase tender.

opw-690483

When the purchase tender of a PO refers to a blanket order, the price
unit used to create/update the order lines doesn't take into account the
potential difference of UoM.

When returning an item by entering an orderline with a negative quantity
you got a warning message asking you to confirm a large payment
amount. Introduced by 5a3d9ce9.

Closes #13777

If you validate an order it will be sent to the backend. If you then
close the POS frontend somehow before clicking 'Next order' this order
will be reloaded from localStorage when reopening it. This is
problematic because it allows the user to then modify this order and
validate it again. Everything will appear fine but in the backend this
new, modified order will be ignored as it has the same pos_reference as
the one that was sent initially.

The deeper underlying issue is that there exists a brief timeframe where
the same order can exist twice in the db: both as 'order' and
'unpaid_order'. To ensure this does not happen this fix removes the
order from the unpaid orders after it is saved as a validated order.

Fixes #13538

Before the fix, the tax base amount is computed only for a complete
invoice line. However, depending on the tax sequence and their inclusion
in the base amount, the tax base amount might be different for the
various taxes of an invoice line.

We keep track of the base amount for every single tax, and refactor the
`_compute_base_amount` to take these values into account.

opw-691177
Closes #13819

When registering a payment on an account invoice with an automated
action which adds a follower "On Creation & Update", the function
recompute was triggered(due to the field residual_company_signed)
and the same followers was added two times for the invoice.

The fix avoid to unlink and create the same followers several
times(because it was the case with the function "_add_follower_command")

opw:690939

The form widgets did not apply the 'style' attribute to the result of
the rendering.  Because of that, many small adjustment were no longer
possible. This commit makes sure that it is indeed done.

This is needed for example, to enhance the analytic dimension of these
lines.

Closes #12739
opw-691337

The following configuration leads to different results:
- Deferred revenue: 12 entries, 1/month, prorata temporis, 1000€,
  date 15th of October
- Asset: 12 entries, 1/month, prorata temporis, 1000€, linear, date
  15th of October

Deferred revenues and assets should give identical results.

opw-690034

This is required in order to have those bank journal items appearing afterwards in the bank statement reconciliation widget (blue line) for reconciliation.

[FIX] anglo_saxon_dropshipping: fix accounting entries creating on anglo_saxon + real_time + dropship.

This revert the fix made on 7bdd4de8 and replace it with a proper one that do create an account entry from stock_input to stock_output on a dropship move. That way, we avoid the manual change of account on supplier invoice. See the whole discussion on odoo#12687

In 8.0, the field `base` was a stored Float (see https://github.com/odoo/odoo/blob/8.0/addons/account/account_invoice.py#L1516 )
In 9.0, the field `base` is a Monetary computed non-stored (see https://github.com/odoo/odoo/blob/9.0/addons/account/models/account_invoice.py#L1307 )

As it is not stored, there is no point of anonymise it, so it can be removed from the CSV file.

Before this commit, the inventory by lot/pack/serial/... was only visible
if you switch quickly between res_config and adjustment inventory... once
the vaccumn clean the osv memory, the options was ignored.

Same issue with the _get_string_qty_information function.

Setting the value of a one2many field (`rec.line_ids = ...`) converts the new
recordset to a list of commands, and passes it to `write`.

Currently the list of commands is like: `[(5,), (0, 0, vals), (1, id, vals), (4, id), ...]`.
Notice that the command `(5,)` is inappropriate here: it deletes all the
existing lines of the record. Reintroducing the same lines with `(4, id)`
commands crashes, because the corresponding `id` is no longer in database.

The fix serializes the recordset as a list of commands like
`[(6, 0, ids), (0, 0, vals), (1, id, vals), ...]`.
Only the lines that are not kept will be deleted in this case.

- Create a deferred revenue type > 3 depreciations, one every month
- Create a deferred revenue with this revenue type
- Odoo generates a depreciation board with 3 entries > one should be
  done in October, one November, one in december
- Generate your deferred revenues entries UNTIL 31st of december

Odoo create the 3 depreciations but they all have the 31ST of december
as accounting date > the dates of these accounting entries should be the
date defined on the depreciation board.

opw-690970

When we are trying to set the quantity on a mobile device, we get
a traceback saying that we cannot call the 'find' function on the
elements returned by '_get_records'.

This '_get_records' function returns a 'Collection' when called on a tree
view and an 'Array' when called on a kanban view. When we are working
on a mobile device, most of the one2many are displayed as kanban.
The thing is when we work with the object returned by '_get_records' we
call a 'find' method on it, which is implemented by Odoo's Collection class.

So when we call 'find' on an 'Array' we actually call 'Array.prototype.find' which
is implemented on most desktop browser and on some mobile browser [1]. This is what
caused the traceback on Chrome in Android.

To fix this issue, we enforce '_get_records' to always return an 'Array' and we ensure
that, when working on this 'Array', we use '_.find'.

[1] https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/find

In the frontend customer quote validation,
the company used in the sentence
```
I agree that by signing this proposal,
I accept it on the behalf of
```

was the quotation company, which is the company
which is selling, not the company/customer which is buying,
and this does not make any sense.

Instead, it should use the company of the customer
accepting the sales order, or simply the customer
if he does not have a company set.

The only case which make it a little weird is when
it's the customer himself, without parent company,
who is accepting the quote
"on the behalf of himself", but:
 - This isn't possible to correct this without
   breaking the translations, because the
   sentence "I accept it on the behalf on"
   is within the same sentence than
   "I agree that by signing this proposal"
 - This makes sense if another person than the
   customer himself is validating the order
   (the customer sent the quote link with the token
    to another person).

opw-690837

Data dictionary filled inside the function purchase_order_change had no possibility
of inheritance.

opw:690733

Current issue without this patch:
On a bare database, install `website_portal` and go to `/my/home` logged out.
You get to an empty page where you can see Public User's details.

Expected behavior with this patch:
User should be redirected to the login page.

Additional notes:
- Other submodules (`website_portal_sale` and `website_project_issue`) were
  actually implementing this, so that is removed BTW and relies in base
  module's now sensible behavior.

This commit closes #12775

With this commit, it's now possible to set an arbitrary limit on any
kanban view by adding a limit attribut to the root kanban tag in a
kanban definition.

Do not forward-port.

Backport of rev 8a87c382

- Activate the receipt in two steps on the warehouse
- Create a PO for a stockable product
- Receive the product in Input zone
- Receive the product in Stock
- Reverse the move to Stock > products are back in Input
- Reverse the move to Input

You can't reserve quantities for this last move (from Input to Vendor).

This is because a picking has been automatically created from the Input
to Stock.

Original move which is reversed: Input -> Stock
When we reverse it, we don't want to send it back to Stock, so we need
to check the destination location of the original move, not its
location.

opw-689206

In the widget, the value of reference field is a pair `[val1, val2]`.
When the field is blank, its value is `[false,false]`, thus checking `[false,false] === false`
never succeeds, and this breaks the check for required fields.

This is done by guarding the `on_hashchange` evant handler with the
`clear_uncommitted_changes` function.

Note that the url has already changed when we are in this handler, so we
make sure to restore the old url when the user chose to continue its
edition.

When you browse through the views of an action and then hit the back button,
the view does not change. For example, go to the customers kanban, click
on a customer, hit back, you're still in the customer form view.

related rev: 46857d26

`do_load_state` is called when you hit f5 or press the back button on
your browser. The related rev took care of fixing the ugly part that
make the webclient goes trough the multi record view then the mono
record view when you hit f5 on a mono record view.

In this context, it removed the code in view manager's `do_load_state` that
switched the mode of the action if it isn't the same the one the web client
is trying to restore from the state (because now the correct mode is loaded).

However, if you hit the back button while the previous view is in the same
action, it obviously doesn't switch the mode anymore and you're facing
the same view.

The issue is fixed by restoring the switch_mode in the view manager's
`do_load_state` (without its oudated comment).

Added twice during a forward port

Closes #13796
Fixes ##13795