Is it possible to link a Project Issue (Bug\Task) to Another Project ?

5 Projects (= 5 Products)

All 5 Products (= 5 Projects) share features = shared common components\modules

An Issue (Bug\Task) for a component\module in one Project (= Product) might apply to another Project (= Product)

* * * * *

Can I link Issues (Bug\Tasks) in one Project (= Product) to another Project (= Product) ?

Easily ?


5 answers

1 vote
Alex Christensen Community Champion Apr 20, 2017

You should be able to link any issues together as long as you have permissions to view/edit any of those issues.

Thanks Alex.

Instead of creating an Issue (Bug\Task) in one Project, copying it, and then pasting it to another Project, I simply want to link it to all other Projects to which the Issue (Bug\Task) will also apply.

Simple concept.  Save a lot of time.

However... will queries\searches for Bugs\Tasks in a Project (= Product) include linked Bugs\Tasks in another Project (= Product) - WITHOUT USING A PLUG-IN ?






Alex Christensen Community Champion Apr 20, 2017

Sorry, I see what you're asking now. No - what you're asking for is not possible without a plugin. A single bug/issue cannot be related to more than one whole project.

Without a plugin, you will probably need to create/copy the bug/issue in multiple projects. I would suggest having only one of the bugs/issues be the single source of truth and the others should just link back to that original bug - that avoids you having to update the same bug multiple times. Not an ideal approach, but I think it's the only way to acheive what you're trying to do in default JIRA without any add-ons.

So, if I am understanding correctly, you are recommending that I do what I originally wanted by creating a bug in a Project, linking back to it in other Projects to which the same bug would apply - but the limitation is that I will not be able to search for linked bugs in Projects ?

I will have the bug link in other Projects - but will have to go to the original Project in which the bug was created ?

The whole plug-in business is just atrocious.  This is basic functionality and there should be no need for an Atlassian Cloud subscriber to have to purchase additional "stuff" to make the product capable of performing something that should be included in the base product.


Alex Christensen Community Champion Apr 20, 2017

I could see your approach working like this:

  • A user finds a new bug and creates a new issue in Project A.
  • You find out a little later that this bug also applies to Project B, so you copy the original bug from Project A into Project B. You would then use an issue link to relate to two bugs together.
  • The bug in Project B will not be updated. All updates would go into the bug in Project A. This avoids you having to update the same bug in two places.
  • Once the bug is resolved, then you can close both the bug in Project A and the bug in Project B.

Since the bug is in both projects, searching for it in both projects is possible. If you open the bug in Project B, all you would need to do is just go to the bug in Project A, which is very easy because you would have linked the two bugs together. Does that fulfill your requirement here?

Could I not create a Project and then just create Versions - and then link bugs within a single Project ?

For example, Project X with Versions 1, 2, and 3.

Create a bug for Version 1 and link that bug to Versions 2 and 3.

The linked bug in Versions 2 and 3 will update and will be searchable ?

For example, I want to search for the bugs that are common (the original and linked) to Versions 1, 2, and 3 ?

Epics would be components.  So any Issues (Bugs\Tasks) would be created\assigned to specific Epics.

Basically, Project X > Versions 1, 2, 3 > Epics 1, 2, 3, 4, 5 > Issues (Bugs\Tasks)

Alternatively just use Versions 1, 2, 3 but instead rely upon the Component field that is in the default JIRA

* * * * *

What plug-in would I need to search for linked Issues across Projects - do have any idea or recommendations ?

We are considering Atlassian Cloud (JIRA\Confluence\perhaps BitBucket) for about 20 user seats.




Alex Christensen Community Champion Apr 20, 2017

Based on that structure, I'd change it up a little bit:

  • Create a single project.
  • Epics could represent each of your products, so you would have five Epics in this single project. A bug can only belong to one Epic, which is why I would use the Epic to track a product.
  • Use Components to track all of the common components/modules for those five Epics. A bug can belong to multiple Components, so if a bug affects multiple components, assign the bug to multiple components.
    • You could use Versions to accomplish this, too, but the name "Components" seems more appropriate here, personally.
Alex Christensen Community Champion Apr 20, 2017

And to clarify, I don't think you would need any add-ons to accomplish what you're trying to do if you go with a single-project solution like you or I outlined.

I'd suggest having a separate JIRA project for common components or modules. It seems that issues (new features/bugs etc.) would affect these components and not directly your products.

You can also use common "components" with the same name defined in each project and the use any filter you need on them. Of course you have to set the affected component in each issue.

Already having issues just creating a Reply and using this editor.  Formatting keeps getting lost.  Not very encouraging.


I will give a basic outline of what we are trying to accomplish.

Two (2) products (= Projects A and B):

A. Consumer

  • Product Name X
  • Product Name Y
  • Product Name Z

Products X, Y. and Z are essentially identical except for a few very minor differences.

Product Name X - Admin and very minor policy differences from others.
Product Name Y
Product Name Z - Single-seat license and cosmetic GUI differences from others.

Most of the time, an Issue (Bug or Task) in one Product Name applies to the other two.

Each Product Name will be the same Version number - such as Version a.b.c.d. (Basically one Product with 3 very minor build differences and hence 3 different Product Names).
We want to manage this Project by Version number.
Sprints will be managed by Version number.
We want to create a single bug in a Product Name and link it to the other Product Names when applicable - that is the most important thing - to save time.

Version > Epic > Issues

Version a.b.c.d
    Product Name X
    Product Name Y
    Product Name Z
         Bug (created in Product Z linked to Product Name X and Y
         for Version a.b.c.d)

Version e.f.g.h.
    Product Name X
    Product Name Y
    Product Name Z
         Bug (created in Product Z linked to Product Name X and Y
         for Version e.f.g.h)

B. Enterprise (only a single version with two (2) components)

Web Console
Local Agent

We want to manage by Version numbers of the Web Console and Local Agent.

An Issue (Bug or Task) will occasionally also apply to Project A.

Consumer [I suppose it is infrequent enough that we can identify these with a specially designated Tag or other means].

Web Console
  Version a.b.c

Local Agent

   Version d.e.f.g

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

919 views 3 9
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you