Feature #5875
open
Changes to child estimates should trigger journal entries for the parent estimate
0%
Description
- 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.
Related issues
Updated by Kurt Christensen about 15 years ago
This is somewhat related to #5490
Updated by Kurt Christensen almost 15 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.
Updated by Kurt Christensen over 14 years ago
Hellooooo...? Anyone care about this??
Updated by Mischa The Evil over 14 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.
Updated by Randy Syring over 14 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.
Updated by Svein-Tore Griff With about 14 years ago
I think Randy has suggested the best approach for this.
something like "Estimated time (children): ..." and keep the current field "Estimated time".