The precision of the field 'hours' in project.task.work and the precision of
'remaining_hours' are not the same. This is why the difference between them can
generate some very small negative difference which implies an infinite percentage for
the working progress time.
opw:643649
This revision is related to 279f225cf0.
`_get_pickings` is used as trigger store method
for several computation fields.
The trigger restriction applied in the above commit should
only be applied on the `min_date`, `max_date` and
`priority` fields.
This rev. is related to 279f225cf0.
The `product_qty` computation priority should be
important, as other compute fields depends on it
such as `weight` and `weight_net` from the
delivery module
This is a performance revision.
Some stored functions field were recomputed uselessly.
In mrp, `hour_total` and `cycle_total` were recomputed
at each write on `mrp.production`, while they should be recomputed
only when there is a change on the `workcenter_lines` field,
or when there is a change in the `hour` or `cycle` field
of these `workcenter_lines`.
In stock, `min_date`, `max_date` and `priority` of
`stock.picking` were recomputed each time a new move
was added to the picking,
wether or not the 'expected_date' of this move
was between the `stock.picking` `min_date` and `max_date`,
and the priority not greater.
In stock, `product_qty` of `stock.move` was recomputed
at each write on the `stock.move`, while it should be
recomputed only when there is a change in `product_id`,
`product_uom` or `product_uom_qty`, as the computation
method only depends on these three fields.
In stock_account, the `invoice_state` of `stock.picking`
was recomputed each time a new `stock.move` was associated
to the picking, wether or not the `invoice_state` of the move
was already the same than the `invoice_state` of the picking.
opw-643560
This fixes 2 issues.
First, it keeps consistent the precision required for posted entries and the
precision for the balance assertion. This could be an issue if the account
precision is larger than 4.
Then, it makes sure to round the amount with the appropriate precision to avoid
numerical errors. For example 1.2344 - 1.2345 = -9.999999999998899e-05, which
is indeed smaller than the required precision 10 ** -4.
A minimum precision of 10 ** -5 is kept for historical reason.
Fixes#7276
opw-643305
Revert the modification from commit 8ae67f6a54 ; it appears that the test of required field is done before the computation of the related field and that leads to a Validation Error.
As the field employee_id is already required and the user_id is related to this field, the attribute required is redundant and unecessary.
When we return goods and a refund is created, we check the purchase order
linked to the original move. Therefore, the appropriate currency and unit
prices will be chosen.
opw-643085
The price without taxe must be rounded on each line like 'price_subtotal' in "sale.order.line"
with digits_compute= dp.get_precision('Account').
The total taxes included must be the sum of the rounded total without taxe and
the rounded taxes like in "sale.order" in _amount_all.
opw:643254
Returning `picking_id` can be useful for overrides.
In addition, when there is no return statement,
the method basically returns None.
As this is a public method (not beginning with '_'), it can
be called with an xmlrpc call, and `None` is not an
accepted return value for the xmlrpc protocol.
Closes#1714
A variable "lines" is instancied few lines above,
with the exact same browse call, and there is no
operation that could lead to an update of the result
between these two browse calls.
Closes#1394
When confirming a sales order with invoicing control
based on "Delivery order", confirming the quotation
didn't post the "Quotation Confirmed" message
subtype in the sales order thread.
opw-642744
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
Incoming shipments are marked red according to creation date which does
not really make much sense.
closes#1061
note: it was already like this in 8.0 with 201f1c323
When creating an event in at 4 pm,
while being in UTC +2 (Europe/Brussels),
The start date sent to Google was set as
'2015-07-03T16:00:00+02:00',
but the timezone was described as 'UTC', giving
therefore giving contradictory information.
At the end, in the google calendar,
the event was set in the UTC timezone,
while it should have been set in GMT +2 (Europe/Brussels).
opw-640825
When column 'writeoff_amount' gets displayed on a tree view and function
_get_writeoff_amount() is called with multiple ids, the returned amounts keeps
getting bigger every row.
Closes#7211
Before this rev.,
if you define a carrier
- without advanced price rules
- with a normal price set to 0.0
- Free if more than amount unchecked
When you try to invoice a delivery order
(coming from a sales order with as invoicing policy
"on delivery order)
No grid was found, while there was one, with as price 0.0
Closes#1364
The amount total computed for pos order must be the sum of the rounded tax amount
and the rounded untax amount. Inspired from _amount_total in "sale.order".
opw:643254
Don't retrieve the binary contents just to display the size, but pass context
with bin_size=True instead
Always pass filename in download link
Combination of patches from the bug report from Enrico Ganzaroli, Cedric Le
Brouster and Holger Brunn
Fixes#4899, lp:1167429
In account_budget module,
when creating a budget position,
the user can select view accounts and also accounts with consolidation children,
in addition to normal accounts.
However, when viewing budgets with positions containing only view accounts,
the "practical amount" field was always zero.
Since these type of accounts are accepted as budget positions,
the system should take into account children and consolidation children
when computing the practical amount.
Fixes#372Closes#1247
Don't preload company logo of the wrong company
When a user other than the admin signed in
and was in a company different than the admin
and this company had a different logo,
the company logo (in the upper left corner)
displayed the logo of the admin company,
instead of the logo of the company of this
user.
As soon as the user refreshed the page
in his browser, the issue was resolved,
but the logo should be the good one
from the beginning.
Closes#1453
Goffin Simon
luistorresm
Denis Ledoux
fclementic2c
Temur Vibliani
Christophe Simonis
Nicolas Martinelli
Jeremy Kersten
Jonathan Nemry
Martin Geubelle
Max Hellwig
Pedro M. Baeza
Ludwik Trammer
Stéphane Bidoul
Odoo Translation Bot
Daniel Dico
André Paramés
Xavier Morel
Tam Vu
andrius-preimantas
Nicolas Bustillos
Lionel Sausin (Numérigraphe)
Martin Trigaux
Robin Lucbernet
Stefan Rijnhart
Joao Alfredo Gama Batista