Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Transitioning an issue when it gets linked

Whenever an issue gets linked to another through the "Blocked" link type I would like to transition it to a "Blocked on task" status.

I want this to occur only for this particular link type so I was wondering if there is a way in the action condition to determine the link type that is being set.

The direction of the link will also influence which issue gets transitioned...

I.e.

Task A gets linked to Task B, where A blocks B.

Using automation I want to transition B to a "Blocked on task" status.

If B gets the trigger, with an "is blocked by" link, then transition B.

If A gets the trigger, with a "blocks" link, then transition linked issue (B).

(I have a misc workflow extension post-function that will unlock task B when task A gets completed)

Is this possible using the "Issue Linked" trigger with some conditions based on link type?

 

2 answers

1 accepted

0 votes
Answer accepted
andreas Community Leader Dec 20, 2017

Hi Eric,

So you can do this with an automation rule, but it's pretty complicated at the moment. I've raised https://codebarrel.atlassian.net/browse/AUT-678 to make this simpler in future.

Here's the rule you need:

link-directional.png

Here's how this works:

  • When an issue is linked (only triggered once - either A or B - it's the issue from which the link was added by the user)
  • Check if the linkType is 'Blocks'
  • Then we first try to find related issues with JQL and transition those to blocked (this is for if A gets trigger with a 'blocks' link to then transition B): 
    key = {{destinationIssue.key}} and issue in linkedIssues({{triggerIssue.key}},"blocks")
  • Then we have a condition on linked issues to check if:
    issue in linkedIssues({{triggerIssue.key}}, "is blocked by")
  • If that's true then transition the trigger issue to blocked.  This is for the if B gets the trigger with 'is blocked by' link scenario to transition B.

 

Hope that makes sense.  I used 'Log action' for debugging, but you can just replace those blue actions with 'Transition issue' actions.

Cheers,
  Andreas

Hi Andreas,

Thank you so much, this worked like a charm.

Not sure if it is a worse solution but in the end I used a JQL search twice. Once to look for the trigger issue in the list of issues blocked by the destination issue. If found I transition the trigger issue.

key = {{triggerIssue.key}} and issue in linkedIssues({{destinationIssue.key}},"blocks")

And then once to look for the destination issue in the list of issues blocked by the trigger issue (the reverse situation). If found I transition this one.

key = {{destinationIssue.key}} and issue in linkedIssues({{triggerIssue.key}},"blocks")

At worse I do one search too many but is makes the whole logic really simple. I tested it setting multiple links at once and it turns out the trigger gets called multiple time so this situation is covered as well.

Thanks again,

Eric

linktrigger.jpg

Btw, while looking for a solution to this I looked all over for documentation listing the sort of info I can get from the action (things such as triggerIssue and destinationIssue) but I could not find anything.

Is there a way to "dump" this info in the audit? for instance if I put {{triggerIssue}} in the audit I will get the whole information on the issue, but I could really use the level above listing the parameters available from the trigger.

Thanks!

Eric

Hi Eric,

Yeah your solution is fine too.  Searches are cheap in Jira. Also I think your solution is actually better than mine - uses less searches - mine would have run a search for each linked issue.

And yes, we're going to improve in-product help around smart-values in future.  We'll continue to make our fields easier to use (so you don't even need smart-values), plus add some kind of auto-complete/preview for them: https://codebarrel.atlassian.net/browse/AUT-104

Cheers,
  Andreas

Hey Andreas,

 

thanks for your great support first.

My case is little bit different:

I've a service desk project. One request type of the project is "Vacation". This "Vacation" request type is a change request.

I've externally a Personel Management project. 

Each employee has an unique "Employee number"; in my project this is a text field.

Notice that there is no change request issue type in "Personel Management" project. Instead, there is a sub-task which names "Vacation".  

 

So, when an employee has landed in service desk

and raise a request by giving his employee number regarding "Vacation",

I would clone all info that belongs to the service desk project's ticket("Vacation" Request type Change request issue type), to the "Personel Management" project ticket ("Vacation" sub-task issue type).  

 

Note that the screen configuration is identical.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Marketplace Apps & Integrations

5 mobile apps for Jira Cloud to boost productivity

  It’s very important to have access to the workflow process from anywhere. Especially if you manage the work of others. There is no difference whether you’re out of office, or drive a ca...

224 views 2 5
Read article

Community Events

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

Events near you