why are sub-tasks so awkward to set up?

[Ray Kiddy]

I had built my own web-based tracking system. Thankfully we are using JIRA so I can get back to, you know, real work. But I made it so that any issue could be a sub-task of any issue, because, well, duh. It just seems so obvious.

Yet with JIRA one gets a sort-of issue as a sub-task and not all the fields are offered or look the same or behave the same. Why?

The fact that every issue should be relatable to any issue in this way just seems really, really obvious. Should i file an enhancement request?

[Maya S Chase · Accepted solution]

You can assign a sub-task its own screen, or the same screen as a parent issue, or make a custom issue type to be a sub-task. So, the fields are just a matter of massaging it in the admin.

The only real restriction you have is that a sub-task cannot have a sub-task - you only get one level. There's a discussion of this very thing here http://forums.atlassian.com/thread.jspa?threadID=22788&start=0&tstart=0 so you may find some useful info there.

[Ray Kiddy]

Did all these forum post get moved to answers.atlassian.com? Is there a bug somewhere that I can mark with a hearty "yes, please"? Thanx.

[Maya S Chase]

Allow sharing a sub-task between parents is a feature request here: https://jira.atlassian.com/browse/JRA-24776

Allow sub-tasks to have sub-tasks is a feature request here: https://jira.atlassian.com/browse/JRA-4446

[JamieA]

For what it's worth, IMHO you're completely correct. It's an arbitrary restriction. You may want different workflows and fields for the subtasks, but often you do not, and have to set up various sub-tasks the same as parent issue types is a royal pain. In the same spirit, you should also be allowed any level of subtask nesting.

[Nic Brough -Adaptavist-]

>Yet with JIRA one gets a sort-of issue as a sub-task and not all the fields are offered or look the same or behave the same. Why?

Because you've configured them to be different. A sub-task *can* be the same as a top-level issue, but it doesn't have to be. In a LOT of cases, the reason for using sub-task types is precisely because you don't want the same characteristics. (Simple example - Top level "change" issue type will have justification for the change, then the sub-task of "staging deployment" will have fields dealing with testing and giving servers and environment details, then the sub-task of "Live deployment" will deal with impacts on other runing systems. And so-on).

>The fact that every issue should be relatable to any issue in this way just seems really, really obvious. Should i file an enhancement request?

I think Renjith's answer covers that - linking is designed for creating those relationships.

[Ray Kiddy]

The one common thing about all the issue types is that they presume to take some time to execute. Therefore it would be valid to roll-up time-to-completion estimates for any issue type. Again, linking does not give you this.

[Nic Brough -Adaptavist-]

No, it's not supposed to, and it would be completely arbitrary too - linking is there to say "this issue has a relationship with that one for some reason". I don't want time to roll up because an issue is documented/duplicated/mentioned elsewhere, that's utterly wrong.

If I want time to roll up, I use sub-tasks. That's what they're for.

The ideal situation would be to bin sub-tasks and change linking so that administrators can set a flag on the link type that says "this type of link makes the issue part of X". But you'd also need to protect these so that an issue cannot be part of more than one "Parent" and the "Parent" couldn't be made part of any of it's own issues. (And the code for working out time could be torturous)

[Ray Kiddy]

Ooh. Can we talk about multiple inheritance in categorization? Fun stuff. This reminds me, though, of the joke about the lawyer who got to St Peter's gate and said "Why am I here? I am only 47?" and was told "Really? By your billable hours, you are 105."

It is conceivable that an issue could have two parent issue. Parcelling out the time and resource use, though, would be a nightmare.

[Nic Brough -Adaptavist-]

Exactly why I'd try to say "you can't have more than one parent" - not because it's structurally wrong, but because you'd not be able to parcel out the time!

And yes, I think you'd run into the billable time thing too, if you don't have inherited levels instead of a fee-for-all

[Renjith Pillai]

What you need is actually acheived by 'linking' of issues, where you state the relation between issues.

[Ray Kiddy]

I can link issues, but the semantics of a link is more general that a "sub-issue". Also, if an issue has linked issues, I do not get a roll-up of time estimated for completion from linked issues. That is one of the more valuable feature of the "sub" in "sub-task" and linking does not do it.