We support 'returns' in the POS frontend by allowing the user to
specify a negative quantity. Before this patch however, the backend
would always generate a single picking per pos.order. This is
problematic when a pos.order contains both lines with a positive and
negative quantity. The generated move lines would not all have the same
source and destination location and so could not be added to the same
picking.

This commit creates an extra 'return' picking when required and assigns
the generated moves to the correct picking.

opw-690812

Closes #13929

Forward-port of 19cca50e

Underscore method _.each expects an array like object when a "length"
property is present.

This was an issue with a record having a numeric "length" field set to a
non-negative value. When changing a line the change would not appear on
blur.

This issue was fixed with 0e664c9e but introduced back with f0e331e0.

opw-691070

Forward-port of 5d17749f which has been
forgotten during previous forward-port.

Oversight of commit 7e58821a

Closes #13998

When a group of tax is nested inside another group of taxes, the tax
amount and base are wrongly calculated. It is also the case when a tax
is applied after a group of taxes.

This is because the recursive call doesn't reuse the previously
calculated tax amounts and base, but always use the same entry amounts.

The fix introduces this behavior, and moreover makes sure to include the
tax group in the base amount only if it should.

Closes #13995

The ids returned in notifications must be ids of account move.

opw:690621

When clicking on "Show older messages" in the bottom of the chatter, the
page would jump to the top when the additional messages are loaded.

There is already a functionality in a discuss channel to stay at the
previous scrolling position (related to the content) :

 https://github.com/odoo/odoo/blob/ffe0db0d/addons/mail/static/src/js/client_action.js#L506-L521

This fix does the same steps for the chatter.

opw-692010

Consider that you have a custom one2many field based on a custom many2one
field, and that you delete the many2one field.  From that point on, it is
impossible to load the registry of the corresponding database.  To prevent this
from happening, we add a check before modifying or deleting custom fields.

When unreconciling a payment from an invoice, the link between
the payment and the invoice (in many2many invoice_ids)was kept
and then the invoice still appeared when clicking on the button
invoices in the payment form view.

The invoice must be removed from invoice_ids.

opw:691692

When clicking on the trash to remove a line (e.g. a sale order line
in a quotation form view) while editing another line, it produces a
traceback (in most cases), or behaves randomly (less frequently)
like removing both lines, or one of them, or maybe none of them.

Anyway, this feature doesn't work at all, so this commit simply disables
it when we are in edition mode.

In a perfect world, we would fix the feature instead of disabling it,
but the code of the list editable is so instable that it would most
certainly break something else.

Closes #13778

The dashboard instantiates an action manager for each view it contains.
When removing a view from the dashboard, the $el of its action manager
is simply removed from the DOM, unbinding all DOM event handlers
attached on it and its children, but the action manager isn't destroyed.
It means that Odoo event handlers (like core.bus.on(...)) aren't unbound.

This causes a traceback when removing a calendar view from the dashboard,
because such an Odoo handler is defined, and tries to access some
autocomplete stuff that doesn't exist anymore since the element has been
removed.

This commit ensures to destroy the action_manager.

Closes #13858

Since rev. 002660a9, form views are instantiated with their fields_view.
This has an impact in FormViewDialog as the inner form view
instantiation is now asynchronous. The diagram view instantiates several
FormViewDialogs but doesn't wait for the form view to be instantiated
before accessing it, which produces a traceback.

Closes #13775

- Invoice a POS order => the invoice number is for example 0001
- Close the POS session
- Invoice another POS order => the invoice number is 0003

This is because the journal used for the POS closing entries is the same
than the journal used for the customer invoices. Therefore, the closing
entry consumes a sequence number of the invoices.

This affects POS orders, but potentially SO as well if they use the same
journal.

This is fixed in v10 from commit b5b0d36b. In v9, we use a workaround
by looking first if a `ir.config_parameter` named
`pos.closing.journal_id` exists. We use this journal for the session
closing.

opw-691771

Allow reading and saving the value of `server_wide_modules` from the
configuration file, instead of just the command line.

The max size of 20 is for the pos ticket which has a limited size.
Strip on client side to keep the full name for the pdf report.
opw-691483

We support 'returns' in the POS frontend by allowing the user to
specify a negative quantity. Before this patch however, the backend
would always generate a single picking per pos.order. This is
problematic when a pos.order contains both lines with a positive and
negative quantity. The generated move lines would not all have the same
source and destination location and so could not be added to the same
picking.

This commit creates an extra 'return' picking when required and assigns
the generated moves to the correct picking.

Closes #13699
Closes #13762

opw-690812

There are multiple scopes giving access to analytics api, like
https://www.googleapis.com/auth/analytics.readonly

Having a space at the end of the queried string prevents correct
scope detection; so a user who has, in fact, access will receive
a faulty error message.

Commit which added summernote broke the ace editor with a strange
change: https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7#diff-e9d66a1b466f404be082fa00519eafa5L140.

With this change instead of not including the assets bundles in the ace
editor and allowing to see them by checking the option, the assets
bundles were included when NOT in debug mode and not included when in
debug mode.

* The Dialog dependency was missing
* The function arguments were wrong

Before this patch, the debian package depends on `python-pybabel`.
According to the documentation, this is a dummy package for transition
from `python-pybabel` to `python-babel`[1].

This dummy package has thus been removed in debian stretch in favor of
`python-babel`, and the odoo package is thus not installable in debian
stretch.

To fix this, we depend directly on `python-babel`, which is available in
all debian releases[2].

Closes #13905

[1] https://packages.debian.org/jessie/python-pybabel
[2] https://packages.debian.org/jessie/python-babel

Underscore method _.each expects an array like object when a
"length" property is present.

This was an issue with a record having a numeric "length" field set
to a non-negative value.

opw-691070

Without this patch, the fonts are not included and the barcodes in the
reports were not displayed.

The `map_account()` method expects a browse_record as
parameter, and returns a browse_record (possibly the
argument if no mapping happened).

It was being called with an account ID instead, so
fiscal position mapping would never match, and would
always return the argument itself.

The `fiscal_position_id` field actually depends on both
the `shipping_partner_id` and the `partner_id` field,
not just the former.

Theoretically the recompute should trigger on both fields
anyway because changing the `partner_id` will automatically
change the `shipping_partner_id`.

Unfortunately this onchange chaining does not work as expected
as of Odoo 9, at least when the `partner_id` field is set
to the same value (was done for optimization reasons).
This special case really happens when you edit the Partner
from a sales order form view, and save the changes.
It triggers a "dummy on_change" for the `partner_id`
value, with the same value as before.
If the edit changed the fiscal position or another
field on which it depends, a recompute is really needed.

Adding the direct dependency works around this limitation,
and is semantically valid, too.

An extra fix of this special case in the framework might still
be nice to have, though.

Ref: feedback ID 29042

Underscore method _.each expects an array like object when a "length"
property is present.

This was an issue with a record having a numeric "length" field set to a
non-negative value. When changing a line the change would not appear on
blur.

This issue was fixed with 0e664c9e but introduced back with f0e331e0.

opw-691070

This is related to revision
b65c67a2

The field `seller_ids` is a field which is set
on the `product.template`, and this is why
the condition `(x.product_id == product)` is being applied
in the list comprehension searching the current seller
of the product sellers.

The `variant` variable is a string containing
the attribute name of a variant.
Therefore, if a product tempalte has only one variant, without
any attribute (e.g. when you don't use variants),
`variant` will be empty, and therefore the condition
`if variant:` will be `False`, and therefore it won't search
in the product sellers with a specific `product.product`, while it
should, as, even if there are no attributes, there could be a
seller line with this specific `product.product`.

Besides, as we are in the `name_get` of `product.product`, and
not the `name_get` of `product.template`, we are always in the case
of a `variant`, this test is therefore pointless.

opw-682390

[FIX] hr_expense: don't group accounting entries of hr.expense if several are generated at the same time.

This grouping was causing problem at the time of bank statement reconciliation, if the expenses were set as already paid by the company, since we had only one account.move related to several bank statement lines although the DB structure wasn't allowing such a case (the link was made as a m2o from account.move to account.bank.statement.line where a m2m would have been needed).

Make sure tax.base is always defined to avoid traceback.