Feature #5875
open
Changes to child estimates should trigger journal entries for the parent estimate
Added by Kurt Christensen almost 14 years ago.
Updated almost 13 years ago.
Description
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:
- 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.
- 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.
This is somewhat related to #5490
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.
Hellooooo...? Anyone care about this??
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.
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.
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
Updated by 
Updated by 
Updated by 
Updated by