Parent/subtask: calculation of estimated hours
We defined 1-level issue with estimated time 10 hours.
Once we defined subtask for 1-level issue with estimated time 15 hours, we got 15 hours in parent task. (should be 25 hours in parent)
Once we defined subtask for above subtask with estimation 20 hours, above subtask became with 20 hours and parent task became 20 hours. (should be 45 in parent)
If we define another subtask for 1-level issue with estimation 30 hours, then parent task make sum of two subtasks on 2-level and total time for parent task will be 50 hours. (should be 75 in parent)
But in general, with such arithmetic we're losing hours. Each task which has subtask should make a sum of it's own estimation hours with all hours that defined in his subtasks, not round to hours in subtasks.
#5 Updated by Heiko Robert over 7 years ago
- if a ticket becomes a parent task, estimated time on the parent ticket is replaced with the sum of all subtasks (old value of estimated time is lost!)
- if the estimation for a subtask changes, the estimated hours of the master task is recalculated as sum of all subtasks
conclusion: the semantic of the time estimation field changes if the master_id is set - which is bad! This causes a semantic bug if estimated time is shown in issue list view since time duplicates in master and subtickets.
This inconsistency is continuing with spent time calculation which differs from detail to list view (#17550).
The concept is not very intuitive because it doesn't support / prevent a switch from a normal ticket to a master ticket without loosing time estimations. It is a normal live cycle to start with a simple task/feature and to add bugs, missing features later as subtasks.
I think the solution would be not to use the estimated hours field as a sum field for master tickets. Instead sums should be saved (only) in the master (if parent_id is not set) ticket in a separate field and/or solved by correct/dynamic sql and grouping. SQL/grouping should be handled in the time entry report.