Defect #16092
closed
Parent/subtask: calculation of estimated hours
Added by Pavel Potcheptsov about 10 years ago.
Updated about 8 years ago.
Description
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.
I've made a typo in second sentence. Should be:
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)
- Related to Feature #5490: Option for independent subtask priority/start date/due date/done ratio added
- Description updated (diff)
I think I understood now how it works:
- 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.
- Related to Defect #17550: Spent time in exported CSV is wrong added
How can I get total estimate hours on parent issue via REST ? I had been able to get it under version 3.0.
- Related to Feature #20688: Add Total estimated hours column on issue list added
Takashi Ichihashi wrote:
How can I get total estimate hours on parent issue via REST ? I had been able to get it under version 3.0.
It is deleted (ref: #5490#note-93).
Please describe your opinion to #20688.
So, there is no any way to get total_estimate_hours via REST?
- Related to Defect #21449: Automatic done ratio calculation in issue tree is wrong when parent has its own estimated time added
Why this task is still open? It seems that r14272 implemented all what written in the description field, didn't it?
- Status changed from New to Resolved
- Status changed from Resolved to Closed
- Resolution set to Fixed
- Has duplicate Feature #13775: Adding a sub-task with zero estimated time erases parents value added
Also available in: Atom
PDF
Updated by 
Updated by Toshi MARUYAMA 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by