Closes #11888

Closes #10997

Closes #11070

Closes #11940

Closes #11488

Use case:
-enable multi currency (use UDS as company currency and EUR as secondary currency)
-create account account in a different currency (EUR)
-create journal for the bank account in EUR
-create a new tax included tax
-create a new bank statement in EUR journal and add one line
-reconcile
-Choose a counterpart with the included tax and click on reconcile

Before the fix:
After reconciliation the amount_currency for tax and expense were wrong.
You could check this in the journal items linked to the bank statement.

Video:https://youtu.be/678rFb4OE2Q

opw:680693

* Always change the uuid of a duplicate database by default
* Clearer message when restoring a backup

when there are too many unreconciled entries, showing dashboard is really slow, switch the computation of unreconciled entries to SQL

[FIX] account: fix condition to create exchange_rate_entries, in some case we don't want to create one

Typically when sum(debit) = sum(credit) and sum(amount_currency) = 0

When grouping result the BaseModel method _read_group_fill_results add
the possible groups which had no result.

But, if the order of the group is not consistent, we can get really
wrong results. The code logic is expecting that the grouped result
gotten and the list of groups (returned by _read_group_stage_ids of
crm.lead) is in the same order.

If the _order attribute of the model is not enough specific (as was the
case in crm.stage) the inconsistent order would kill aggregation values
(displaying 0 instead of what should have been present).

opw-680952

[FIX] account: on opening of bank statement reconciliation widget, don't make automatic reconciliation if we have only one open invoice but also an unreconciled payment line (blue line) with the same amount

[FIX] account: in bank statement reconciliation widget, searching on a given amount now also return blue lines with that amount (previously it was only looking on payable/receivable lines)

Before this revision, this was not possible to write
`statment_id` on multiple journal items at a time,
as the condition:
`if 'statement_id' in vals and self.payment_id:`

required `self` to contains only one record

The dates in the Partner Ledger have to be in the date format language
used by the user.

opw:678575

On the cancelation of a bank statement line
reconciled with journal items created
by the registering a payment, in addition to unbind
the move with the statement line, the statement must be
unbind from the move, and the payment must be reset
to posted.

opw-680128

In v8, the field "Order Reference" was part of the "Import-Compatible
Export" fields. This is not the case anymore in v9 since the field is
always read-only.

The fix uses the same logic than v8: dedine the field as non-readonly
for state "Draft" in the model, but always set it to readonly in the
view.

opw-676095

Closes #12398

In some cases, several barcode widgets can be found on the same page.
This is for example the case of the stock picking: there is a widget on
the `stock.picking` model (main view) itself, and a widget on the
`stock.pack.operation` model (modal view).

In this case, when the focus is not set directly on the field which
needs to be filled in, both widgets will trigger a `barcode_scanned`
scanned event. This will call the `on_barcode_scanned` Python method
which can lead to errors/warning. For example, the `on_barcode_scanned`
method on the `stock.picking` model raises a warning in case the barcode
scanned does not match any product/package.

The fix is to make sure that the event target is located in the correct
DOM element.

opw-677506

Closes #12402

From #12402

To recompute the depreciation board the last depreciation date must be
taken.

opw:679212

The field was removed from the form view at af9d21b3 during a refactoring but
was forgotten in the tree view.
It makes no sense to display a field that the user can not change.

The same field was already invisible on the product.product tree view since
43977deb.

Make it invisible instead of removing it to avoid breaking potential xpaths.

Fixes #12418

The changes in `l10n_es` [1] have been ignored. They will be ported to
the new accouting later.

[1] See 730890f3 and e3e5cfe8

# Conflicts:
#	addons/account/i18n/bs.po
#	addons/account_analytic_default/i18n/lo.po
#	addons/account_analytic_plans/i18n/lo.po
#	addons/account_bank_statement_extensions/i18n/zh_CN.po
#	addons/account_cancel/i18n/ca.po
#	addons/account_check_writing/i18n/zh_CN.po
#	addons/account_payment/i18n/bs.po
#	addons/account_test/i18n/zh_CN.po
#	addons/analytic/i18n/te.po
#	addons/auth_ldap/i18n/pl.po
#	addons/auth_oauth/i18n/bs.po
#	addons/auth_oauth/i18n/pl.po
#	addons/base_geolocalize/i18n/uk.po
#	addons/base_import/i18n/pl.po
#	addons/base_import_module/i18n/pl.po
#	addons/base_setup/i18n/bs.po
#	addons/claim_from_delivery/i18n/zh_CN.po
#	addons/crm_claim/i18n/zh_CN.po
#	addons/crm_helpdesk/i18n/zh_CN.po
#	addons/crm_partner_assign/i18n/pl.po
#	addons/crm_profiling/i18n/zh_CN.po
#	addons/crm_project_issue/i18n/ca.po
#	addons/email_template/i18n/ca.po
#	addons/email_template/i18n/zh_CN.po
#	addons/event/i18n/da.po
#	addons/event_sale/i18n/da.po
#	addons/google_calendar/i18n/bs.po
#	addons/google_drive/i18n/bs.po
#	addons/hr/i18n/cs.po
#	addons/hr_expense/i18n/sv.po
#	addons/hr_holidays/i18n/pl.po
#	addons/hr_payroll_account/i18n/zh_CN.po
#	addons/hr_recruitment/i18n/ja.po
#	addons/hr_timesheet/i18n/tlh.po
#	addons/hr_timesheet_sheet/i18n/fr.po
#	addons/im_chat/i18n/bs.po
#	addons/im_chat/i18n/da.po
#	addons/im_livechat/i18n/bs.po
#	addons/l10n_be/i18n/pl.po
#	addons/l10n_be_intrastat/i18n/es_DO.po
#	addons/l10n_be_intrastat/i18n/lo.po
#	addons/l10n_be_invoice_bba/i18n/ca.po
#	addons/l10n_be_invoice_bba/i18n/lo.po
#	addons/l10n_eu_service/i18n/mk.po
#	addons/l10n_in_hr_payroll/i18n/zh_CN.po
#	addons/l10n_multilang/i18n/zh_CN.po
#	addons/l10n_th/i18n/zh_CN.po
#	addons/lunch/i18n/bs.po
#	addons/lunch/i18n/pl.po
#	addons/lunch/i18n/sv.po
#	addons/lunch/i18n/th.po
#	addons/marketing/i18n/te.po
#	addons/marketing_campaign/i18n/zh_CN.po
#	addons/marketing_campaign_crm_demo/i18n/pl.po
#	addons/membership/i18n/zh_CN.po
#	addons/mrp_byproduct/i18n/ab.po
#	addons/mrp_repair/i18n/pl.po
#	addons/mrp_repair/i18n/sv.po
#	addons/note/i18n/zh_CN.po
#	addons/pad/i18n/pl.po
#	addons/payment_buckaroo/i18n/pl.po
#	addons/payment_ogone/i18n/pl.po
#	addons/point_of_sale/i18n/bs.po
#	addons/pos_discount/i18n/bs.po
#	addons/pos_restaurant/i18n/bs.po
#	addons/procurement/i18n/ja.po
#	addons/procurement/i18n/sv.po
#	addons/product/i18n/bs.po
#	addons/product_expiry/i18n/hr.po
#	addons/product_expiry/i18n/sv.po
#	addons/product_extended/i18n/sv.po
#	addons/project/i18n/ja.po
#	addons/project_issue/i18n/ja.po
#	addons/project_issue/i18n/zh_CN.po
#	addons/project_issue_sheet/i18n/zh_CN.po
#	addons/purchase/i18n/bs.po
#	addons/purchase/i18n/ja.po
#	addons/purchase/i18n/nb.po
#	addons/purchase/i18n/sv.po
#	addons/report/i18n/fr.po
#	addons/report/i18n/pt_BR.po
#	addons/report_intrastat/i18n/sv.po
#	addons/sale/i18n/bs.po
#	addons/sale/i18n/ja.po
#	addons/sale_crm/i18n/fa.po
#	addons/sale_layout/i18n/zh_CN.po
#	addons/sale_service/i18n/lo.po
#	addons/sales_team/i18n/zh_CN.po
#	addons/stock_account/i18n/ja.po
#	addons/stock_account/i18n/sv.po
#	addons/stock_picking_wave/i18n/lo.po
#	addons/subscription/i18n/zh_CN.po
#	addons/survey/i18n/mk.po
#	addons/survey/i18n/pt_BR.po
#	addons/warning/i18n/lo.po
#	addons/web/i18n/lo.po
#	addons/website_blog/i18n/bs.po
#	addons/website_blog/i18n/ja.po
#	addons/website_crm_partner_assign/i18n/pl.po
#	addons/website_crm_partner_assign/i18n/zh_CN.po
#	addons/website_event/i18n/da.po
#	addons/website_event/i18n/zh_CN.po
#	addons/website_event_sale/i18n/da.po
#	addons/website_event_track/i18n/da.po
#	addons/website_event_track/i18n/ja.po
#	addons/website_event_track/i18n/zh_CN.po
#	addons/website_forum_doc/i18n/zh_CN.po
#	addons/website_hr_recruitment/i18n/da.po
#	addons/website_hr_recruitment/i18n/ja.po
#	addons/website_mail/i18n/fr.po
#	addons/website_mail/i18n/ja.po
#	addons/website_mail_group/i18n/zh_CN.po
#	addons/website_quote/i18n/bs.po
#	addons/website_sale/controllers/main.py
#	addons/website_sale/i18n/bs.po
#	addons/website_sale/i18n/fa.po
#	addons/website_sale_delivery/i18n/zh_CN.po
#	addons/website_sale_options/i18n/lo.po
#	openerp/addons/base/i18n/bs.po
#	openerp/addons/base/i18n/ka.po

This reverts commit a0eb172c and thus
allow to actually use the longpolling feature.

The commit was made originally to better follow the debian packaging
guidelines.

A better solution will be implemented for v10: removing the `openerp-gevent`
script to replace it with a special argument in `odoo.py`.

There is still a dependency issue as we need psycogreen but this dependency
is not met in debian wheezy. This will be made a hard dependency for v10 as
it is available in debian jessie.

opw 678334

Cancelling a statement line should not remove the
according journal items if they are associated
to an `account.payment`.

In this case, this should simply remove
the `statement_id` of the move lines,
and unmark the `account.payment` as
reconciled.

opw-674896

[FIX] anonymization: default anonymization fields

res_partner.name was twice : remove one
res_users.name doesn't exist (now, it use the partner name) : remove
remove training.* fields that do not exists

Closes #11806

[FIX] anonymization: allow anonymization on HTML fields

Was missing in the (old) list of fields

[CLA] Sign CLA of leblanc-simon

Done at #11806

All the information about the taxes must be displayed in the  confirmation page.

opw:679316

Source: http://lh.2xlibre.net/locale/sv_SE/ (p_cs_precedes)

Closes #12414, related to #12350

[FIX] account_voucher: allow the web client to catch the warning instead of returning the whole traceback

Actually, it was a Python ``Warning`` exception that was returned, and
not an ``openerp.exceptions.Warning``, that is an alias of ``openerp.exceptions.UserError``.

All actions of the database manager redirect the user after an action except the
backup option which returns an octet stream.
Close the modal after form submission to mimic the same behaviour.

Do not close the modal for other actions than database manager to avoid waiting
time for create that may be long to process.

Add message to warn the user about backup waiting time after cliking on submit
to be less confusing for big databases that may take a lot of time to be ready.

Fixes #10803

On an editable list view, an issue occurs with the following procedure:
- Click "Add an item", write something
- Press "Enter" key --> a new item is added, write something
- Click outside of the list, then click on the last item created
- Press "Enter" key --> the cursor is set at the beginning of the list

This is an issue for two reasons. First, the behavior is not the same if
we have clicked outside of the list before pressing "Enter", which is
not logical. Then, in some undetermined cases, the focus can be lost
then retrieved on the last record. It means that suddenly, the cursor
goes back at the beginning of the list without notice.

The latter issue is problematic when batch-encoding data, for example
encoding the lot numbers of incoming products thanks to a scanner.

opw-680758

Improves 8049d1e8 for other detected
cases, e.g. on Firefox + OSX.

opw-680347

The method `get_products_accounts` obviously requires
a fiscal position browse record for its `fiscal_pos` parameter:

```
    @api.multi
    def get_product_accounts(self, fiscal_pos=None):
        accounts = self._get_product_accounts()
        if not fiscal_pos:
            fiscal_pos = self.env['account.fiscal.position']
        return fiscal_pos.map_accounts(accounts)
```

But the method `product_id_change` called it with a fiscal
position id, through its own class method `_get_account`

This probably happened during the merge at revision
75d7bbb4

which has not been correctly rebased on the acounting 9.0
revision
c04065ab

opw-678735

* Fixes a bug that prevented the system to fetch the default provider
because the default_get call was wrong (wrong model + missing
company_id kwarg)
* Displays the amount as a monetary widget (to do that, the amount
must be sent as a float in the controller)
* Display the acquirer 'pre_msg' field to display eventual fees

When no `partner_id` was passed to `render()` and the acquirer
had a fees computation method, (e.g. Paypal), it would crash.
Could happen when coming through the /website_payment/pay
controller, for instance.