Feature #5875
Changes to child estimates should trigger journal entries for the parent estimate
| Status: | New | Start date: | 2010-07-12 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | Issues | |||
| Target version: | - | |||
| Resolution: |
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
History
#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".