Handling update/create of existing values is already
handled by ir.values.set() itself.

While the signature makes sense in an old API context (sort-of) it's
very easy to misuse in a new API context as one'd expect `has_group` to
use the subject (recordset), not the user in the environment, compounded
by ``env.user`` being browsed as administrator, resulting in the
"obvious" ``env.user.has_group(foo)`` checking if the
administrator (rather than the current user) has the specified group.

Adds a divergent v8 version of has_group which first checks if it's
called on a non-empty recordset, and in that case use the recordset id,
otherwise fallback on the context user (to handle new API conversions
which used the "correct" call convention rather than the obvious one).

fixes #9649

Both UoM and UoS quantity change should be propagated.

Fixes #10623
opw-667805

When changing the quantity of a SO line, the product_id_change_with_wh
must be triggered to check the availability of this product.

opw:668236

When writing on a recordset with duplicates, the ORM raises a `MissingError`
because the rowcount gives a difference with the injected ids.  The fix simply
eliminates duplicates from ids.

When a record is exported, an external ID, in the form of __export__.<model>_<id>
is created on this record.

When the translations are generated (e.g. "synchronise terms" wizard), the
translations may be duplicated for records that have been exported. If a
translation is submitted before the export (when the record had no external ID
yet), a new empty translation is created as the module differs in the import.

Creating a new translation may be a problem as the new term (equal to the source
term) will be used as the translation value.

Fixes 9480

When overriding a method that calls its super later on, it's important
that arguments is used to correctly pass all arguments to the super.

Consider the following:

// module 1 (not correct)
method: function(a) {
    return _super.call(this, a);
}

// module 2 (correct)
method: function(a, b) {
    return _super.apply(this, arguments);
}

If the method of module 1 gets called first it will throw away the b
argument when it calls _super. Therefore the b argument will never
arrive in method of module 2.

The margin in a SO line is the difference between the price unit and
the cost price of this SO line. In function "_product_margin" in model
"sale.order.line", the cost price is equal to the purchase_price or
the standard_price of the product. Then the cost price in the SO line
must be set with the same value when creating SO line linked to the delivery.

opw:668090

The order of a bank statement lines is entirely done on the sequence:
`_order = "statement_id desc, sequence"`

The `create` method of `accounT.bank.statement` is overriden
to handle the sequences of each line.

The `write` method as well, except that the set of the sequences
lines is done after the call to `super`. So, if you add
several new lines to a bank statement, the order of the line
you just added can be different before and after save,
as the sequence of these new lines are not set before
actually writting them on the bank statement.

The widget `handle` serves this sequencing purpose. The
fact it isn't used here is most-likely because
it did not exist at the time this was designed.

Besides, this gives the possibility to the user
to add a new line and re-order it where he wants.
For instance, when manually entering a bank statement,
a user could skip unintentionally a line. If he would
like to add it at the right place, before this revision,
he would have to delete all the lines coming
after the line he skipped. Now, he can add
it at the end, and re-order it where he wants.

What is done in the overriden `create` and `write`
is now useless, but we left it for retro-compatibility
purposes, for databases updating their sources without
updating their views.

opw-667541

The system cannot create two inventory adjustements in state 'in Progess'
with the same product, with the same location, same package, same lot and
same owner.
Example:if two adjustments(ADJ1, ADJ2) are created with the same product(P)
and with the same location(L), let's say:
qty_available for P is 10
in ADJ1: Theoritical Quantity=10 and Real Quantity=20 => a quant with +10 is created
in ADJ2: Theoritical Quantity=10 and Real Quantity=30 => a quant with +20 is created

When ADJ1 is validated then qty_available for P is now 20(that 's ok)
When ADJ2 is validated then qty_available for P is now 40(that's wrong because
the Real Quantity is expected which is 30)

This is why this fix is required.

opw:660658

According to PEP302, the signature of `Finder.find_module` should be 
`find_module(fullname, path=None)`.

Ever since it was introduced in 64ec5f36 the addons import hook 
defines the second parameter as mandatory, which is an issue for
systems relying on the specified behaviour (and not needing to
provide a path) like the stdlib's `pkgutil.find_loader`.

fixes #10670

Borrowing a cursor each time you access `field.digits` may be costly, because
of the connection reset.  Moreover, in most cases, the cursor is not used at
all, since the decimal precision are kept in cache.

For the installation of module `product` with its demo data, the number of
cursor allocations was reduced from ~1500 to about 50!

Usually when setting up a POSBox you want it to have a static IP. The
best way to do that is by configuring whatever DHCP server is
used (usually just on the router) to always assign the same IP to a
certain MAC address (naming depends on what is being used, sometimes
it's called static DHCP but it's also known as DHCP reservations and a
bunch of other names).

The process of setting this up is complicated for a non-technical user,
and this attempts to make it a little bit easier to do by immediately
giving them the correct MAC address they should use. To avoid confusion
this only prints the MAC addresses for interfaces which have an IP
address.

With 003d85bc instead of getting the name of the relation
field_relation we get field_relation/id which will get us an xmlid
instead.

But the data about related fields are not gotten all at once when
opening the export modal. They are gotten by clicking on the arrow of
the related record.

It is in this data that the /id will be appended for the field, but when
getting a saved export list, this data may not be available.

This commit immediately add the `/id` when a field is put in "Fields to
export" column, so this inconsistency is no more.

closes #10640
fixes #10327
opw-665994

Backport of revisions
 - 100d604c
 - ddd3e08f
opw-667814

Traversing new records in a different cache requires that all new records on
the path are copied across caches.  Make the copy across caches recursive when
the first record on the path is a new record.

Copy the structure of the sale order report regarding the
partner, invoice and shipping address.

Besides, on a repair order, this is possible
to set a shipping address without setting
an invoice address (if no invoicing is set).

In such a case, the `Invoice address:` must be hidden.

opw-666506

context -> context=context in writes within validate.
This is required for super().write with new api.

Closes #10645

With:

Two companies 'Company A' & 'Company B'
Sequences for SO & PO for each company
so_from_po set to True on 'Compny B'
When:

Company A created a PO with Company B as supplier, and validated it,
An error is raised "Configure correct warehouse for company(Company B)..."
The field warehouse_id is required on the SO, so force the user to set one in
the configuration of the company

Who has eaten the s ?

This is possible to unreconcile and then remove journal
items associated to `account.voucher.line`.

When it's done, the voucher is within a corrupted state,
with debits and credits lines without journal item, which
is required.

Because the journal item of this line is empty,
while required, this is no longer possible to use
the "Unreconcile" button, because the form is invalid.

In order to allow to unreconcile a posted customer/supplier
payments with missing journal items, we set
the journal items as required only when the payment
is within the `draft` stage.

opw-667232

Because otherwise a user who has access to a view displaying
supplier_invoice_count will get an access error if he doesn't also have
access to purchase.order, even if that wouldn't have been displayed.

opw-666935

account.bank.statement.line has a journal_entry_ids field which is a o2m
to account.move. During confirmation of bank
statements (button_confirm_bank()) this o2m field is heavily used. When
a database has a lot of account.move records this lookup starts taking
up quite a bit of time. As an example, on a locally duplicated customer
database with ~700000 account.move records attempting to resolve
journal_entry_ids of an account.bank.statement.line record was observed
to take > 1 second. This index improves it to be < 5 milliseconds.

This is especially important when big POS sessions have to be closed,
because those will contain a lot of account.bank.statement.line records.

opw-665309

When editing a form with the arabic language, the date is formatted in
arabic. But the version of the Moment.js library we use for this had
inconsistencies and parsing the arabic date could not work.

Hence, saving would not work since date field values would be invalid.

This commit cherry-pick http://momentjs.com/ commits which solves that:

  from version 1.8.4: https://github.com/moment/moment/commit/c9023b5
  from version 1.9.0: https://github.com/moment/moment/commit/bd328d5

closes #10634
opw-660453