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
The working time unit can either be hours or days. In case of days, should
replace the references to hours in the view to days. In case of days, use float
field instead of float_time.
Using the string 'Hours' as a way to determine the unit is too weak as:
1. it does not work in other language than english
2. if the unit is renamed (*cough* 1626eca *cough*), it will fail as well
Using the object with context to compare strings in the user language.
lp:1080191, opw 595397
When setting a task as done, the state is done and the progress written to 100%.
If this task is reopened, the progress was not resetted as the stage is changed
but not the state (still done).
Partially backport behaviour of 8.0 (8fbfc997) by using the fold attribute
instead of the state to reset the progress.
opw 597688
The tasks list view "act_project_project_2_project_task_all"
always displays inactive tasks ("'active_test': False" in context).
Both the link in the kanban and the button in the form
leading to this list view should therefore counts both
inactive & active tasks.
opw-628672
The gantt view does not have enough data to properly display a project's length
based on only the planned hours.
It also makes it impossible to change the project's length using drag & drop.
It's safer to simply display the start and end dates recorded in the project
Fixes#2632