Automation Rule: Add a label to an issue when it has been linked to a Bug or Incident

[Richard Herrada]

After a bug is closed there are often a number of tickets that need to be worked on to ensure that this does not happen again and/or to clean-up any related issues caused by the bug.

I would like to build an automation rule (or rules) that adds a label to any ticket (for the purposes below I will use "task") that is linked to a Bug so that we are able to identify what % of them get completed throughout the year.

I've been able to build the following rule:

• When you are in a task and link that task to a Bug, add a label to the task:
  • Trigger: Issue Linked
  • Condition: Issuetype = Bug
  • Branch: For Destination Issue
    • Action: Add a label

What I am having trouble with is figuring out the condition for:

• When you are in a Bug issue type and link a task, add a label to the task.

Key things to consider:

• The trigger for "Issue Linked" uses the following rule:
  • Rule executes when an issue is linked to another issue. {{issue}} will always refer to the source issue, so if ISSUE-A is blocked by ISSUE-B, this rule will execute on ISSUE-B. To access ISSUE-A, use {{destinationIssue}}, and to access the link type, use {{linkType}} (e.g. {{linkType}}

Some workarounds I've put in place for now:

• Within the Bug issue type, when a manual trigger is selected add a label to any/all of its linked issues
• When a Bug is updated (i.e. status changed, assignee updated, etc.), add a label to any/all of its linked issues
  • For some reason linking a task to the Bug does not trigger the rule. Therefore you have to actually make a change to the ticket itself (i.e. status, some other field).

Any ideas?

[Mark Segall · Accepted solution]

Hi @Richard Herrada - What type of link are you using?

[Richard Herrada]

Hi @Mark Segall i am trying to build the rule such that it can be any type of link. That way user error is lower.

That said, one of the workarounds I was able to identify was: I can make the rule work if I build the rule based off the link type and not build a condition around issue type.

However, I fear (and the feedback I received from stakeholders) was that users may not select the correct link type and therefore our data would not be as accurate as we hope.

[Mark Segall]

Got it.  So is there a reason why you have the bug condition?  Does a bug get a different label than a task?  If so, you could try this:

• TRIGGER: Issue Linked
• BRANCH (JQL)

  • key = {{destinationIssue}} AND issueType = Bug

  • ACTION: Edit Issue (Label)
• BRANCH (JQL)

  • key = {{destinationIssue}} AND issueType != Bug

  • ACTION: Edit Issue (Label)

[Richard Herrada]

The reason for the condition is because without it if we link any task to any other task then it will add a label which we don't want. We only want the label added to tasks that are linked to our Bugs.

Just to take a step back, this is what I am trying to do:

• As a product manager, I'd like to track any tasks that have been linked to a bug, to ensure that all tech debt has been resolved as a result of the bug.

At our organization, the workflow for bugs is:

Prod bug occurs > we quickly resolve it > we perform a retro > during retro create tasks > we link the tasks to the bug > (this is what I am trying to figure out) linked tasks automatically get a tag/label or something else so we can track the tasks and build metrics.

[Mark Segall]

Got it... So you could potentially tweak it like this:

• TRIGGER: Issue Linked
• BRANCH (JQL)

  • key = {{destinationIssue}} AND issueType = Bug

  • CONDITION (Advanced)
    • {{issue.issueType.name}} 
    • Equals
    • Task
  • ACTION: Edit Issue (Label)
• BRANCH (JQL)

  • key = {{destinationIssue}} AND issueType != Bug

  • CONDITION (Advanced)
    • {{issue.issueType.name}}
    • Equals
    • Bug
  • ACTION: Edit Issue (Label)

[Richard Herrada]

Hi @Mark Segall

The test I am performing for the below is: I am in the bug ticket and link that bug ticket to a task.

When I tried the above:

I got the following "no actions performed message":

Which spawned the idea to try:

But I got the following "no actions performed message":

From what I can tell by looking at the second rule, it seems like even though the JQL condition is referencing the "{{destinationIssue}}" (Bug) it is still running the query against the "{{issue}}" (Task).

[Mark Segall]

Sorry - Error on my part. Let's replace triggerIssue with issue in those two conditions (I've updated my last post):

{{issue.issueType.name}}

[Richard Herrada]

Hi Mark, the proposal did not work.

This is what I tried:

This is the no actions performed message:

I've been playing around with the lookup function to see if that is a possible solution.  But I haven't been able to nail it down. Thoughts on using that function?

[Mark Segall]

Let me take a step back on this.  I don't think Lookup Issues is necessary.  What if we just do this:

[Richard Herrada]

Thanks again for the response @Mark Segall !  Upon attempting the above, I received the following No Actions Performed message:

[Mark Segall]

Are both of these issues on the same project? I ask because if they're on different projects, you'll need to update the project scope (rule details).  This would need to be done by a Jira Admin under Settings >> Global Automation.

And for the IF condition did you make sure to change it so that it acted as an OR instead of AND?

[Richard Herrada]

Yes they are.

[Mark Segall]

Sorry to ask again, but can you confirm whether the two issues are in the same project or not?

[Richard Herrada]

Sorry for the confusion.  Yes, they are both in the same project.

[Mark Segall]

Ok - No idea why it has to be set up this way, but I got it to work when I did this:

For some reason, when you use a JQL, it automatically adds "AND Key != {{destinationIssue}}" which makes no sense to me.  So, I went with the above and it worked for me no matter how I set up the links.

[Richard Herrada]

@Mark Segall You did it!!  This seems to be working beautifully. Thank you so much!

The below are the tests I performed to ensure it was working properly.

Test 1: Successful

• I am in Task 1 and link a ticket to Task 2.
• Expected outcome: neither ticket gets a label.
• Actual outcome: neither ticket got a label.

Test 2: Successful

• I am in a Bug and link a Task.
• Expected outcome: The Bug and Task should receive a label.
• Actual outcome: Both the Bug and Task received a label.

Test 3: Successful

• I am in a Task and link a Bug.
• Expected outcome: The Bug and Task should receive a label.
• Actual outcome: Both the Bug and Task received a label.

Test 4: Successful

• Task 1 is linked to a Bug. I am in Task 2 and link it to Task 1.
• Expected outcome: Neither of the Tasks nor the Bug should receive a label.
• Actual outcome: Neither of the Tasks nor the Bug received a label.

[Renee Niewald]

Is there a way to do this where the destination is in a different project? 

[Mark Segall]

Hi @Renee Niewald - Yes.  You need to make sure the rule scope is set for multiple projects or global.  This is done from System >> Global Automation.

[Renee Niewald]

I think my use case may be different but maybe you can still help. When we have Incidents we want to track the follow up work. There are 2 ways we know there will be follow up work: 1)followUp label is added to the Incident in project "Incident Response" OR 2) An issue is linked to the Incident in project "Incident Response" but it may be in a different project space" 

In each case, we want to ensure the followUp label is added to the Incident and the linked issues.

[Mark Segall]

Since this is slightly different and so that this can be easily findable later, can you please create a new question and @mention me in it?

Thanks!

[Richard Herrada]

@Mark Segall if the rule is Global, which is how I set up my rule, the solution should still work.  If I have a bug in project A and create a standard issue (for simplicity call it a task) in project B, the rule it will still add the label to the task.

Feel free to @mention me in the new question if you'd like to collaborate.