Feature #7450

Subtask : automatic status

Added by Alain V. over 6 years ago. Updated over 6 years ago.

Status:NewStart date:2011-01-26
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-
Resolution:

Description

Hello

I would like to use redmine in such way

Project1 with trackerA, with status open, on going, done

Subproject11 of project1 with trackerB with status Pending/Finished

I would like to create a task1 in project1.
Then i would like to create a substask (task2) in Subproject11.

Is it to possible that when I change the status of task2 to Finished, my task1 change automatically to Finished.

And ideally if i have several subtask when all are Finished, my father task switches to Done.

Thank you


Related issues

Related to Redmine - Feature #13585: Make sub-task inherit the properties of parent New
Duplicated by Redmine - Feature #5734: Subtasks: inheritance of status needs to be clear, either... Closed 2010-06-22
Duplicated by Redmine - Feature #9991: Estate parent task vs subtask Closed

History

#1 Updated by Etienne Massip over 6 years ago

I guess closing children issues when closing their parent is ok, but closing the parent when closing the last opened issue may be dangerous : what if your parent issue is not just a subtask container but includes itself some specific actions ?

#2 Updated by Alain V. over 6 years ago

Yes this is a rule to define. For me subtasking is not a "related task" but more a "split" of the parent task..

#3 Updated by Etienne Massip over 6 years ago

You mean like grouping tasks for a project phase ?

This is indeed the most common use of subtasking, but not the only one.

#4 Updated by Alain V. over 6 years ago

What i would like is be able to define rules

Like for instance

For Subtask/tracker-ii if Status1 => Status2 then For Subtask/tracker1 Status=StatusX

#5 Updated by Roman G over 6 years ago

The possiblity to define a rule for status deriving would be great.
I use sub tasks for grouping of tasks because i don't want to create a sub project. Therefore the container itself should be closed if all subtasks are closed

#6 Updated by Alain V. over 6 years ago

Roman G wrote:

The possibility to define a rule for status deriving would be great.
I use sub tasks for grouping of tasks because i don't want to create a sub project. Therefore the container itself should be closed if all subtasks are closed

Exactly the same thing for me!

#7 Updated by Olivier Farlotti over 6 years ago

The way i see subtask is more like ie. "You're trying to describe a body. Subtask are head, legs, arms etc...".
But not like a body, you could add more subtasks as your parent task is on going.
What if you need afterward to add another subtask while all the previous subtask has already been closed ? Does it really mean the parent task is really finished ?

#8 Updated by Roman G over 6 years ago

if a parent task was closed and a new sub taks is added i would suggest opening the parent task again

#9 Updated by Alain V. over 6 years ago

Roman G wrote:

if a parent task was closed and a new sub taks is added i would suggest opening the parent task again

Exactly..
Adding a subtask implicitly means that your parent task should be reopen

#10 Updated by Etienne Massip over 6 years ago

This can't be a good choice : once a task is closed, it is not supposed to be reopened, ever, except if it was closed by mistake (you think it was resolved but it was not).

What you are using subtasking for is, as I see it, more of a replacement for some lacking level in the project -> issue tree, maybe phase.

#11 Updated by Alain V. over 6 years ago

Etienne Massip wrote:

This can't be a good choice : once a task is closed, it is not supposed to be reopened, ever, except if it was closed by mistake (you think it was resolved but it was not).

What you are using subtasking for is, as I see it, more of a replacement for some lacking level in the project -> issue tree, maybe phase.

This is completely unreal..
When you produce a software, it may happen that you did not thought of all the aspect and so reopen a ticket can happen.

We use Redmine in production and i can tell you reopen a ticket is something that is happening.

Not the same by you?

#12 Updated by Etienne Massip over 6 years ago

No, I won't close a ticket before the specified development has been tested and validated.

Once the version has been released for production, I close all related tickets in Redmine (and the version itself) and they won't be reopened.

If you reopen a ticket related to an already closed version, you're going to change the fixed version to a new one and loose your closed version history, aren't you ?

#13 Updated by Alain V. over 6 years ago

Ok for closed but what about intermediate status?

For instance to have the possibility that the parent ticket switch "to test" when all the substasks are in "to test"

#14 Updated by Etienne Massip over 6 years ago

As I said before :

What you are using subtasking for is, as I see it, more of a replacement for some lacking level in the project -> issue tree, maybe phase.

What I meant is that maybe what you are asking for is not a parent task status autoupdate but some kind of another concept, somehow a simple group of tasks reflecting the progress of every one of them.

Or can't you simply use categories for that, as Category progress is displayed on the version overview screen ?

#15 Updated by Etienne Massip over 6 years ago

  • Category set to Issues

Also available in: Atom PDF