Ceate a task and subtasks cross multiple projects

[aquila jiang]

When I used  JIRA, I want to ceate a task in project a, this project will have four sub tasks, but the 
four tasks will belong three projects. task 1 and task 2 belong to project a, task 3 belong to project b,
task 4 belong to project c. I try to create this type task in JIRA, but failed. 
How can I create this type task in JIRA?

[Megan Baker]

Are there any plans to expand this to where you can have sub task cross projects?

[Nic Brough -Adaptavist-]

No, because it does not make sense to have sub-tasks in a different project to their parent.  And the problems presented by different permissions just become impossible.

[GregS]

So instead of supporting a simple way to handle this (e.g. if a user story requires changes in one or more microservices and a ui project....which have to be separate projects, because components can't be versioned) it makes more sense to force people to create tasks in each project and then remember to go back and manually add links for everything afterwards?

[Nic Brough -Adaptavist-]

Yes, getting people into a nonsensical position is not something that anyone wants to support.

Given the essays above on why it cannot work, could you explain how you think it could?

[GregS]

I don't know, I'm not getting paid to develop the product.  I'm just pointing out that it doesn't work for what seems like a fairly normal use case.  I can't collapse my projects because jira won't let you version components.  User stories may require changes to be made in multiple projects.  Only solution is to create all the tickets and then manually link them as a separate step, which seems extremely tedious and error prone.  What am I doing wrong here that is so nonsensical?

[Nic Brough -Adaptavist-]

Assuming that subtasks could exist outside any useful context for them.  Have a read of the problem statement and the answers to see what is nonesense.

I'd like to see versions on components too, for other reasons than the one you describe (which is also perfectly valid, just not the way I need to work).

[Jacek Kobus]

@GregS did you find a solution to your problem?

I have similar use-case to yours.

[Nic Brough -Adaptavist-]

I suspect GregS re-arranged the hierarchy into something a bit more sane, where sub-tasks are entirely a part of their parent issue (and hence in the same project)

[Boris Georgiev _Appfire_]

It's not very easy to undestand what are you trying to do. Please clarify the question.

You can not create sub-task of an issue in a different project. If you want a relation of issues between project user issue linking

https://confluence.atlassian.com/display/JIRA/Linking+Issues

[Boris Georgiev _Appfire_]

Do you really need different projects for that? What about using different issue types for different tasks and also different Project Components ?

[aquila jiang]

first, I have several projects in JIRA, I want to create a main task and this task has several sub task, these sub tasks belong to different project. Because I am doing a web project and I desigin a new business function. This function will be divided into diferent child functions, one is belong to web page designer, one is belong code programer. The designer and programer didn't stay in same project, so I need to create this type task.

[Nic Brough -Adaptavist-]

There is no way you can do this, as Boris first said.

An issue belongs to a single project. Sub-tasks have a single parent issue and hence have to be in the same project as their parent.

Links are there for representing cross-project relationships.

You either need to move your users into the same project, or use links to say "issue X is related to issue Y in the other project". I'd strongly recommend the first option, and use the fields to separate the data out.

There is a good logic behind this design - in a system that represents clear streams of work or distinct teams as "projects", having cross-project sub-tasks rapidly makes a complete mess that us humans simply can't unpick. I've seen it tried in a couple of places, and it's never worked - the projects end up messy, delayed and gridlocked, with managers screaming that they can't see what is going on and the developers unable to see what should be happening. Think it through as well - what happens if you have two projects with different permissions? You've suddenly got an issue that could have subtasks in the other project that a user can't even see...

[aquila jiang]

Thanks Nic and Boris your explanation.