project.task: use an onchange to update date_start when changing user_id.
Indeed date_start is automatically updated in the create / write. Without
the onchange, this may lead to errors related to date_start being greater
then date_end.
project.issue: code in create and write now takes into account date_open
values given to the method and avoid erasing them.
In issue however the onchange is not added. Indeed the date_open and
date_closed fields are not visible in the view. They are automatically
computed and used to compute statistics.
Since we're not duplicating work items when duplicating tasks during
project duplication, it doesn't make sense to duplicate the
likely correspondingly adjusted remaining hour.
Behave as if the planned hours had just been set/reset and set the
remaining hours of the new task to that instead.
fixes#8985
This change avoid to display the tasks
that a user is not permitted to see
in the reporting view 'Task analysis'
Closes#4399
Courtesy of jkei
https://github.com/jkei
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
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
Some tests (e.g. mail) have expensive and significant DB setup for a
number of small and cheap tests. Using a TransactionCase, the DB setup
far dominates the tests themselves, by up to 10x (mail unit tests take
~130s on my machine, the tests themselves take ~15s).
The SavepointCase introduced here is an hybrid of SingleTransactionCase
and TransactionCase: it uses a single transaction for all tests in a
class, but each test case is isolated by a rollbacked savepoint. This
allows a common DB setup (via setUpClass) while keeping independent
tests.
TransactionCase should remain the primary test case superclass, but
SavepointCase can be a fair optimisation when setup costs far dominate.
Changing the unit does not modify past entries generated (too dangerous) however
this was not clear of the effect of the field.
A better fix (for master) would be to add a unit field. opw 618804
Measures added to the Task Analysis report were not kept when saving the filter.
This is due to the lack of 'col' type field in the view definition (the parser
in 8.0 needs at least one).
This does not need to be forward ported (no bug in next version) but it's anyway
a good idea to filter by user by default.
Fixes#2835, opw 621468
Odoo Translation Bot
Thibault Delavallée
Martin Trigaux
Xavier Morel
Denis Ledoux
Pedro M. Baeza
Goffin Simon
Christophe Simonis
Christophe Combelles
Olivier Dony
Josse Colpaert
Rucha Dave
fka-odoo