We use workflow conditions and issue links for this purpose. Several of our state transitions fire a condition to check "depends on" or "blocked-by" links' statuses before it allows the "parent" task to transition.
For instance, if ISSUE-1 has a blocked by link to ISSUE-2 then our condition does not allow ISSUE-1 to transition to resolved until ISSUE-2 is in the resolved state.
The plug-in Structure (referenced by Nic) is able to visualize issue relationships via these links.
Structure does not provide workflow conditions. We created a plug-in to provide workflow conditions that check the status of linked issues. This ensures we cannot close the "parent" issue without first closing the "depends on/blocked by/children".
We simply use Structure to visualize the hierarchy of issues using these links (which can be many levels deep vs. the one-level subtask hierarchy).
That's not quite right. There is a way to create sub-sub-sub-whatever Task. I cannot advise the trick, because you get lost your overview and sometimes there will be also created an Parent Task with Dead End - It has worked on JIRA 4 and I think it's still working on JIRA 5.
You can do it by a post-function called "Create sub-Task on transition" This post-Function can be also a part of an Sub-Task Workflow. you must choosen the Issuetype of the Sub-Task and also the Summary. Later you can edit this parts.
That's an worse hack but it's a way to do it.
ARG. Do not use these two tricks.
If you create a sub-task of a sub-task, you can break your data so badly that Jira will crash spectacularly. It is rescuable by deleting the sub-sub-tasks in the database, restarting and reindexing, but you really are asking for trouble.
Don't do it. Despite what mds said it is NOT WORKING in either Jira 4 or 5. It might look like it's working initially, and you could well be lucky and never run into whatever it is that crashes it, but it's not a sane risk to take.
I would recommend a good look at https://marketplace.atlassian.com/34717 instead (it's one of the workarounds, and probably the best of them, at least until Atlassian get onto JRA-4446)
we implemented workaround where i created a new issue type which follows same workflow as our sub-task workflow, and then when needing to break sub-tasks down further into separate tasks, we create this new issue type, and link it to be contained in the relevant sub-task. This works for us, but we also use the Gantt Chart plug in, and when doing it this way, the sub tasks appear under the parent, and the further breakdown then appear under the sub-task, which is what we wanted.
Then add your vote to Atlassian's issue tracker. This is a discussion forum, not something Atlassian use to get information about the potential improvements and how popular they are. (Although they do take ideas from here and turn them into improvement requests, they use votes on them to feed into their plans, not comments here) However, most people don't need sub-task of sub-task, and in places where I've seen it done (with addons or other systems), it tends to end up in a confused mess, with users going back to spreadsheets because they don't grasp the many layers.
Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs