[REF] Packaging: backport of a7ab5a41
[REF] Packaging: backport of a700a113
[REF] Packaging: backport of 9d0bd280
[REF] Packaging: backport of b0722d3e
[REF] Packaging: backport of 24b2c938
[REF] Packaging: backport of e874cdaf
[REF] Packaging: backport of 56b61da1
[REF] Packaging: backport of be96dd85
[REF] Packaging: backport of 50a4da99
[REF] Packaging: backport of 1c41f369
[REF] Packaging: backport of cc113317
[FIX] Packaging: backport of 13471630
[REF] Package: backport of 93845d68
[REF] Package: backport of 012bc01c
[FIX] Package: partial apply of d9e72a37
[REF] Package: backport of 67036fef
[REF] Package: backport of 73de0138
[REF] Package: backport of 30d987ed
[REF] Package: backport of 29132669
[REF] Package: backport of 7db12dc4
[REF] Package: backport of f668f9c6
[REF] Package: backport of 2cf4051a
[REF] Packaging: backport of 73592487
[REF] Packaging: backport of f2598ecd
[REF] Package: backport of fd21912c
[REF] Package: backport of 9a8cdf49
[REF] Package: backport of 2f4984b8
[REF] Package: backport of 6e9edeeb
[REF] Package: partial backport of d4624fa8
[REF] Package: backport of 9f13722f

The gantt view does not have enough data to properly display a project's length
based on only the planned hours.
It also makes it impossible to change the project's length using drag & drop.
It's safer to simply display the start and end dates recorded in the project
Fixes #2632

Fixes #4269

Partners totals were not correct if the partner paid partially an invoice in advance
For an invoice of 20.000 in the future, with a payment made in advance of 5000
The column not due must contains 20.000, as the amount is not yet due
One of the column 1-30, 30-60, ... (accordingly on when the payment was made). must contains -5000
The total should be 15.000

When creating a return picking, the default invoice state is 'To Be Invoiced' if
returned picking was invoiced. However if the invoice of the picking has not
been generated yet (state '2binvoiced'), the return should also be invoiced.
Fixes #4002

Only the commercial partner (parent company) should be set in partner field of
an account.move.line.
Fixes #4261, opw 618763

Google api geolocation service returns a precise latitude and longitude, greater or equal than 5 digits
The precision is important as storing 2 digits instead of 5 can lead to an inaccuracy of allmost half a mile.

delay already being the hours amount in business hours

opw-620189

Catch only the error related to the access of the linked record.
Previous was hidding error to access the ir.config_parameter and eventual other
errors from the orm.
Uses SUPERUSER_ID to access instance URL (e.g. portal has no access to it).
Fixes #4234 #4234

This is related to rev. db98434e

rev. abe5c803 forgot some partial reconciliations when the date domain was other than BETWEEN (for instance, <= stop date or >= start date, alone, not between)
Besides, the rev. abe5c803 did not care about account move being posted or not.

rev. db98434e took several times the same partially reconciled moves lines

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

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

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)