Create one unique generic Makefile to compile sass files.

Stems from prebiblical commit f083aa2b.

Fixes #3480

fix a5cf7197

opw-616843

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

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

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

This fix is related to df845940

Fixes #3469

This is related to rev. a218a9ed

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

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

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] 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: 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.

Restauring changes removed by the update of the library
bff34f40
17a23c60
cc23ddd0
5c45aac7

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

Partial backport of 5f061291.
Fixes #2837

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.

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

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

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

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>

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

This fix is related to rev. b1df5aab

This reverts commit 07906822.

This fix is not yet ready. See PR #3295

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

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.

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

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

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)

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

opw-616616

Instead of html cleaned html, to allow display blockquotes

opw-614729

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)

The price_surcharge attribute must be computed based on the reference unit of measure (divided by the factor).
This is to make sure than 12 units and 1 dozen have the same price after pricelist computation (opw 599727).

Added test checking the correctness of pricelist computation based on unit of measures.

Fixes #3237

cherry-pick of 8e720494

[FIX] When using "--stop-after-init", set the return code correctly. A non zero return code reflect the number of databases that fail to load/update

Backport of 2c4e370b and
33ce0e73