Project

General

Profile

Actions

Feature #5875

open

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

Added by Kurt Christensen over 14 years ago. Updated over 13 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Issues
Target version:
-
Start date:
2010-07-12
Due date:
% Done:

0%

Estimated time:
Resolution:

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:
  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 date/done ratioClosedJean-Philippe Lang2010-05-10

Actions
Related to Redmine - Feature #6687: Making an issue a subtask leads to loss of issue-property valuesNew2010-10-18

Actions
Related to Redmine - Feature #13585: Make sub-task inherit the properties of parentNew

Actions
Has duplicate Redmine - Feature #5876: Changes to child estimates should trigger journal entries for the parent estimateClosed2010-07-12

Actions
Has duplicate Redmine - Feature #5733: Subtasks: inheritance of time needs to be clear, either way we chooseClosed2010-06-22

Actions
Has duplicate Redmine - Defect #14118: When creating a subtask, the priority of the main defect might be changed unwillinglyClosed

Actions
Actions #1

Updated by Kurt Christensen over 14 years ago

This is somewhat related to #5490

Actions #2

Updated by Kurt Christensen over 14 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.

Actions #3

Updated by Kurt Christensen about 14 years ago

Hellooooo...? Anyone care about this??

Actions #4

Updated by Mischa The Evil about 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.

Actions #5

Updated by Randy Syring about 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.

Actions #6

Updated by Svein-Tore Griff With over 13 years ago

I think Randy has suggested the best approach for this.

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

Actions

Also available in: Atom PDF