Defect #23151
closeddone_ratio calculation with multi-level sub tasks and estimated hours
0%
Description
Using the Setting parent_issue_done_ratio=derived
and given the following issue hierarchy:
[1_0_0] - (3h) | | | +- [1_1_0] - 1h | +--- [1_2_0] - (2h) | | | +- [1_2_1] - 1h | +--- [1_2_1] - 1h
When I set [1_1_0]
to status closed, the done ratio of [1_0_0]
is recalculated.
Since 1h of 3h of work are done, the derived done ratio of [1_0_0]
should be 33%. In current Redmine trunk r15582 the actual value is 50%, since the done ratio is solely based on the direct children and their estimated hours. The code was introduced with 3.2.0, r14875, #20995.
It gets more complicated when adding estimates on parent nodes (introduced in 3.1.0, r14272, #16092):
[2_0_0] - 1h (Total 5h) | | | +- [2_1_0] - 1h (Total 1h) | +--- [2_2_0] - 1h (Total 3h) | | | +- [2_2_1] - 1h (Total 1h) | +--- [2_2_1] - 1h (Total 1h)
Estimated hours on parent tasks are added to the estimated hours of the issue's sub tasks. The total estimated hours is the sum of all issues within the sub tree.
When I set [2_1_0]
to status closed, the done ratio of [2_0_0]
is recalculated.
Now 1h of 4h of work on the sub tasks are done, the derived done ratio of [2_0_0]
should therefore be 25%. Similarly one could argue that 1h of 5h on the whole issue tree are done, the derived done ratio of [2_0_0]
should therefore be 20%.
But in current Redmine trunk r15582 the actual value is 50%, since the done ratio is solely based on the direct children and their estimated hours.
Attached are some easy tests highlighting the problem.
Files
Related issues