[MERGE] forward port of branch 7.0 up to de07c64

[FIX] base: delete parent partner reset use_parent_address

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

[FIX] product: remove unnecessary UoM rounding step, add missing test

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

[MERGE] forward port of branch 7.0 up to 2080ea0

[FIX] stock: on stock picking invoicing, allow to pick a journal if no move line

[FIX] base: avoid having 'False' in name of a bank

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

[FIX] stock: prevent serial number deletion on stock.move

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

[FIX] sale_margin: stored field functions cannot trigger other stored field functions

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

[FIX] correctly update many2many in listview (web client)

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.

[MERGE] forward port of branch 7.0 up to e2dd18f

[FIX] mrp: prevent recursion from phantom boms with no lines

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.

[FIX] l10n_br: remove reference to old base.group_extended group

Fixes #3879

[FIX] marketing_campaign: typo in manifest

[FIX] account: prevent invoice line duplication on partner duplication

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)

[FIX] project_timesheet: date of created analytic line not in user tz

When the user was in timezone UTC + 1, and added a project.task.work which created an analytic entry line (timsheet activity), if the datetime was set to 11/25 00:00:00, the date on the analytic line was set to 11/24, because this was the truncated stored value(UTC Time), which was 11/24 23:00:00

[FIX] product: creation of reference uom

Set a default value for factor when creating a new uom.
Could not create a new UoM with type reference (if creates a reference uom, no need to pass a factor).

Change the readonly filter to (type = bigger) to make the field writable for reference uom.
This is needed to force the reset of the factor when switching of type (onchange_type).
As the field was readonly, kept the old value for factor.

[MERGE] forward port of branch 7.0 up to 529e920

[FIX] mrp: perform location chaining for kit exploded moves

This rev. 7307227 ensured to not (re-)set the state 'confirmed' to exploded moves with a more advanced state (for instance, 'assigned')
Nevertheless, the location chaining is performed on the move confirmation, through the action_confirm method of the stock.move model. Besides, the resulting moves of the _action_explode method had the state 'confirmed' on creation, the 'confirmed' state wasn't set by the method 'action_confirm', meaning that the moves were confirmed without having the location chaining done. Allowing moves to go through the action_confirm method even if the state was 'confirmed' or further triggered the location chaining.

Preventing already confirmed moves to go through the action_confirm method prevented the location chaining, thus.

We now create the resulting moves with the 'draft' state, and then confirm them through the procurement workflow signal 'button_confirm'. Thus, the resulting moves are confirmed by going through the action_confirm method, writing the confirmed state and triggering the location chaining at the same time. We then write the 'assigned' state if necessary.

opw-617235

[FIX] point_of_sale: fix point of sale sequence declaration, github issue #3218

[FIX] account: do not duplicate analytic lines on analytic journal duplicate

[MERGE] forward port of branch 7.0 up to 922a52d

[FIX] web: date autocompletion should not harcode 'date'

But should use date or datetime according to the widget type

This fix is related to 69d60465ee67969d72210a61a9e23204d037378a

[FIX] purchase: keep PO currency on picking

The delivery of a purchase order was not keeping the currency and cost price
from the purchase order for the reception. This was problematic for orders where
the invoice was generated from the picking (Invoicing Control: Based on incoming
shipments). The currency of the purchase order was kept while the cost was the
one in the company's currency.
It's better to keep the currency of the purchase order to make the invoice as
it's usually the one expected (and not convert everything to the currency of the
company). opw 615555

[MERGE] forward port of branch 7.0 up to da15c9d

[FIX] web: do not set the one2many dirty on field validation

This rev. 06104ba553702b16878d52c5b8ab089355216a5e

Added the dirty flag on the o2m field when the editor of the editable list was enabled (meaning that the editable list has been altered)) because the dirty flag was not set correctly by the one2many during the edition, at the time.

It looks like this is now the case

Besides, as now, we valid all the editable list of the form, wether or not the editable list was altered, we must not set the o2m as dirty anymore.

[FIX] point_of_sale: missing multi-company rule

[FIX] product: more accurate name_search

First, name_search searches on default_code, then, if the limit is not reached, it searches on the product name
The results found from the default code search must be removed from the search domain when doing the search on the product name, to avoid having results already found by the search on the default_code

opw-618015

[FIX] stock: multicompany reception

When a picking is confirmed, the generated account.move(.line) should take the
company, accounts, journals and period with the same company as the picking,
not the one of the current user.

This was problematic if a user in a company confirm a picking linked to
a purchase order done in another company.
For real time valuations, the generated accounting entries were mixing both
companies.

Fixes #3466

[IMP] purchase: error message linked to product, not company

[IMP] Speedup test account_assert_test.xml in account

[FIX] web: date autocompletion should use user's locale

search bar does not suggest date field format based on user's locale and always shows based on mmddyy using Date.parse,  opw:615276

Note: starting in 9.0, datejs has been replaced by momentjs, so this
problem should be solved in a better way.

Merge pull request #3220 from odoo-dev/7.0-opw-615322-rgo

[FIX] point_of_sale: fixed rounding issue for pos order when discount ad...

[MERGE] forward port of branch 7.0 up to ab5ecef

[FIX] project_timesheet: accept work without date

date field on a project.task.work is not required while it is on the hr.analytic.timesheet (with default value).
Avoid error if fill a task work without date, fallback on context_today.

[FIX] mrp: prevent suppression of bom if used in mo

The field bom_id is required on a manufacturing order and deleting a mrp.bom would block the current mo.
Restrict the suppression for manufacturing order in progress.
Fixes #3417

[FIX] project_timesheet: missing timesheet for tasks without project

Timesheet activities (hr.analytic.timesheet) are generated when a work activity (project.task.work) is logged on a task.
These are updated if the project of the task is modified.
This patch applies the same behaviour for tasks without project, the timesheet activities are generated once a project is set on the task.
To avoid redundency in the code, extract the computation in a distinct method.
Fixes #701, opw 609481

[IMP] stock: added missing 'context' parameter (opw 616952)

[FIX] hr,mail: correct remove of suggestions.

[MERGE] forward port of branch 7.0 up to ae99a93

[FIX] web: many2many_binary widget upload

once widget extended with ReinitializeFieldMixin, the event binding with the binary file input and the on_file_change method can be done in initialize_content instead of start

This fix is related to d36c8b5c9bf7ab9215bc63db6ee49bec5e5b225b

[MERGE] forward port of branch 7.0 up to d36c8b5

[FIX] web: FieldMany2ManyBinaryMultiFiles must extend ReinitializeFieldMixin

The add attachment button should be displayed while being in edit mode, but not in view mode
As the widget depends on the form actual mode, the widget should be re-rendered each time the actual mode changes

This is the point of the ReinitializeFieldMixin class

[FIX] account_asset: moves should use the depreciation line date

[MERGE] forward port of branch 7.0 up to 3e3e35e

[FIX] web,web_kanban: correct radial-gradient usage

[MERGE] forward port of branch 7.0 up to 65d92da

[IMP] *: one Makefile to rules them all.

Create one unique generic Makefile to compile sass files.

[FIX] base: incorrect code and locale for Bosnian

Stems from prebiblical commit f083aa2.

Fixes #3480

[MERGE] forward port of branch 7.0 up to cb91966

[REVERT] 056c06570c741fab1515978a957766b0a77bd80a and a5cf71973916f3e9b6ea578a614c76b0b34689d8

[FIX] account_asset: asset depreciation should use the correct dates

fix a5cf71973916f3e9b6ea578a614c76b0b34689d8

[FIX] account_asset: move lines should use the depreciation line date

opw-616843

[IMP] account: (over)due payments report

The report includes all due payments, not only the one after the maturity date.
The maturity date is displayed in the report so no confusion is possible for payments below the maturity date.
Fixes #3064

[MERGE] forward port of branch 7.0 up to cd69dee

[FIX] web: inhibit on change flag when validating editable list

To valid all editable list line, we iterate on the lines and set the editor form with the line value, using set_value.
The _inhibit_on_change_flag should be set to True to avoid triggering on changes events

opw-617395

[FIX] mrp: chain product move and MO locations

When validating a SO containing a `make to stock` + `manufacture` product
(with bom + orderpoint), we have the following stock moves:
* Product move
* Manufacturing order
Selling 1 such product would yield 2 as incoming quantity, an
inconsistency that this commit solves by setting the location_id of the
product move to the MO's location_dest_id (in the same fashion that
the create_pickings method does in an mts/buy case)

opw-616229

[MERGE] forward port of branch 7.0 up to 9a37e5a

[FIX] web: regard the view_list has valid if not yet loaded

This fix is related to df845940ed52040ef92b1b5759306c556fa38e66

Fixes #3469

[MERGE] forward port of branch 7.0 up to be7c894

[FIX] web_kanban: wrong condition to reset the dataset index

This is related to rev. a218a9ed3f6c965820f2ebdf76ee0e6c89c59a0c

The condition is good, but not in the right place: It should be done once all read_slice (all columns records) are fetched, not at each read_slice end

[FIX] mail: partners with missing/invalid emails must not halt notifications to others

[FIX] web: keep pager in popup list view

When an action opens records in list (or other) mode in a popup (target:new), the pager should be kept. It can be removed in form view.
Fixes #742

[MERGE] forward port of branch 7.0 up to 5035c76

[FIX] product: product prices can be company dependent

Some prices, as standard_price, being a property, are company dependent. Therefore, when browsing as superuser, force_company is mandatory to get the property of the user company

[FIX] gamification: call _send_badge on right object

[FIX] account: backport of 12a39db

[FIX] account: Preserve analytic account on tax lines which are on same general account as invoice line

After careful analysis, I'm now convinced it is a good thing to preserve
the analytic account on taxes line which have the same general account
as the invoice line.

This is the best default case and will save time for users,
while leaving the flexibility to adapt the analytic account on
taxes manually.

[FIX] account: backport of 3470643

[FIX] account: Error when manually adding analytic account in the generated tax lines on an invoice

fixes #374
fixes https://bugs.launchpad.net/ocb-addons/+bug/1084822

The fix considers invoice tax lines with different analytic account
are equivalent for the purpose of checking if the list of tax line
is complete.

Caveat, this changes the structure of keys in the dictionary
returned by account.invoice.tax's compute method, I suppose this
is ok for the master branch.

[IMP] project_issue : correct model name in onchange method

There is no model project.issueS, making the onchange select an inexistant model.
Fixes #3418

[FIX] web: more backports for cleditor

Restauring changes removed by the update of the library
bff34f4014aee31aac7412cc38598adbeb8230f0
17a23c60b80474f053997f90d05a94acb8561604
cc23ddd0cec62342d538c17140840f7dda569d0b
5c45aac7ef9df8f2f0d2aeb213813a99dfb2a8c7

[IMP] marketing_campaign: forbid creation of activities from transitions

[FIX] web: backport of 2331b14

Update the cleditor lib from v1.3.0 to v1.4.4 fixing IE11 issue, opw 614826

[FIX] payment_paypal: add company name in paypal item name

So the company name is displayed in the paypal payment form

[IMP] account: remove duplicated field in view

Partial backport of 5f06129.
Fixes #2837

[FIX] web: on editable list save, valid all records

opw-617036:
In my current timesheet, if you add a a required field on the timesheet ids lines, and add data in the summary tab, it was possible to validate the timesheet lines while requried fields were missing.

[FIX] stock: more tolerant copy method

Allow setting origin/backorder when copying new stock.picking
Fixes #379, lp:1098557

[IMP] stock: avoid errors with picking without quantity

When a line is not present in the partial delivery wizard, computation variables are initialized with generic values (zero quantity, zero price,...). Instead of setting the uom to False, keep the quantity of the move.
This makes a difference only when the quantity of the move is 0. That means that the move will be marked as complete and can be processed.
This avoids trying to update the stock.move with a uom at False. opw 616844

[FIX] project_issue: explicit store attribute for the progress function field

This is a workaround for an ORM limitation. A stored function field is
not updated when it should if the "source" field is also a stored function
field

[FIX] base_action_rule: Make sure model exists before trying to wrap hooks

In certain cases, before running an update unregistered models will try to
register hooks. Trying to wrap create and write on these will cause
AttributeError on model_obj which would be None

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

[IMP] .gitignore maintenance migration scripts

[MERGE] forward port of branch 7.0 up to 43db726

[FIX] web_calendar: cast the id into int. When you open a form view in a popup via the attr 'event_open_popup', in some cases the id is a string and so the popup is empty... FIX #545  PR #551

[FIX] stock: UoS quantity in stock.picking

Implements the UoS TODO items on stock.picking.do_partial() to fix #1432.
Add a new method _compute_uos_qty() on product.product to computes
product's invoicing quantity in UoS from quantity in UoM.

The created invoice will use the product_uos of the stock.move, meaning keeping
the quantity specified on the partial picking and the unit of measure of the
original stock.move (e.g. recieving 1 dozen from a 12 unit picking should either
get uos=dozen, uos_qty=1 or uos=unit, uos_qty=12, not a mix of both)

Fixes #1432, opw 611479

[MERGE] forward port of branch 7.0 up to f4870f8

[FIX] sale: when invoicing on lines, set order in progress when all lines invoiced

This fix is related to rev. b1df5aab6e529e9667bb97c96c9196e1a4e5e0ce

[MERGE] forward port of branch 7.0 up to b1df5aa

[FIX] sale: trigger all_lines signal when all lines are invoiced

Revert "[FIX] mail: read more show original message"

This reverts commit 0790682296e43989e4e232189009c3ba380e32ba.

This fix is not yet ready. See PR #3295

[MERGE] forward port of branch 7.0 up to 00ec786

[FIX] account: partner balance general totals

General totals were not computed at all, due to the condition "if not self.ids" which was always true as self.ids wasn't set.

Besides, a parameter allows to display only partner with balance greater than 0, which was completely ignored by the totals computation methods: The totals always included all partners, even those having balance equals to 0

[FIX] hr_timesheet_invoice: warning in report generation

When generating the report 'Timesheet Profit', got a warning "The domain term '('user_id', '=', [...])' should use the 'in' or 'not in' operator."
This warning is due to the use of the '=' operator to compare the field 'user_id' while the reports sends a list of ids.
Fallback to still accept a single id in case of customised reports.

[FIX] sale_margin: cost price uom

When computing the cost price to display, take the uom into account. The cost of 1 Unit or 1 dozen should not be the same. opw 599727

[FIX] stock: forbid adding new lines when processing picking

Source and destination locations are required and not displayed in the form view.
Adding new items when recieving a picking can not be easily guessed as we can put different locations for each line, using default locations may not be the expected result.
Instead should modify the original picking or create new one.
Fixes #2074, opw 612768

[FIX] product_visible_discount: use on_change result for product value

At the end of the onchange call product_id_change, the uom may have changed (e.g. if product in different category).
To compute the quantity, we need to use the new uom and not the first one (that may be Unit, default value)

[FIX] account: limit search for fields_view_get to one result

+ use ir.model.data get_object_reference method for better performance (cached result)

opw-616616

[FIX] mail: read more show original message

Instead of html cleaned html, to allow display blockquotes

opw-614729

[FIX] web: cors rpc calls were missing the session cookie, resulting in new sessions being created for every call

Forward port of branch 7.0 up to rev 8abd003

[FIX] product: reference in test

Forward port of branch 7.0 up to 42bf0a5

[FIX] product_visible_discount: discount with different unit of measures

The computation of the price without pricelist should take care of the unit of measure.
e.g. if computing discount for objects in dozen (on a product with price in unit), returned unit price should be (price*12) where 12 is the factor to go from dozen to unit.
Otherwise the compared prices (with and without pricelist) would not use the same unit of measure and the comparaison would be inconsistent. (opw 599727)