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
Using the `start` CLI command with the `--path` or `-p` option arrors with:
odoo.py: error: no such option: --path
This is because the `--path` option is passed on the server start routine,
and it's invalid there.
A workaround is to remove those command options from the arguments passed
to the main() server start.
Closes#5896
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
luistorresm
Denis Ledoux
fclementic2c
Temur Vibliani
kmatitaishvili
Daniel Reis
Christophe Simonis
Nicolas Martinelli
bevanweiss
Jeremy Kersten
florent.thomas
Jonathan Nemry
Mohammad Alhashash
Martin Geubelle
Martin Trigaux
Max Hellwig
SauliusZ
Pedro M. Baeza
Ludwik Trammer
Goffin Simon
Stéphane Bidoul
Odoo Translation Bot
Daniel Dico
André Paramés
Xavier Morel
Tam Vu
andrius-preimantas
Nicolas Bustillos