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.
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.
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.
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 =
is cloned by =
is duplicated by =
is caused by =
relates to =
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.
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.
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.
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?
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.
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.
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!"
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?
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.
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
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events