Transitioning an issue when it gets linked

[Eric Brown]

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?

[andreas · Accepted solution]

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:

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

[Eric Brown]

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

[Eric Brown]

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

[andreas]

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

[mustafa korkmaz]

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.