Redmine

Well, I was aware of how RM handled this before I started implementing them, so my use is in line with the devs' intentions and it works well for me.

I think of parent issues as "empty containers", hierarchy-indicating placeholders designed to group related tasks together to help me organize my query/views. This is true for any items with subs - all "real content" (in the sense of items representing work) are bottom-level "leaves" in the hierarchy.

The parent issues' automatic updating based on changes to their subs (not just dates but priority, estimated time length) is very helpful - otherwise you'd need to remember to go back and edit the containers manually (i.e. they'd quickly get out of sync).

I also make sure that no one puts important notes into the "leaf" action items, as these in effect disappear when "done" - the parent containers of the action items also hold the ongoing commentary related to all their subs. Only when a containing parent gets flagged "done" as a whole do the associated notes then need to be extracted and summarized, and generally that's a manager's task.

Hope this helps. . .

I can understand this philosophy in some contexts, however I think people using Redmine manage their projects and their tasks in many other and legitimate ways than this one.

Usually, Redmine is open enough to offer ways to overcome intrinsic limitations, but in this case, Redmine itself imposes a limitation.

Imho, this limitation is as arguable as the answer to "what's the best management method" (which should be "it depends" (or "42" maybe ;)). Whether adhering to this subtasking philosophy or not should be an user choice...

Eric

Sorry for reviving the post, but this behavior threw me off a lot.

Couldn't this be an option? Something like "force parents to calculate priority, time and date from children".

I'd also like to have a toggle for this behaviour as an option.

+1

This behaviour can't be the default, it can be useful if you can control it from the parent or by task type.

http://www.redmine.org/boards/1/topics/41138

I'm not happy with this implementation and I agree that this behavior should be an option. I can totally understand that it works for many but for others, it is not suitable at all !

Hello,

Would you like to test the patch which address this issue ? #5490-82

You can apply it with the command git am some.patch