Project

General

Profile

Actions

Feature #6687

open

Making an issue a subtask leads to loss of issue-property values

Added by Mischa The Evil almost 14 years ago. Updated almost 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Issues
Start date:
2010-10-18
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

When a normal issue is changed to being a subtask (thus getting an initial parent id) current values for the following issue-properties are lost due to roll-up from subtasks to parent issues:
  • priority
  • start/due dates
  • progress
  • estimate

These changes aren't recorded to issue-journals (besides an entry about the changed parent id), thus are lost without any reminder/notice.


Files

no_priority_rollup.diff (2.76 KB) no_priority_rollup.diff No priority rollup patch. Chris Wolf, 2011-04-28 20:29
keep_original_dates_and_estimations_on_parent_issue.diff (13.5 KB) keep_original_dates_and_estimations_on_parent_issue.diff Bishma Stornelli Ortega, 2013-02-22 21:09
de.yml (50.6 KB) de.yml Sebastian Bertram, 2013-04-20 13:45
log redmine.JPG (61.6 KB) log redmine.JPG Sebastian Bertram, 2013-04-20 14:00

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 #5875: Changes to child estimates should trigger journal entries for the parent estimateNew2010-07-12

Actions
Related to Redmine - Feature #9991: Estate parent task vs subtaskClosed

Actions
Related to Redmine - Feature #13775: Adding a sub-task with zero estimated time erases parents valueClosed

Actions
Related to Redmine - Feature #27644: Journals and notifications on changes on Issues set by relationsNew

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

Actions
Has duplicate Redmine - Defect #25056: Parent task issueClosed

Actions
Actions #1

Updated by Ewan Makepeace almost 14 years ago

+1

At least write the values in the history so we can restore the issue as it was if needed.

Actions #2

Updated by Mischa The Evil almost 14 years ago

  • Priority changed from Normal to High
Actions #3

Updated by Chris Wolf over 13 years ago

In my organization, we do want the dates and estimated time to rollup from the subtasks, however, we don't want the priority to rollup - we want the priority set and maintained in the parent task independently of the subtasks. Attached is a hack to implement this. The patch includes the cross-project subtask feature /issues/5487.

This patch is base on release 1.1.2.

Actions #4

Updated by Etienne Massip over 13 years ago

  • Target version set to Candidate for next minor release
Actions #5

Updated by Svein-Tore Griff With over 13 years ago

+1
Vote for the option where the current solution is kept, but we also keep a separate estimate for the parent task, so that the parent task would have the properties:

Estimated time: 30 hours(editable)
Total estimated time from children: 32 hours

We can do the same for the other properties.

Actions #6

Updated by Jacq Jacq over 12 years ago

+1
All the properties should be editable and independent from subtasks.
As a option it could be set to get properties from subtasks.

Actions #7

Updated by Radek Karban over 12 years ago

+1

Actions #8

Updated by Murray Melvin almost 12 years ago

I also would like to see something done about this. Svein-Tore Griff With's suggestion would work for me.

Actions #10

Updated by Eric Voisard almost 12 years ago

All these discussions and issues about subtasks just show that this important feature needs serious (and open minded) rethinking.

Or an option to disable subtasks completely...

Actions #11

Updated by Julian S. Luipold over 11 years ago

+1
would prefer to have a per project setting for the behaviour of subtasks!

Actions #12

Updated by Bishma Stornelli Ortega over 11 years ago

I've just made a patch that works like this:

When an issue is divided in subtasks, the priority, the start/dude date and the estimated time is kept in the parent but additional fields are created to show the calculated values of the subtasks.

The estimated time of an issue must be greater than the estimated time of the subtasks, less than the estimated time of the parent - estimated time of siblings and if the parent has not estimated time, subtasks can't have estimated time.

The done ratio is calculated using the no calculated estimated hours of the issues. Example:

  • Issue 1 has 100 estimated hours
  • It's divided into Issue 1.1 and Issue 1.2
  • Issue 1.1 has an estimated hours of 40 and a done ratio of 50.
  • Issue 1.2 has an estimated hours of 30 and a done ratio of 100.
  • Then the done ratio of Issue 1 is 40*0.5 + 30*1 = 50.

Dates on subtasks are allowed to be before or after the start/due date of the parent but it's always displayed in the parent issue. Maybe I'll add a validation to avoid this and ensure that all dates in subtasks are between the start and due date of the parent.

This patch was made for version 2.2.1 and there is not warranty it works even in this version because the development was done on an already patched version of redmine and I'm not sure if the files edited were changed previously.

Don't forget to run the migration (it will force update of these attributes for all existing issues).

Actions #13

Updated by Toshi MARUYAMA over 11 years ago

  • Tracker changed from Defect to Feature
  • Priority changed from High to Normal
Actions #14

Updated by VD DV over 11 years ago

+1

Actions #15

Updated by Sebastian Bertram over 11 years ago

Hi the patch sounds realy good. Did somebody try it? I have a new installed 2.3 version of redmine here and the parent subtask thing is realy annoying

Actions #16

Updated by Sebastian Bertram over 11 years ago

I did try to patch my redmine 2.3 today and I get an internal error when I want to display the issus. I'm glad that I patched with the backup option.

Actions #17

Updated by Sebastian Bertram over 11 years ago

Now I realize that I didn't run the migration. Could the internal error 500 occurred because of that?

Actions #18

Updated by Bishma Stornelli Ortega over 11 years ago

Hello Sebastian, I guess it is. Probably a NoMethodError. You can check the log and print the error message here.

Actions #19

Updated by Sebastian Bertram over 11 years ago

Unfortunately there was a permission issue, so the log wasn't written. But at the Moment I also think that the Problem maybe only or also comes from the fact, that I am using redmine with German language and the patch only changes the file for the English and Spanish language.
So I think there a two things I can try now. Change the language file and make a migration.
Is there something I have to care about when I add the added lines of the en.ylm to the de.ylm? Other then translation the words after the colon.
Is there a order in which the lines have to be added?

Actions #20

Updated by Bishma Stornelli Ortega over 11 years ago

No. Just add the lines in any order but make sure you use the right indentation.

Actions #21

Updated by Sebastian Bertram over 11 years ago

Ok, now I patched the files again and also changed the de.yml. At the moment I have the problem, that the german translation isn't working for the hole programm. And I don't know why.
Here is the file I created.

Actions #22

Updated by Sebastian Bertram over 11 years ago

And the log shows that. (see file)

Actions #23

Updated by Mischa The Evil over 11 years ago

  • Related to Feature #13775: Adding a sub-task with zero estimated time erases parents value added
Actions #24

Updated by Lucas Ribeiro about 11 years ago

Bishma Stornelli Ortega wrote:

I've just made a patch that works like this:

When an issue is divided in subtasks, the priority, the start/dude date and the estimated time is kept in the parent but additional fields are created to show the calculated values of the subtasks.

The estimated time of an issue must be greater than the estimated time of the subtasks, less than the estimated time of the parent - estimated time of siblings and if the parent has not estimated time, subtasks can't have estimated time.

The done ratio is calculated using the no calculated estimated hours of the issues. Example:

  • Issue 1 has 100 estimated hours
  • It's divided into Issue 1.1 and Issue 1.2
  • Issue 1.1 has an estimated hours of 40 and a done ratio of 50.
  • Issue 1.2 has an estimated hours of 30 and a done ratio of 100.
  • Then the done ratio of Issue 1 is 40*0.5 + 30*1 = 50.

Dates on subtasks are allowed to be before or after the start/due date of the parent but it's always displayed in the parent issue. Maybe I'll add a validation to avoid this and ensure that all dates in subtasks are between the start and due date of the parent.

This patch was made for version 2.2.1 and there is not warranty it works even in this version because the development was done on an already patched version of redmine and I'm not sure if the files edited were changed previously.

Don't forget to run the migration (it will force update of these attributes for all existing issues).

Applied your patch on version 2.3.1 and ran the migration. No changes were found on the parent task.

Actions #25

Updated by Lucas Ribeiro about 11 years ago

Strange, even for new tasks the patch didn't work. I'm suspecting it's a migration problem, as I try to migrate there is this warning:
WARNING: 'require 'rake/rdoctask'' is deprecated. Please use 'require 'rdoc/task' (in RDoc 2.4.2+)' instead.

Any clues?

Actions #26

Updated by Sebastian Paluch almost 9 years ago

It seems that this has been already implemented by #16092 and #5490. The behavior is now configurable so probably this can be closed.

Actions #27

Updated by Mischa The Evil over 7 years ago

Sebastian Paluch wrote:

It seems that this has been already implemented by #16092 and #5490. The behavior is now configurable so probably this can be closed.

No, this issue is not-yet solved. See eg. this case (taken from #25056):

Mischa The Evil wrote:

[...] parent tasks attributes setting set to "calculated from subtasks" [...]

When you have two issues:
  • issue1 (priority => normal, start_date => 01-01-2017, due_date => 31-12-2017, %-done => 10 %)
  • issue2 (priority => immediate, start_date => 05-01-2017, due_date => 05-03-2017, %-done => 50 %)
and now identify issue2 to be part of issue1 and as such edit issue2 to become a subtask of issue1, looking as follows:
  • issue2 (priority => immediate, start_date => 05-01-2017, due_date => 05-03-2017, %-done => 50 %, parent => issue1)
then issue1 will be changed to look like following without any journal on issue1 to record the previous values of priority, start-/due date and %-done attributes (estimated time attribute is already fixed by r14272):
  • issue1 (priority => immediate, start_date => 05-01-2017, due_date => 05-03-2017, %-done => 50 %)

This shows that the conversion of root-issue to parent-issue leads to a silent loss of issue attribute values, which I think is a true problem.

Actions #28

Updated by Mischa The Evil over 7 years ago

Actions #29

Updated by Eva Encabo almost 7 years ago

+1 It's very important for us that the changes are recorded in journals and also to have notification of parent changes

Actions #30

Updated by Mischa The Evil almost 7 years ago

  • Related to Feature #27644: Journals and notifications on changes on Issues set by relations added
Actions

Also available in: Atom PDF