Also show subtask in the hierarchy (automatically define them as subissues)
Also show subtask in the hierarchy (automatically define them as subissues)
-
Walter commented
Works great! Thank you.
-
Russell, thanks for your comment. We are working on an idea how to have two-way sync between sub-tasks and structure.
-
russell.mull commented
The admin function is useful, but it's really not sufficient. My case is similar to Walter's; I want to use SubTasks for doing project-level decomposition because they work really well with greenhopper. But I'd like those to show up in the Structure view so we can track progress all the way up to cross-project requirements.
-
Walter commented
Yep, adminstrator conversion would be good to for existing subtasks. But we would still keep using GreenHopper (and the way it displays subtasks in it's boards) which means that new subtasks event should also trigger the creation of subissues.
-
Thanks for the idea. What we have planned already is some migration tool: an admin would have a button like "Create Subissues from Subtasks". It would scan all the issues (or issues from selected project) and make each subtask to be a subissue of its parent task. Optionally, it would suggest to use "Move Issues" to convert the issue type from Sub-task to a non-subtask type.
I think if we mix sub-tasks and sub-issues in the same hierarchical view in runtime, it would be confusing. To make things worse, it's possible that a subtask is a subissue, but it's parent task (in terms of subtasks) is different from its parent issue (in terms of structure).
What do you think - would administrator conversion actions be enough?
Thanks,
Igor -
Walter commented
With a flag (include subtask?) that can be set per project.
Hierarchy for tasks-subtasks cannot be changed but you could create subissues for a subtask.