An OFX file can contain more than one account. Therefore, we need to
loop over all the included accounts, otherwise statements will be
missed.

opw-673814

This case corresponds to searches like `[(field, 'ilike', name)]` where `field`
is a many2many field.  The domain processing performs a `name_search` on the
field's comodel, then makes the relation match the returned record ids.

Problem: the call to `name_search` uses the default limit (100), and this makes
the search return less results than expected.  Make the search complete by
forcing `limit=None`.

When traversing relational fields as superuser, you end up with a recordset for
which only a subset is accessible to the current user.  An earlier fix to this
issue completely dropped the `related_sudo` feature; change its implementation
to keep the feature.

Non-stored new API computed fields are only defined in _fields
but not in _columns, and they were never exported within translation
files.

Closes #9081

When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.

Used case:

- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice

Before the fix: the asset is created twice.
After the fix: the asset is created once.

opw:674674

Note: This is a cherry-pick of commits 9d14230d and 58a5b5e4

Handle the case of immutable (tuple) domain leafs.

When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.

Used case:

- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice

Before the fix: the asset is created twice.
After the fix: the asset is created once.

opw:674674

The pricelist field is not a mandatory field on the partner. A default
value is usually defined for any new partner created. However, if the
pricelist is manually removed from the partner, errors (tracebacks) will
occur in the eCommerce when no pricelist is found.

We cannot make the field mandatory, as it could potentially break the
workflow of some users which are not using eCommerce. Therefore, we
simply log an error message to help debugging.

opw-673453

Closes #11815

On the `res.company` model, the fields
`name`, `phone`, `email`, `website`, `vat` are
related field on the `partner_id` of the company.

When creating a new company, the partner
associated to the company is created automatically,
it's handled in the overrided `create` method
of the model, but it forgots the values
`phone`, `email`, `website`, `vat` at the moment
the partner is being created.

opw-675526

This fixes the case where the lines of a one2many field are modified several
times by onchange methods: instead of retrieving the most recent updates, we
merge them with former updates.

This solution was written as an improvement of a proposal made by Alexis
Delattre and Sébastien Beau as #11620.

When writting a value on a translatable field in a different language than
English, the submitted *raw* value was saved in the database.

This could cause the following issues:
- empty value (provided as `False` by the web client) saved as the string
  'false' in the translations table
- no encoding or sanitization convertion
- ignore size parameter on the translatable field

Process the submitted translation through symbol_set method to clean it before
storing it blindly in the database.

This allows to convert `False` into `''` for empty value and fixes #10862

[FIX] account: Allow to select sale taxes in bank statement reconciliation process. Courtesy of adrienpeiffer. PR #11673

attribute string is translatable on a search filter, not name (which is used as fallback label
Closes #10419

Do not match with source
Closes #11789

This revision corrects a regression introduced by
8395f0d2:
the possibility to call
`ir.qweb.field.datetime`.`value_to_html` with
a datetime string directly, instead of calling
`ir.qweb.field.datetime`.`record_to_html`
(which call `value_to_html` as well).

opw-675427

The dates of an event on the website was always
within the user timezone. If not signed in,
it was within the public user timezone
(which is quite not user-friendly to change)

For this purpose, we weed get the context
from the record (the context used when using
`record.with_context`), and therefore
the QWeb field
`ir.qweb.field.datetime` is slightly altered,
to use the context from the record.

opw-675427

From af614946
Allow to compute the depreciation when the asset is in state: draft

The above string was not translated, when creating a new
discussion group, in the group message input placeholder.

opw-673712

The stock history doesn't take into account internal moves. For example,
in the following situation:
- Receive 1000 products to Internal Warehouse 1
- Move these 1000 products to Internal Warehouse 2

The 1000 products are still recorded on the Internal Warehouse 1.

opw-672277

This is a complement to commit 6d4a78a2. The 'invoiced' status should
be removed automatically once the membership is expired.

opw-672259

Avoids name collisions when custom columns are involved.

Closes #11743

Oversight of commit bd025cda.
I'm an idiot, I should have checked that another solution was applied
from 9.0 with accounting refactoring. We apply it here as well.

When stock landed costs are divided per product unit, inconsistencies
may arise between the real stock valuation and the stock valuation
account. This is likely to happen when several products are bought, but
these products leave the stock one at a time.

A numerical example is the following: a landed cost of 15.00 is applied
to a purchase of 13 units. An amount of 15.00 is recorded when the
products enter the stock. If the product leave the stock one at a time,
13 entries of 1.15 are recorded (15.00/13 = 1.153846... ≈ 1.15), which
is then equal to 13 * 1.15 = 14.95. In this case, All the products have
left the stock (stock valuation is zero), but 5 cents remain on the
account.

This is of course even worse the higher the ratio is. For example, a
landed cost of 4.00 split into 1000 units sold piece by piece will never
be recorded when a product leaves the stock.

The fix is to record the rounding difference on a specific quant. In the
previous example, instead of adding 1.153846... on the unit cost of the
13 units, we do the following:
- 12 units to which we add 1.15 on unit cost
- 1 unit to which we add 1.20 on unit cost

opw-675222

When the product price is divided per product unit, inconsistencies
may arise between the real stock valuation and the stock valuation
account. This is likely to happen when a product is bought in a UoM
different from the standard UoM of the product.

A numerical example is the following: a box of 13 is bought for 15.00.
An amount of 15.00 is recorded when the products enter the stock. If the
product leave the stock one at a time, 13 entries of 1.15 are recorded
(15.00/13 = 1.153846... ≈ 1.15), which is then equal to
13 * 1.15 = 14.95. In this case, All the products have left the stock
(stock valuation is zero), but 5 cents remain on the account.

This is of course even worse the higher the ratio is. For example, a
box of 4.00 split into 1000 units sold piece by piece will never be
recorded when a product leaves the stock.

The fix is to record the rounding difference on a specific quant. In the
previous example, instead of adding 1.153846... on the unit cost of the
13 units, we do the following:
- 12 units to which we add 1.15 on unit cost
- 1 unit to which we add 1.20 on unit cost

opw-675222

The precision of `former_cost_per_unit` should not be set. Indeed, a
stock move can contain several quants with different unit prices.
Therefore, we should not round the field when stored, otherwise the
difference per unit will not be calculated correctly.

This is a workaround since we cannot change the DB structure in stable.

opw-675222

Use the normalized quantity, otherwise the amount per unit is wrongly
calculated.

Complement of f992c8ee,
to be reverted in saas-6+ and in 8.0 when Chrome's
fix reaches the stable Chrome channel.

Fixes #11629

See https://bugs.chromium.org/p/chromium/issues/detail?id=603507

Everything's displayed fine on orderlines with weighable products, this
only affected the small blue labels on the products.

opw-674264

In version 3, process.memory_info() returns only rss and vms
In version 4, it now returns rss, vms, shared, text, lib, data and dirty
Automatic unpacking is no longer possible in 4.0

Fixes #11052, Closes #11459

signature #11459

Closes #11639

Makes the fix in f992c8ee
specific to the view manager of the main oe_application
container, in order to avoid disrupting other view manager
occurrences (such as the ones in modal windows or x2many
list views).

Fixes #11629 (again)

Note: Hopefully the Blink team will fix Chrome so we can
get rid of this hack in the future:
  https://bugs.chromium.org/p/chromium/issues/detail?id=603507