Another fix should probably be build for purchase price, but it isn't that easy, we need to know the partner to which the product has been purchased, as taxes are partner/country dependent.

Besides, included taxes in purchase prices happen less often.

Default Currency for Malaysia is MYR (Malaysian ringgit), not MXN (Mexican peso)
Fixes #4193

In some cases when the move was partially reconciled, the amount of the move wasn't added to the total
This is related to rev. abe5c803

When composing an email based on an email template, some parts of the template
(the result of name_get on fields) were not translated.
This was due to missing language in context when rendering the template.
Fixes #3708, opw 617309

When sending a message with the "Compose new message" button on the right of the user menu, in the top bar, if you tried to save the message as template, you had a traceback because model field of email.template is mandatory, but was set to True because there is no model in such a case.

As there is no any relevant model in such a place, and that the field is mandatory, mail.message is pretty convenient as the default value.

Potentialy, the timezone too.

On item action click (such as menus in More.. and Print..), the data in form view had the priority on user context (through the sidebar_eval_context)

Therefore, if a field "lang" was present in the form view (like in partner form), the web/action/load xmlrpc call was using the partner language instead of the user language.

Example of wrong use case before the fix:
 - Set the user language in French, then go to a partner form of a partner with English set as language
  - Click on any button of the partner form, such as the "Invoices" button, notice that the last item of the breadcrumb is in English, instead of Frenh (the user language)
  - Click on any menu opening a wizard in the More.. dropdown menu, notice that the wizard title is in English instead of French
  - Print any report from the Print dropdown menu, notice that the report file name is in English. If you print the same report for the same partner but from the list view, the report file name is in French.

The destruction of one2many fields is forced with the event change:effective_readonly
This revision add the forced destruction for cancel(discard) button as well

Otherwise, one2many fields are not properly destroyed when hitting the button "discard" (from save or discard).
This can be problematic for one2many editable list views (such as invoice lines) if you discard while having a mandatory field not filled in the invoice line: You can't recreate an invoice, the one2many editable list is messed up

Use case: Create an invoice, create a line, leave the description, required field, empty. Then, discard. Then, click on create.

opw-616946

See https://github.com/ether/etherpad-lite/issues/1116

Check if id is valid by searching record columns when a key error is raised
If the record has the column, the key error is actually an error on a
missing or inaccessible id.

Signed-off-by: Sandy Carter <sandy.carter@savoirfairelinux.com>

Closes #3658

Add invoicing related fields on anlytic account tree view for the invoicing group only
Otherwise, when a user not having the invoicing access rights displays the analytic account list, he gets an access right error.

opw-619485

Recompute the name_template field if the template changes.

backport of 41628fc7 + f25c5d85 to 7.0 plus some optimisations in triggers
Fixes #3277

When the list view is grouped, the page count should be hidden as irrelevant.
However if it's fully hidden, the limit can no longer be changed.
Instead of hidding the pager, this commit hides the arrows and replaces
the content by the current limit to allow to be changed.

Fixes #3973

The average price computation is now deduplicated and moved to
a separate function called in stock_move action_done.
This makes sure it is always called when a stock.move is
processed, even without going through the partial picking wizard.

Fixes #2991
Closes #3949
OPW-615491

If a special period is present, it must be selected fist
Fixes #3946

Reminder emails are generated based on the list of attendees.
The email_to field used to be a string with a list of emails separated by spaces
while the comma is the valid separator (RFC2822).
Fixes #3933 #3784 #2033

See issue #3964 for more detail.  Main problem was caused by commit
f0e331e0.  It set the key name+'__display' to false when reloading
a record for all field types, but it was only concerned with many2many.

Invoice control field was invisible, and we cannot change value if none selected or copy picking in.
Fixes #3636

When deleting a partner with some contacts, if the contacts had selected
the "use parent address" checkbox, the address of the contacts was stucked in
readonly mode (no checkbox to disable it).
Disable use_parent_address for orphan partners.

Fixes #3611 #3613

Remove the intermediate rounding inside _compute_qty(), as it
is not necessary after rev. fa2f7b86 and has undesired side-effects.

An extra float_round() operation inside _compute_qty()
had been added at rev. 311c77bb to avoid a float representation
error in UoM factors that could bias the ceiling() operation
done as the last conversion step.

Example 1:
Dozen has a factor of 1/12, which was previously stored in the
database with a decimal accuracy of 12 significant decimal digits.
This meant the factor was exactly stored as 0.08333333333333.
When reading this back into a Python float, the precision was not
sufficient, and the UoM conversion of 1 Dozen to Units gave a
result of 12.00000000000047961...
After the final ceiling() operation to Unit's rounding, the
converted value ended up as 13.

This problem was initially solved using an extra rounding.

However at revision fa2f7b86 the decimal precision used to store
UoM factors was increased to preserve all significant digits.
This added the extra precision necessary to read the Dozen factor
back into an accurate float value of 1/12, and the conversion of
1 Dozen now gives 12.0 Units, even without the intermediate
rounding operation. (Works for other factor values too)

At the same time that extra rounding operation has undesired
side-effects, as it requires a fixed precision derived from
the rounding precisions of the UoMs. But there is no given precision
that would work in all cases for this intermediate value. It is
always possible to find a valid combination of UoM roundings
that breaks that intermediate step, e.g. by forcing integer
roundings.

Example 2:
Let Grams have a rounding precision set to 1 because no smaller
quantities are allowed, and Kilograms a rounding of 0.001 to allow
representing 1 Gram. (gram factor = 1000 and kilogram rounding = .001
by default)
If we try to convert 1234 Grams into Kilograms, the extra rounding
introduced in 311c77bb will cause a rounding of 1234.0/1000.0 at
the precision of Grams (1), which gives 1.0 as a result.
The net result of this conversion gives 1234.0 Gram = 1.0 Kilogram,
while the correct result (1.234 Kilogram) is perfectly compatible
with the UoM settings.

Similar errors could be triggered with various rounding settings, as
long as the intermediate rounding needs a finite precision.

Two extra tests have been added to cover Example 1 and Example 2.

--
Related to #2072, #1125, #1126, #2672
Closes #2495, #2498

The name_get of res.partner.bank uses the format_layout to generate the name
of the bank. As every field is not required, we may get 'False' in the name.
Replace these missing values by an empty string.

Fixes #3590

prodlot_id field may be required due to constraint `_check_tracking`.
When a stock.production.lot is deleted, the constraint on linked stock.move is
not checked. To avoid inconsistency, restrict the suppression.
To allow the modification of existing stock.move, remove the states attribute on
the field definition.

As removal of serial may impact the traceability, it makes sense on buisness
point of view to force the modification of previous stock.move, even if the
constraint would not have been violated.
The list of linked stock.move is present on the serial form view making
the operation easier.

Fixes #3560, lp:1176912

the update of sale.order margin field was trigger with the margin stored field of sale.order.line: This cannot work with the old api

Fixes the issue #1216 (follow the link for more information). The issue
was caused by a hack in list view: the magical suffix __display is used
in render_cell to determine if a many2many field should be updated. This
commit simply makes sure that old many2many fields + __display keys are
cleared.

A better way would be to redesign/refactor the list view to avoid that
hack in the first place.  But this would be a much more complex task.

if the bom is phantom and has no line, we attempt to find a new bom with the default product uom
This is possible that we find the same bom that the current one
In such a case, we must not explode, to avoid recursion.

Fixes #3879

If a company contact (a partner with a company set as parent) had invoices, and the company of this contact was duplicated, all the invoices lines were duplicated,  on the original invoice moreover (new lines were added on existing invoices)