When a landed costs is applied on goods that are already out, these landed
costs need to be subtracted in the stock valuation account and added in the output account.
(they were just added before)
When the landed cost is negative, it needs to do the opposite for what is already out also.
When the public user comments the website, he will be redirected
to the login page and his comment will be posted with his logged
user name.
opw:643412
Revert 83282f2d for a cleaner sanitizing earlier in the generation of the error
message.
If the import is failing, the error message contains the value that is
problematic. Escape this value in case it contains '%'
This is related to rev. 55b7f15ee2
Prevent crash when there is no line to display
in the stock valuation report
Reporting > Warehouse > Stock Valuation.
Like when there is not yet any data, or the filter gives no result
opw-643748
While working on project task it is possible
to record "task work" that will automatically
create timesheet lines. These are not by default
included into any timesheet, but they need to
appear in reporting nonetheless.
These lines disappeared from the analysis view
after the performance improvement of
rev. fe31451899
which introduced a JOIN with the `totals`
CTE table - and should have been LEFT JOIN.
When printing these reports from the accounts list
Accounting > Configuration > Accounts > Print menu > General Ledger
the ID of the wizard was considered as the ID of an account,
leading to obvious issues when this ID wasn't available
in the account_account table, or when the user
do not had the access rights to see the accounts with this
ID.
The override was completely useless: The wizard is
launched whether you print these reports from
Accounting > Reporting > Legal reports > Accounting Reports
or from the accounts list, and the super _get_account can
be called correctly for these two use cases.
opw-643589
In commit 44f2c8d54 we unified the return value of the function to int,
but it seems the returned size could be None which is not a valid input
of the int() built-in function.
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
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.
andreparames
Josse Colpaert
Antonio Espinosa
Alexis de Lattre
Goffin Simon
谢立
mrshelly
Olivier Dony
Pedro M. Baeza
Martin Trigaux
Alexandre Fayolle
Denis Ledoux
Dušan Laznik
Raphael Collet
Odoo Translation Bot
Nicolas Lempereur
Briksisn
luistorresm
fclementic2c
Temur Vibliani
kmatitaishvili
Daniel Reis
Christophe Simonis
Nicolas Martinelli
bevanweiss
Jeremy Kersten
florent.thomas
Jonathan Nemry
Mohammad Alhashash
Martin Geubelle
Max Hellwig