Defect #16092
closed
Parent/subtask: calculation of estimated hours
0%
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.
Related issues
Updated by Pavel Potcheptsov almost 11 years ago
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)
Updated by Toshi MARUYAMA almost 11 years ago
- Related to Feature #5490: Option for independent subtask priority/start date/due date/done ratio added
Updated by Heiko Robert over 10 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.
Updated by Toshi MARUYAMA about 10 years ago
- Related to Defect #17550: Spent time in exported CSV is wrong added
Updated by Takashi Ichihashi over 9 years ago
How can I get total estimate hours on parent issue via REST ? I had been able to get it under version 3.0.
Updated by Toshi MARUYAMA over 9 years ago
- Related to Feature #20688: Add Total estimated hours column on issue list added
Updated by Toshi MARUYAMA over 9 years ago
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.
Updated by Evgeny Popov about 9 years ago
So, there is no any way to get total_estimate_hours via REST?
Updated by Toshi MARUYAMA almost 9 years ago
- Related to Defect #21449: Automatic done ratio calculation in issue tree is wrong when parent has its own estimated time added
Updated by Sebastian Paluch almost 9 years ago
Why this task is still open? It seems that r14272 implemented all what written in the description field, didn't it?
Updated by Pavel Potcheptsov almost 9 years ago
- Status changed from New to Resolved
Updated by Toshi MARUYAMA almost 9 years ago
- Status changed from Resolved to Closed
- Resolution set to Fixed
Updated by Go MAEDA about 8 years ago
- Has duplicate Feature #13775: Adding a sub-task with zero estimated time erases parents value added