Redmine

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 ?

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

You mean like grouping tasks for a project phase ?

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

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

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

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!

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 ?

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

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

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.

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?

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 ?

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"

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 ?