When trying to merge partners, an sql error may be violated (e.g. unique constraints).
In this case, catch the error and delete the problematic record as it will no longer be relevant with the old partner and left unconsistant data in the database.

The domains in the form ('o2m_field', operator, False) do not use the orm but convert the domain to ('id', 'invert operator', [list of ids]). This means that the orm is not used and implicit filter (active=True) or access rights are not checked.
A proper fix in master should be done to use the orm instead of an SQL query.
This patch force a search to be made on product.product and then exclude the products where active=False (opw 607602).

[IMP] email_template: add a lambda function to allow a user to format a date from a template mail into a specific timezone, and/or in a specific format.

Eg: ${format_tz(object.name, object.employee_id.address_id.tz,'%m/%d/%Y %H:%M')}

[FIX] calendar/crm: Add active_id (if in model partner_id) in defaults values from partner_ids when we creates a new meeting.

Bug was that when you click on meeting button from a res_partner form (Customers in menu), the button overwrites the context to use the active partner as a default in the calendar meeting. By consequence, the context overwritte the default partner who are the creator. Now the context could be removed from action and that is in get_default for partner_ids (from model calendar_event) that we add the creator AND the active_id if from a model res_partner.

[FIX] payment_paypal: SUPERUSER_ID removed by inadvertence in 1826f6d4

To avoid access denied errors for portal users

It wasn't possible to create claims as a portal user when the portal user had a parent_id

Without clear tag total amounts breaks sheet layout.

The onchange_product_id method used to only change the description if the stock.move is not saved yet. That does not make much sense.
opw 607347, bug lp:1314700

The name_search was hardcoding ilike operator while it could be different. This means that a name_search "name != Agrolait" would return accounts with agrolait.
A side effect of this was the impossibility to import account_analytic_account whose parent is a substring of another - opw 607315

Avoid to get company names such as "L'abc" to be transformed as "L'abc" opw 607221

As the survey hardcode lot's of views and reports in python, we do not beneficiate from automatic timezone conversions in the webclient.
Hopefully this is fixed in v8 after refactoring of the survey module. opw 608786

On child partner creation of a parent partner, the commercial_partner_id is not computed (and stored) in the create method.
Therefore, we should compute the commercial_partner_id before trying to sync his data

The method  _paypal_form_get_invalid_parameters checks that the params passed by the paypal feedback coroborate with the transaction requested by Odoo.

It looks like the 'receiver_id' is not always passed by the paypal feedback. Therefore, we check this param only if it is available in the paypal feeback.

This issue had as side-effect to not validate the paypal transaction, which remained 'draft' permanently.

Fixes an error introduced in f6fb2b69

If any missing or partially incorrect values cause
an exception other than a psycopg2 error, we should
still catch it, rollback that record and report
the error, rather than letting bubble and fail
without any feedback to the user.

Fixes #1485

When we compute the discount of a product to display (result of product_id_change), we compare prices in the currency of the product while we expect prices in the currency of the pricelist. opw 606188

When a record is created, the magic fields (id, create_date,...) are first removed from the vals as the user should not set a value for these.
However if a value for this is given in default value (e.g. defined in an ir.value), the creation would crash (sql error : column specified more than once) as the magic column would be added again.

Same behavior than in saas-5

These parameters are (or should be) irrelevant for
a search_count(), and they could actually break the
result or make it significantly slower (e.g applying
`order` on large tables).
This fixes a performance regression introduced by
0f43032b.

We could also raise an error offset/limit are
passed in combination with count, but that seems
unnecessary.

Also switched to "SELECT count(1)" for the count
query, as it is simpler and just as fast.
We'd get the same perf with * or any constant value,
as in "SELECT count('me in')", but let's keep it
simple ;-)

Same as for rev 4bad513d, the references were not correctly parsed, added missing regex

and without spaces for vat