I am looking for definitions to what the various Linked Issues options are when creating an Epic

[Mitchell Whitman]

When I create a new Epic in JIRA there is a drop down for Linked issues and I can not find information anywhere on what those options do depending on what you select. I am attaching a screen shot for further clarity in the hopes someone can tell me what each option does.

[Steven F Behnke]

There is no behavior specific to them out of the box. They are simply descriptive links that allow you to arbitrarily link issues together.

You may search these issuelinks and certain plugins offer enhanced functionality for them.

For instance, I create fields like Feature Link, similar to Epic Link. I link inputted issues via a custom "Feature-Story Link" that I created. Finally, I display select child issue details on the Feature type. This is all similar to how the Epic type works.

[Mitchell Whitman]

Okay so really unless i set up some outside plug-ins selecting "Blocks" or "Clones" essentially doesn't do anything?

[Steven F Behnke]

I was less than clear.

Links offer a visual panel on both sides of the issue indicating the issue details and type/direction of the link.

Additionally, you can arbitrarily query 'issue in linkedIssues(JRA-123, "is blocked by")' to be returned a list of blocked issues.

My only intention with my previous comment was to state that the issuelinks are easily extendable to other business processes.

[Sean Reilly]

I know this thread is almost 4 years old now but I have the same exact question that was never answered here. What does each option do exactly? In other words, can someone please define what each of these nine options below does?

is blocked by =

blocks =

is cloned by =

clones =

is duplicated by = 

duplicates =

is caused by =

causes = 

relates to =

Thanks! 

[Deleted user]

They don't do anything.  There is no functionality aside from the written text.  Their purpose is to inform the human user in terms that are understandable what the link means in human terms.

Think of it this way - In Jira, you can make a note on an issue that it is related to some other issue.  This is "linking" the issue to some other issue.  If there were no label or text description of WHY there is a link, you'd just be left with "oh, these two issues are linked for some reason."  So Atlassian provided some basic labels like "is related to" or "blocks" to identify why the link is there.  The label doesn't do anything else.

[Sean Reilly]

Thank you, Matt! I should've replied here earlier because I figured this out myself a couple weeks ago by just trying every single definition as a ticket link. So, you are correct and it makes sense now. My Tech Manager also said that he has the ability to change these definitions, which is good to know. Although for my job, I mainly use relates to.

[Deleted user]

At the risk of being confusing, what I said is not 100% true.  IF you use Advanced Roadmaps (a Jira Premier feature), the "blocked by" and "blocks" links will serve as indicators for issue dependencies.  So, in that particular case, the label DOES have functionality, but it's limited to that product and that use-case.

[Andrew]

Is there any way to give functionality to issue links without an additional add on?

for example, say you have 10 tasks, and want tasks 5,6,7,8,9, and 10 to only be able to be opened or in progress once task 4 is complete. Is there any way to do this? if an add on is needed, what would be the easiest, preferably free add on to use?

[Sean Reilly]

Yes, as Matt said above, the "blocked by" and "blocks" can block out certain tickets. The best way I've found is to create test tickets and then try all of the different keywords to see what they do, but in your case you would only need to experiment with "blocked by" and "blocks". I don't know about add-ons or functionality in a hierarchy scenario as you are describing, but I'd imagine that you can just block them all individually or just add a note in the work order, but I know that's not ideal, so perhaps someone else here can chime in on that... If I have some free time, I will try to experiment and get back to you.

[Andrew]

Thank you for your response Sean!

I guess I just dont understand what you mean by the "blocks" or "blocked by" blocking out other tickets. I have tested those as issue links as well, and they are only visual-- meaning they dont block anything as far as I can tell. the issue still progresses through the workflow, even when it is supposed to not be allowed to until another issue is completed.

[dsilverberg]

Hey Andrew,

I'm learning Jira myself, but I do have the roadmaps feature enabled and was reading this thread trying to learn the definitions myself. However, i think I can help you.

Us Noobs need to stick together.

Blocks or Blocked by means one task must be completed before the other can begin.

the terms blocks or blocked by just differentiates between which ticket you are starting from.

for example. You cannot become President of the USA before you are 30 years old.

So Ticket A = Turn 30

Ticket B = Become President of the USA

If you are on ticket A and the you select Blocks Ticket B. Because the ticket you are currently on (turning 30) must be complete before you can start ticket B

If you are on ticket B then you select Is Blocked By ticket A. Because the ticket you are currently on cannot begin before you turn 30.

The actual functions this allows are things like mapping out visually what tasks need to be done before others can start. It also can trigger some things like email reminders. like "hey you turned 30! Now you can become president!"

[Monica Limas]

This is very helpful! I'm new to Roadmaps and I'm trying to figure out how to utilize the links function to help out with two things- a retro board and risks board. And advice on how I could utilize dependencies? My initial thought for retro is caused by, and link to the epic or initiative that created the action. I'm unsure where to go with a risks board other than relates to, which seems to be the easiest link to utilize for many reasons. 

You also stated blocks and blocks by can have an email trigger. Can you tell me where to find that info? 

Thank you!

Monica

[dsilverberg]

Hey Monica,

Glad you like my post, My first like! very exciting! :)

This is what you want to arrange things to happen when a linked issue is resolved. You can do more than simply send an email. But I'd be lying if I said I've done it myself.

https://www.atlassian.com/software/jira/guides/expand-jira/automation 

I have no advice for your boards  except to share two hard won pieces of information

1) Blocks and is blocked by are the only links that do anything in the software every other link is purely visual. "needs to be completed with" blah blah blah. These are all the same from a program perspective, the only difference is the words that display.

2) "Issue types" is a fake out. There are only three tiers of tickets in Jira that are inherently one below the other. Epics --> Story or task or milestone or whatever you call it (all identical technically) --> Subtask.

If you choose to have more than three layers in your mapping you will need to build them in artificially. In other words. Task is not inherently below Story. All issue types besides epics and subtasks are exactly the same on the back end except that they are labeled different.

So my current best practice is to use new projects and new epics much more than I used to. Instead of trying to shove in lots of stuff into one project I create new ones all the time. Leveraging filters i can see them all together when i need to.

Hope that helps

[Monica Limas]

Thanks so much for your help and reply, @dsilverberg!

[mikutech]

This has been a useful discussion. I looked for a while and couldn't find any official documentation about this, other than https://confluence.atlassian.com/jiracoreserver084/linking-issues-979408240.html#:~:text=Issue%20linking%20allows%20you%20to,An%20issue%20may%20duplicate%20another.

At my firm we don't have the Jira roadmaps premium feature, I don't think it's available for Jira Server editions. We have the following four default links:

1. relates to
2. duplicates / is duplicated by
3. blocks / is blocked by
4. clones / is cloned by

#1 and #3 have been thoroughly discussed in this thread and make sense. #2 is obvious. But what about #4? clones / is cloned by? Isn't that exactly the same as duplicates / is duplicated by?

Would be nice if someone from Atlassian would give some guidance on this, seems ridiculous that there isn't even a "best practices" for it in their documentation.

Mark

[dsilverberg]

@mikutech It would be nice right?

In their defense, I think they keep it so open ended because there are so many uses and opinions.

I would guess that clones are deliberate and duplicates accidental.

Cloning is an actual Jira function https://support.atlassian.com/jira-software-cloud/docs/clone-an-issue/

The company I work for uses this feature when we "graduate" a ticket from the planning stage to the development stage. 

The PM has a project customized to their workflow, and Dev has a project customized to their workflow.

The cloning happens at the handoff.

The PM team writes the ticket, then when they feel their specs are "complete" a duplicate with the content is created on a separate project with a link between them.

This allows the different departments to have their own ticket to play with in their own space. but still allows the PM team to easily watch the dev teams progress.

[mikutech]

@dsilverberg thanks for the explanation! Funny how that page doesn't exist on the Server documentation, yet closing exists in the Jira server as well.

The way we do it is that PMs / stakeholders write user stories for which the implementers would break down and create tasks for, thus we would never clone anything outright. Instead, those tasks are children of the user stories.

But that's the power/pain of Jira. You can do whatever you want...