When both selected, these filters are expected
to display Invoices - OR - Refunds.

It was not the case, because the web client
expects to receive the domains normalized
when concatenating domains together with a
`|` statement.

Selecting both filters resulted in the below domain:

```
[
    '|',
    ('state','in',['open','paid']),
    ('type','in',('out_invoice','in_invoice'))`,
    ('state','in',['open','paid']),
    ('type','in',('out_refund','in_refund')),
]
```
Instead of
```
[
    '|',
    '&', ('state','in',['open','paid']), ('type','in',('out_invoice','in_invoice'))`,
    '&', ('state','in',['open','paid']), ('type','in',('out_refund','in_refund')),
]
```

opw-679246

endDate appeared twice in event_details

opw:678823

To apply this domain ('bom_count', '=', 0) in the product template view,
the field bom_count must be in the view.

opw:679095

The test `test_balanced_exchanges_gain_loss`
failed on Jun 6, because it created a specific rate
for today's date at midnight
(e.g. on Jun 6, 201x-06-06 00:00:00) for the test purpose,
but a rate is created in the demo data for Jun 6 midnight exactly:
`base.rateUSDbis`, making the test confused about which rate
to use.

We solve this by making the test use the rate `base.rateUSDbis`,
modifying the rate for its own need, instead of creating a new
rate.

This is similar to revision 54140331

opw-673716

Avoid the DOCTYPE tranlation. If this tag is changed, the html rendering is altered. The other effet is that the web_editor wrap the content with <span> to translate, but some explorer eject tags (doctype, head content, script, style, meta) et insert this tags in the body.
NB: DOCTYPE is not a node but a text.

The last depreciation date must be take from the last posted depreciation
line.

opw:679212

The sub-select used to fetch companies rates
was wrong in the case rates with no company set
were entered before rates for specific companies.

e.g., for USD, the below rates:
Date        Rate        Company
2016-02-13  0.721400
2016-02-25  0.738800    1
2016-02-26  0.740000    1

the sub-select returned
Rate        Start       End
0.721400    2016-02-13
0.738800    2016-02-25  2016-02-26
0.740000    2016-02-26

while it was expected to return
Rate        Start        End
0.721400    2016-02-13  2016-02-25
0.738800    2016-02-25  2016-02-26
0.740000    2016-02-26

as the rate 0.721400 ended on 2016-02-25,
since a new rate specific to this company 1 was
added at that date.

opw-678726

fixes #12280

Module sales_team was auto installed if base and mail was installed, but
this isn't wanted as it is already a depends of crm and sale modules
which should be anyway installed for sales team to have a meaning.

This could lead to a glitch with the sale apps displayed whilst it
should not be.

opw-679223

Context:
Source document on invoice created through a credit note with the modify option

Current issue:
create an invoice from a sale order,
validate it,
Create a refund with the modify option
The first invoice is reconciled with the refund
The new draft invoice doesn't have a source document and can't be reached from the SO

Expect result:
The new draft invoice should have the sale order as the source document

Rev. 93e9a4dc tried to speed up
the 9.0 name_get() of res.partner by only calling fields_get()
once for the whole name_get, instead of calling it lazily.

This may have worked for name_get calls on multiple unnamed
addresses (name is NULL), but this is a rare occurrence
in practice - while now every single name_get() call would
incur the full cost of the fields_get() call.

That fields_get() call is O(n) in the number of fields,
and there can be quite a few for res.partner.
Calling it only for the specific 'type' field can easily be
about 40x faster than without it.

And since name_get() is called for each Many2One field
of each record being read (due to convert_to_read()), reading
a batch of records with partner fields had become quite
a bit slower!

Avoiding this cost entirely with lazy fields_get() calls
saves quite a lot of time for the common cases. And now
that fields_get() specifies a single field, it is cheap
enough to be called within the loop.

Non-scientific benchmark: account.invoice.search_read() in
the list view of invoices took 500ms for 25 invoices
_before_ this fix, and 90ms after!

Not evaluated, move the condition to the button
Closes #12230

Cannot link a method before declaring it.

Closes #12057

Closes #11226

HTML content should be escaped before being sanitized. Any content (link, image,
code,...) that is acceptable in usual mail.message but should not be interprated
when posted on a comment of the forum.

Fixes #3737

If we take the below facts:
 - The country select is set as disabled
   when Shipping is set to "Ship to the same address"
 - The disable property of select inputs is
   removed when shipping is set to
   `create a new address`:
   In `website_sale.js`:
   ```
   $selects.attr("disabled", value <= 0 ? null : "disabled" ).prop("disabled", value <= 0 ? null : "disabled" );
   ```

We can safely assume that the select input "State / Province" was supposed
to be set as `disabled` in the first place, not as `readonly`

Before this revision, State / Provice was greyed when choosing
"Create a new address" for shipping, and selecting the United States
(but the select input was still usable, though, it was just greyed)

opw-675739

The field `bom_count` is added in the view for group `group_mrp_user`.
Therefore when extending the view, we should make sure to restrict the
access as well.

opw-679172

* price_average is now always positive regardless of the invoice type, because it's an average and there's no point in summing those values
* price_total is now computed by using ABS() because of a migration bug of price_subtotal_signed introduced in saas-6, where in_invoice and in_refund invoices were set with a negative value while on the help tooltip it was saying that in/out refunds are negative and in/out invoices are positive. That bug was only revealed in v9 -since saas-6 wasn't using that field at all-, with the effect of having wrong values in report for migrated databases. This workaround using ABS() will be removed in a further version with a migration script to fix people's databases.
* residual field is now negative for in_invoices and out_refunds.
* These 2 points ensure that we can group by invoice type and sum the price_total or the residual fields to get the gross income of a month for example.

Since the revision bc23c92c,
the inventory value of the produced items could
be doubled, because the list
`total_consume_moves` could contain several time
the same move ids, e.g. when it was added by
`total_consume_moves.append(raw_material_line.id)`
and
`total_consume_moves += already_consumed_lines.ids`

The list is replaced by a set to ensure a same move
cannot be counted twice.

opw-678727

The cron may no longer be present (e.g. deleted) and the subscribtion would be
blocked in running state.

Fixes #12207

When subscribing a user to a mailing list, the `mail.mass_mailing.contact`
created is processed to identify it's name and email from the address (method
`get_name_email` called in `add_to_list` and `name_create`).
For a better consistency, the search of existing contacts should also be done
using the method `get_name_email`.

This avoids that subscribing twice `Example <example@example.com>` fails to
detect duplicates and creates two subscriptions.

Closes #12265

opw:678921

Related to c6fc91b3.

fp request

When computing the amount_currency, the ratio is 1.0 if the difference
between amount(computed like this -sum([x.balance for x in move.line_ids]))
and the amount set in the statement is not greater than the currency rounding.
opw:678588

Rev. 253437f8 meant to
avoid the creation of duplicate entries during translation
import, caused by existing translations created with an
empty `module` field.

But the fix was over-zealous and caused an extra side-effect:
the creation of missing translations (the blue flag icon)
now creates duplicate translations if other translations
exist with different `module` values.
(This could happen because translations are provided by
several modules, or due to manual translation entries with
no module value, etc.)

Equivalent of 8c337f97
but for account.move.line as well.

Closes #11883