When selectionning a saved shipping address when setting the shipping
address of an ecommerce order, the country and state should be set
accordingly.

unrelated issue noticed when testing e0d4dd01

In 1ef52c9c the code displaying state of a given country was improved
for some incompatibilities.

But, if when setting the billing informations we choose to create a new
shipping address, the shipping state* would not be displayed even when it
should be (currently, if the shipping country is Australia or U.S.).

opw-687948

*a state being a subdivision of a country

Until 9.0 our psycopg2 DSN connection strings do not allow having
spaces within the db name, and passing some can cause duplicate
registries to be loaded.

Stripping spaces is a simple workaround until we actually support
spaces within db names.

Fixes #13078

Since 9.0, `message_follower_ids` are
`mail.followers` records,
the partner are in `message_partner_ids`.

Therefore, the partner images displayed in the note kanban
were not the images of the right partners.

opw-688100

Do not force the `search_default_product_id`to the current
product variant, as the domain just above could return a
result, a BOM which is set for the template of this variant
but not for the variant istself, that this filter would hide.

This is following the revision
52cba1b5

Because of this, a product variant smart button could
display "1 BOM", but when clicking on it, none would be displayed,
which is not user-friendly at all.

opw-687912

One could want to use deferred revenue for revenues invoiced in February
but the services are provided in June (e.g.)

When the asset is created from an invoice line it should be in company currency and not in invoice currency

If `method_time` is set to end, `method_number` is not the reference for the number of depreciation lines.
Take directly the number of depreciation lines is more correct.

[FIX] account_tax_cash_basis: set the entry date for tax_cash_basis as the maximum of involved operations, instead of the reconciliation date.

Also refactored account_tax_cash_basis and account_tax_exigible to have the minimum code lines in the bugfix module

Commit 06754b32 brings an inconsistency between the PoS frontend, the
pos_order and the account_invoice tax calculation. Part of the commit is
correct since it corrects the matching between the `compute_all`
methods, however.

opw-680891

Removing a slide was buggy :
* Removing the last slide left the slide handles (and the user had to
click on remove slide again)
* There was an ugly delay before the removal
* Changing the bg image of a slide was not possible anymore once one
slide was removed
* ...

WHen checking `Dedicated Refund Sequence` in a
sale / purchase journal,
the field `Refund Entry Sequence` must be filled with a sequence.

Otherwise, later, when issuing a refund invoice, it won't be able
to generate the number of the refund invoice as it won't be able
to find the sequence to use.

opw-687839

Inconsistencies can arise between the tax calculation performed in the
PoS and in the backend (e.g. in a SO). For example:
- Unit price: 9.479
- Tax: excluded, 5.5 %
- Buy 5 units
- Round globally

In the backend, the result is 47.40 + 2.60 = 50.00
In the PoS, the result is 47.40 + 2.61 = 50.01

We make the PoS apply the same logic than in the backend. First, at the
level of the `compute_all` method, especially to use the appropriate
rounding precision before starting the calculation (so we move the
rounding of `total_excluded` after the rounding precision adjustment).
Then, by calculating the taxes amount as the difference between
`priceWithTax` with `priceWithoutTax`. This is mandatory since they
contain the result of `compute_all` in which the rounding logic has
already been applied.

opw-680891

When we drag and drop a record in a folded column, the number of elements
in this column displayed  in the column title is not updated.
This issue is present because when a record is droped in a column
its id is not added to the dataset of its new column.

To fix this, we had to add the id of the record in the dataset, and
override the method 'add_ids' in 'DataSetSearch' to have the size
of the dataset equal to the number of ids in it. We have replicated
the behaviour of the function 'remove_ids' in the new function 'add_ids'.

It is possible to put a clickable object in a vignette that opens
an action, for example the kanban_status class used in the CRM
pipeline. This thing presents an issue as it opens a wizard, but
when the wizard is closed the vignette is not reloaded.

When you click on this item, it will go through `on_kanban_action_clicked`
in kanban_record.js that will trigger up a `kanban_do_action` custom
event. The kanban_view have an handler for this custom event and
will call the `do_execute_action` method defined on the view.

This method can take a callback as its last argument that will run
when the wizard is closed. Before rev ae583ba1, the behavior was
to reload the entire kanban view but this rev tries to only reload
the kanban record. Unfortunately, it didn't use the argument
in `do_execute_action` but in a then of this method. So it
didn't work. This commit put the onclose callback at its right place.

The `geoip` is not always defined in the session,
and therefore one needs to check it's defined before
attempting to use it.

The same is done at different places in the code,
through the different modules.

opw-687783

It was doing something before but the useful line was removed at 908f4165
The method is no longer useful and can be removed.
It was error prone has it had not the same signature as the one on project.
Fixes #13402

Without the @api.multi property,
the method is considered as taking only one parameter (self?),
while it takes multiple parameters.

This prevented to change the quote template on a sale order,
if the quote template had some order lines, due to the below error

`TypeError: product_id_change() takes exactly 1 argument (19 given)`

opw-687797

Commit f30ec302 defines the messages sent thanks to the channels as
plain text. This is true for all cases but one: the notification
(e.g. @user). Therefore, the notifications links are broken.

opw-687781

As provider model is intended to be used internally restricting the read of
some private fields to the employee group avoid creating access issues.

From Odoo 9.0, en_US is not always activated in Odoo. As a fallback, if
the search for a language does not find company language nor English US,
we use the first available language (there is always at least one).

In order to reproduce this behavior, eg: you can set the language of
your company's partner to en_US, then load another language, then
disable en_US from your database. Try to open the "Accounting" dashboard
and you will get a traceback.

When consuming products tracked by unique serial number, no check is
done on the quantity consumed for a given serial number. It means that
negative quants might be created without any warning to the user.

We implement a simple warning thanks to a onchange.

opw-687129

When a model has no form defined, a default view is generated displaying all
fields of the model.
The one2many and many2many fields were not displayed on the form, probably for
aesthetic or historical (2008) reasons.

Empty merge as 7bdd4de8 has already
been forward-ported with 33167a1e.

OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal
move for the delivery to debit outgoing inventory (since the goods don't
transit by an internal stock) but the sale does credit it so there was a
build up in the holding account that has to be moved out manually.
This was also reported in #12687.

The solution implemented is to check if the invoice line is related to
sale order lines having one of its procurement_ids with a purchase_line_id
set. If yes, it means that it is a confirmed dropship and in that case we
don't call to super (we don't create the cost of sale line).

That means that:
* If the procurement is in exception at the customer invoice time, the
behavior will be as it is currently, but it's fine as you don't know how
the procurement will be solved, and it'll be only at the beginning (once
the config is done it shouldn't go in exception anymore). People will have
to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account
(received)' on supplier invoices for dropshipped goods, but rather use the
COGS directly (sounds to me logical, and that's actually why I wouldn't go
for the solution to create the stock move entries every time even for the
dropshipped goods. That, and the fact that it would pollute the accounting
with useless moves).

This is a forward-port/cherry-pick of 7bdd4de8

OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.

The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).

That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)

When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. In debug
mode, the click doesn't work anymore.

For some mysterious reason, the event is propagated to the parent. The
`currentTarget` is not the `li` element, but the parent `ul`. By
setting the `immediate` argument to `true` (execute the first function
instead of the last), this solves the issue.

Since commit 2ab68047, the Paypal link can be sent in an invoice as it
was the case before. However, in order to be able to save the Paypal
account in the accounting settings, the Paypal account must be
website-published. If the module `website_payments` is not installed,
this is not possible.

We remove this condition, since it should be possible tu use the Paypal
payment method without installing the whole website.

opw-686216

This reverts commit a57b10db. This has to be fixed in 8.0, and moreover it uses fields defined in sale only so the fix must be done in stock_dropshipping module

OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.

The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).

That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)