How to make task/subtask in different projects?

Shivam
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 12, 2018

I have a system architecture where I have a backend api server, 4 apps. Accordingly, I have 5 different boards. Now, if I create a task/story in my server project, I want the ability to create 4 diff sub tasks across 4 diff boards as these all are dependent on backend server. As of now, I can only create sub task in the same project and then move it to different board, which is not a good way. Can it be achieved through current JIRA architecture or is there any other way I could achieve this functionality with minimum changes required? 

1 answer

1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 12, 2018

There are a couple of fallacies here:

  • Boards are not issue containers, they are views that select things you choose to see.  "Move issue to board" is nonsense, as they're not containers.
  • A sub-task is part of an issue.  An issue is contained in a project.  It does not make sense to say that a sub-task is in a different project to its parent issue.

But, yes, you can do what you describe.  You need to define your board filters so that they select the issues you want to see on each of them.  Your situation needs some slightly more complex filters than most of us need, but it can be done.

Tom Leser June 17, 2019

I disagree.  I've seen similar posts where people say you can't do this but you accomplish the same thing by linking to another issue type in a separate project.  

The benefit on the ability to move a subtask to a separate project is the usability and ease of creating the ticket and having the automatic link to the parent.  

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 18, 2019

I'm not sure what you disagree with.  A sub-task is part of an issue, and an issue lives in a project?  That's how it is, so there's nothing to "disagree" with there.  It's total nonsense to have a sub-task in a different project, they're part of the issue.

Like # people like this
Andre Schaub
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
October 2, 2022

@Nic : You seem to suffer from operational blindness.

An issue is defined a a problem or topic that needs attention or a solution.

It's absolutely common to seperate different development branches in different projects. E.g. you develop your Frontend in php and your backend in Java. Both can have absolutely differend needs, workflows, members and other needs. So you split these into different projects.

If you are working on a specific problem, e.g. developing a new workflow for a new product, the main project may be the frontend because 95% of the workflow happens there. So you place the issue in the project frontend.

But: you may need some endpoints for transferring data to your systems via the backend. These are tasks that have to be placed in the project backend.

For a halfway reasonable workflow you should be able to create tasks in different projects and link them.

Easy to understand as 1, 2, 3.

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 2, 2022

@Andre Schaub - you seem to suffer from operational blindness.

An issue is indeed defined as something that either needs a fix or a new piece of work.

It may well happen that an issue needs to be split up into lots of different parts.

So you give those bits to different teams.  Different stories (linked, of course), different projects (maybe, depends on how you want to work), and, and, and.

Again, the sub-tasks are for breaking down issues for a team,  not many teams.

Sub-tasks outside their parent issue is simply junk, it makes no sense and breaks every way of working (not just agile)

Like Deleted user likes this
Andre Schaub
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
October 5, 2022

@Nic Brough -Adaptavist- - sorry, that's crap. Or to put it nicer: that's a view from the capabilities of the given system not a view from the user's needs.

One more example: our development is split in frontend and backend. Different developers, different system, different programming language. Same database -> the user groups are frontend users and backend users. Backend user enters e.g. dates frontend user calls dates up.

Do you disagree in any way with this allocation? I don't think so.

Actually there's a case in which the external company which has developed the first version of our systems made a serious mistake. The backend AND frontend represent a specific user view/workflow. E.g. dates are meant as personal dates. The database represents group dates not personal dates.

That's on issue. Nothing special. Just one issue.

With several subtaks.

Some frontend subtasks, some backend subtasks. Yes. Subtasks, not issues. Come over and take a look. These tasks are subtasks. Not issues.

Moreover: putting these tasks seperated in different projects would be absolute bullshit.

So we MUST plan our activities and tasks as Jira allowes it. Not as we need it. That's crap and can be source of errors.

Take a step back and start thinking with a green field.

Like # people like this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 5, 2022

So you're taking a step back and re-organising your use of issues and sub-task into a sensible structure?  Actually using projects as containers for issues that need to work the same way because they affect one team or system, and then boards to represent a team's work?

David Harkins
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 15, 2023

My plan for this scenario is to use the sub-tasks to break down the individual issue within the current project.

If work is required form another project, then I will be using linked issues, which can then have their own sub-tasks

You could, however, create a sub-task for the required work from the other project, this then has the linked issue in the other project, which can then still have it's own sub-tasks.

This allows each team / project to work within their own workflow process as required, if not the same, and presents a more accurate to-do list to the viewing agents.

Like Nic Brough -Adaptavist- likes this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 15, 2023

Yep, that works really well.  It also gives you the freedom to work differently in the other projects without loosing track of the sub-tasks causing the work in the other project.

Like David Harkins likes this
Anne Gallant September 25, 2023

At one point Jira allowed you to do this because I have server data that does this exact thing.

Sub-tasks Across Projects.png

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 7, 2023

Jira has never allowed you to do this.  Your screenshots are not showing sub-tasks in different projects, the issue keys to the right of the display are coming from links or a field holding issues.

David Harkins
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 8, 2023

We have taken on the use of Scriptrunner Issue Picker fields.

Multiple Incidents link to a problem (Service Desk)

The Problem links to a Development Bug Issue in a project dependent on the component. Along with a number of FIX issues to have the fix applied to multiple active versions as required.

FIX issues for the same version are then linked to a Service Pack Issue (Service Desk)

Multiple Change issues are then raised from the Service Pack for all installations on that version.

All the above is managed & automated via Scriptrunner and populates issue picker fields, so that users cannot add or remove the links.

The same could be used to split work between different projects as required.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events