How to make task/subtask in different projects?

[Shivam]

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? 

[Nic Brough -Adaptavist-]

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]

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.  

[Nic Brough -Adaptavist-]

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.

[Andre Schaub]

@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.

[Nic Brough -Adaptavist-]

@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)

[Andre Schaub]

@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.

[Nic Brough -Adaptavist-]

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]

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.

[Nic Brough -Adaptavist-]

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.

[Anne Gallant]

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

[Nic Brough -Adaptavist-]

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]

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.