How do others work with issues affecting multiple projects?

[Anthony Newnam]

We have one repository that houses many projects (buildable with different targets) at work. We have one team that supports the "platform" and several teams that each have their own products. Right now, we have one JIRA project per product and one for the platform. If a product team finds a bug, they could enter it in their project and then move it to the platform project if it applied to multiple products, but then it makes it difficult for a product to track all issues important to their product. If they leave it in the product project and it affects another product, then they can't track it easily. We could clone issues, but that seems like a big overhead in maintaining their state and not a good system since the clones don't get updated information.

It seems like the ideal solution would be if JIRA allowed an issue to be in multiple projects at once, but I suspect that is too integral in the JIRA architecture to happen.

Does anyone else have a similar situation and how do they deal with it?

[Renjith Pillai]

Also the Structure plugin may be of use in your situation to effectively track issues across projects.

https://plugins.atlassian.com/plugins/com.almworks.jira.structure

[Roger Day]

You can use a label in the issue, for example Project1, for issues in project2. Them modify the filter for the board in project1 to include the label. This will include the issue on both boards. 

I can then be assigned to sprints in either project. 

[Christian Czaia _Decadis AG_]

Have you thought of issue links? That way you can keep a single issue and when it affects other products you just link them. I could think of a single "dependency" issue in every project that you could easily link to and which could provide an overview of all the dependant issues ferom other projects.

Cheers

Christian

[Anthony Newnam]

You mean create a fake issue in each project that is "An Issue Depends on <PROJECT>" and then link to that issue? That's a creative solution. I'll think about that some more, thanks!

[Christian Czaia _Decadis AG_]

Exactly. You can configure the links as you like.

[Anthony Newnam]

Having thought about what you suggested some more, I don't think that will work out because it doesn't solve the reporting issue. It helps visibility some, but the data that JIRA generates for reporting won't be updated with the linked issues.

It seems like JIRA should be able to support an issue being in multiple projects.

[Christian Czaia _Decadis AG_]

Hey, you're right in terms of reporting...Sorry that I can't help you out here...

[Nikola Falardeau-Drouin]

But then... don't you need to go trough your workflow for every issue one-by-one? An issue status syncing option would be great wouldn't it?

[Roberto Caminos]

One of the projects we work on is a platform that supports multiple products. We created a single JIRA project but created multiple Scrum Boards for each of the products supported by the platform. We then use Labels to tag product specific stories and each of the scrum boards are filtered to only show issues with the product label.

It's been working well for us so far.

[Vasyl Krokha]

Hello,

There is "Multi Project Picker" plugin which could potentially help

[Noel Jans]

Anyone experience with this Multi Project Picker?

[Renjith Pillai]

I can comment on the way Atlassian handles this. The issues that are created in support may not be always directly usable in the Dev projects. You need to first validate whether it is actually an error, replicate an confirm the same, and then create a new issue in the dev project with a detailed explanation of the same, considering the project and all customers.

Once done, the support issue is linked (in comments or direct issue linking) to the dev issue and the support issue is closed. All futher collaboration is on the dev ticket.

There is another aspect that needs to be taken here is that, support tickets are not publich while dev requests are. So a direct copy of data from support ticket is not possible at all. You may also need to think about that aspect.

[epohl]

We have a similar problem...

We use Jira both for Support and for Dev projects, but in order to do effective version planning, we keep separate projects: One for all incoming support issues and then separate Dev projects for our various products.

When a bug comes into the Support project, we want to be able to easily create a corresponding linked ticket in the Dev project for the product the bug is in. Ideally, we'd like comments on the linked Dev issue to be copied to the open issue in Support.

Right now we have a custom plugin that enables us to create a Dev issue that makes a clone of the Support issue in the Dev project and links it, but we're dependent on a 3rd party to keep the plugin up-to-date and that's limiting our ability to upgrade Jira.

It would help if when cloning an issue, there was an option to create the clone in a different project. Right now it requires cloning and then moving - not ideal. I'd love to hear whether anyone has a better solution.

[James Sotelo]

Why not just build one project and boards for each team?

[Wliliam Rudy]

If I understand all this, you can link one issue to another issue, but can't link a single issue to multiple projects, which is what I would like to do.  For example, say I have a project for databases and one for GUIs.  A problem with a database GUI comes along, which impacts both projects.  I think it would not only be inefficient, but could create problems if they aren't in sync.  Logically, I should be able to create it in one project or the other and link it to the other.  Offhand this doesn't appear possible.  Am I missing something?        

[Nic Brough -Adaptavist-]

Not really missing anything, it is something people have problems with.  There are a couple of answers though.

The first one for plain JIRA is that people duplicate the first issue into the second project (and, ideally, link them of course).  This does sound a bit clunky, as you've now got two issues, and they won't be "in sync".  But, remember that the projects are there for different reasons, so although the initial issue should definitely be a copy, the projects work in different ways (possibly in terms of configuration, process, reporting etc, but the main difference is likely to be different people involved)

The second option kicks in when you've got JIRA Software - an issue like this should be an Epic.  Epics are broken down into stories usually, which then, well, have the same pattern above - duplicate issues in different places.  Epics, in this case, act as a much more clever form of linking.

[Wliliam Rudy]

Thanks Nic, but again, we don't want create 2 duplicate issues which must be tracked, updated, etc separately.  I can see where for some people in some situations that would work, in fact actually might be preferable, but not in ours.  

I'm going to give that "Structure" plugin that Renjith mentioned a go, hopefully that will resolve this....

[Noel Jans]

Anyone experience with this?

[Nic Brough -Adaptavist-]

With what? Your comment isn't tied to any particular answer, so we don't know what you're asking about.