When installing costa rican localization the partners titles has
a wrong reference to base module that cause a warning messge in
server log. In total the localization had 8 partners titles that
not exists in base which was removed the reference and another 2
that exists in base but not had any difference.

Courtesy of Vauxoo.

Closes #15495

The field "costing method" on the product.category only appears when
the inventory valuation is set to "perpetual (automated)" which is
wrong. The user must be able to choose the costing method no matter
which inventory valuation method is chosen.

The problem is due to this commit b6a2c0a4
that changes the xml view and make the field invisible if the inventory
valuation is set to "Periodic (manual)".

This commit revert the change on the xml view and thus add again
the group attribute that should not have been removed.

In saas-14, domain selector widgets are supposed to be instanciated
with a valid domain.

The problem is that some valid domains were wrongly evaluated. Indeed,
when receiving a domain which does not begin by an operator, the
"DomainTree" widget considered there is an implicit "&" operator that
should be used. This is not enough. Indeed, when evaluating the domain
["|", A, B, C], there is also an implicit "&" despite the fact the
domain starts with an operator ("|"). Because of that, previous
implementation interpreted this domain as ["|", A, "&", B, C] while
it should have been interpreted as ["&", "|", A, B, C].

Note: in master the parsing will be improved to handle wrong domains
and be decoupled of the DomainTree widget.

When we add a SO line on a sale order with a product packaging, a
traceback is raised.

The problem comes from a default value and a domain set in the context
which reference a product template but since this rev: 796900fe
the product packagings are linked to product_product and not
product_template anymore.

So we used the product_id field instead of product_tmpl_id. And remove
product_tmpl_id from the sale_order_line model which is not used anymore

remove old modules, add new one

data file

The POS Sales Channel performs a read_group, then transforms the date
strings to datetimes, which failed when the language wasn't English.

Also fixes the formatting issue where week numbers weren't the same
between read_group and datetime by using en_GB as default lang.
(which is closer to ISO-8601 dates standards than en_US)

Purpose:
--------

In settings, When we enable pricelist then it should enable first option by default.

In the sale settings view, the field company research hasn't
the enterprise symbol though the related module is in enterprise.
It's the same problem for the Company Research option in the website
admin settings.

Both field declaration use a string attribute in the label tag.
but it is needed to use a "for" attribute. The Upgrade widgets only
put the "enterprise" span after the enterprise label, wich is found
by looking on node having a for attribute with "module_ " and its value.

This commit use an attribute "for" instead of the attribute "string"
in the label declaration.

Before this commit, when opening a field chain with a field selector
and only removing parts of it, the field selector internal "chain"
value was properly updated but not its "selectedField" value.

When using read_group() and grouping by many2one fields, the many2one groupby
fields get updated from an integer id to a tuple from name_get() at the end
of the method.

e.g.: {'user_id': 1, ...} -> {'user_id': (1, u'Administrator'), ...}

To do this, it reads the many2one field by browsing on self.

When self is a model with _auto = False (typically an SQL view), searching by
id can be costly as the id column may not have usual properties for performance
(in some cases a full computation of the table is required to look up 1 id).

Sales Group: "User: All Documents" saw half grey bottom blocks, not
matching the bottom of the graphs. Now the blocks' heights are matched.

for graphs in the sales dashboard.

Problem: Sales dashboard can contain a POS sales channel, but sales managers
do not have access to pos related models unless they are pos managers.

This commit hides the POS Sales Channel to non-pos managers.

This commit improves crm.team compute methods and adds auto_join on:
payment.transaction: field sale_order_id
sale.order: field order_line

Also move the dashboard_graph_type field in invisible in the kanban view to
avoid triggering the computation of the graph when it's not needed.

DO NOT FORWARD-PORT: a different patch will be made for the master branch

This is required since a4dc9a80

Several fixes are addressed in this commit:
- displayed value of writeoff amount now give proper result accordingly to the selection (but that selection may still be wrong!). This is still not ideal but at least it reflects what users can see in the list selection.
- exclude from the reconciliation, entries that have already the boolean 'reconciled' set to True. They shouldn't be passed to reconcile() but are still needed to balance totally the reconciliation so users have to select them.
- avoid crash if no writeoff needed on batch reconcile: Even though the wizard might declare that a writeoff is needed, in batch mode it might not be the case since the reconciliation is done in multiple passes for each currency. If no write-off is needed, no write-off move is created and the code tried to add a boolean variable to a recordset and raised a fruit-salad error (mixing apples-oranges).

This revert commit 1e67069f and correctly fix the use case it was addressing (exclude lines with debit=credit=0 in the filter).

Forward-port of https://github.com/odoo/enterprise/commit/8a55b3f9f7a7524583effb8198c03ebf695131bd

There are multiple problems with the editable view list. It should be
solved once and for all in the work-in-progress master.

This commit fixes a bug with readonly checkboxes. When a field is
readonly, the table cell gets the "o_readonly" class which changes
its style and behavior. When entering edition, the cells are hidden
except the ones with this "o_readonly" class so that their style are
not affected. The "o_readonly" cell content however was hidden thanks
to a "color: transparent;" rule to let the form readonly field show
the value. The problem is that checkboxes... are not hidden with this
"color: transparent;" rule. Also, the "o_readonly" class is not toggled
during edition while the readonly status could be... so the right fix
would be to get rid of this "o_readonly" class and let the inline form
handle the behavior, but this would affect style and possibly break
unknown behavior.

This fix adds rules to handle the checkbox case correctly.

Steps to reproduce:
Go to any pivot view (for example Sales > Report > Sales) and add
the current view to your personnal dashboard (in the search view: Favourites > Add to my Dashboard)
Go to the dashboard, traceback because $buttons was not defined.

opw:707296

In a MO, change a product in "Consumed Materials" by clicking on "Search
more...". It crashes.

Clicking on "Search more..." triggers the onchange since it empties the
line. Since there is no product on the line anymore, it crashes.

opw-705644

Closes #15408

When tax_calculation_rounding_method is configured to round_globally the
compute_all method of account.tax will not round the taxes based on the
currency. The result of the compute_all function is used when creating
the tax parts of a pos.order account.move.

Taxes are aggregated per session, so 2 orders with orderlines in them
with the same tax will turn into 1 single tax account.move.line. To
correctly handle round_globally, we round all tax values we have after
processing each order.

Fixes #14672
Fixes #14673

In revision fc813847,
`_compute_total_invoices_amount()` was assumed to
give the invoice residual within the company currency but,
in the case the payment_currency is different than the company_currency,
it returns the amount in the payment currency.

In this case, we actually need the total invoices residual
within the company currency.

The amount of the invoice in the payment currency was wrongly
computed when a change of rate in the invoice currency occured between
the invoice date and the payment date,
when the invoice currency was neither the company currency
nor the payment currency.

e.g.
Company in USD. Exchange rates:

    07/02   08/02
HKD 7.0     8.0
EUR 0.90    0.94

Invoice: 100,000 HKD, date 07/02, worthing 100,000 / 7 = 14285,71 USD
Payment: 13000 EUR, date 08/02, worthing 13000 / 0,94 = 13829,79 USD

The invoice amount within the invoice currency was computed:
100,000 / 8 * 0.94 = 11750€
While the invoice, at the time of the invoice date, worth actually
14285.71 * 0.94 = 13428,57€

When the invoice, payment and companies are all different,
the invoice amount in the payment currency must not be computed from
the amount in the invoice currency computed at the invoice date
to the payment currency, since the rate of the invoice currency
changed, and the amount in the invoice currency at the time
is no longer the same today.

In simple words, `amount_currency` of the invoice
was computed using the 7.0 rate
e.g. 100,000 / 7 = 14285,71
while, when the rate changes, computing from the invoice currency to
the payment currency, which are both different than the company currency
it will first convert the amount to the company currency, using the new rate:
e.g. 100,000 / 8 = 12500€
and then convert to the payment currency:
e.g. 12500 * 0.94 = 11750€

opw-640248

When making an inventory adjustment in multi company,
the default location_id was all the time taken from
'stock.warehouse0' even if the user was not allowed to read
the warehouse. Inspired from _get_default_location in pos_config.py

Backport of 8955d15e

opw:706704

In SQL, if there is no quote around the table/field, the result will
be returned as case insensitive.

This was causing a bug in the kanban view which was not displaying
the records because x_AA_count was named x_aa_count.

This method receives a new api context and thus should not change it
directly. The stock scheduler didn't run because of this.

opw 704764

The field "Level Name" must be translateble.

opw:706486