Feature #5875

Changes to child estimates should trigger journal entries for the parent estimate

Added by Kurt Christensen almost 9 years ago. Updated almost 8 years ago.

Status:NewStart date:2010-07-12
Priority:NormalDue date:
Assignee:-% Done:


Target version:-


With the new 'subtask' feature in Redmine 1.0.0 RC, any existing estimate for an issue is replaced with a rollup of the estimates for the child issues. Some problems arise from this:
  1. Journal entries are created for estimate changes to the child issues, but not for the parent issue, which makes historical burnup reporting much more difficult.
  2. More importantly, any high-level estimate which once existed for a parent issue is lost once it gains a child issue. This is the only case I know of in the Redmine database where data gets lost without a journal entry.

Selfishly I only care about estimated time, although I assume this also affects the other rollup values: priority, start date and due date.

In other words, to reproduce:
1) Create issue
2) Set estimated time to 100
3) Create subtask
4) Set estimated time for subtask to 44

In the database, note that estimated_hours for the parent issue will have changed, but there is no associated journal entry.

Related issues

Related to Redmine - Feature #5490: Option for independent subtask priority/start date/due da... Closed 2010-05-10
Related to Redmine - Feature #6687: Making an issue a subtask leads to loss of issue-property... New 2010-10-18
Related to Redmine - Feature #13585: Make sub-task inherit the properties of parent New
Duplicated by Redmine - Feature #5876: Changes to child estimates should trigger journal entries... Closed 2010-07-12
Duplicated by Redmine - Feature #5733: Subtasks: inheritance of time needs to be clear, either w... Closed 2010-06-22
Duplicated by Redmine - Defect #14118: When creating a subtask, the priority of the main defect ... Closed


#1 Updated by Kurt Christensen almost 9 years ago

This is somewhat related to #5490

#2 Updated by Kurt Christensen over 8 years ago

Just wondering if anyone out there cares about this... I probably should have marked it as a defect rather than a feature, since it really does give surprising database behavior - changes in the child tasks clobber values which are normally journaled, and you can actually lose history. Seems bad.

#3 Updated by Kurt Christensen over 8 years ago

Hellooooo...? Anyone care about this??

#4 Updated by Mischa The Evil over 8 years ago

Kurt Christensen wrote:

Hellooooo...? Anyone care about this??

I do. See the related issue I filed as #6687. I updated the related issues accordingly too.

#5 Updated by Randy Syring over 8 years ago

I am not sure I agree with just creating a journal entry. My use case is as follows: I have higher level estimates on larger chunks of the project. I then create sub-tasks as needed. But as this issue indicates, as soon as I add a sub-task with an estimate, I lose the estimate on the parent.

I think my solution would be to come up with a different way to show the sum of the child hours. I don't think wanting an estimate on a parent issue as well having a sum of estimated hours on child issues should be mutually exclusive. I guess, I would advocate for a different field entirely on the issue, something like "Estimated time (children): ..." and keep the current field "Estimated time".

If thats not possible or desired, a second idea would be to let the value in the parent' issues "Estimated time" field determine what is shown. If it has a value, show it. If its blank, and child issues have values, then go ahead and sum the children's values.

#6 Updated by Svein-Tore Griff With almost 8 years ago

I think Randy has suggested the best approach for this.

something like "Estimated time (children): ..." and keep the current field "Estimated time".

Also available in: Atom PDF