Automation rule to edit the work items linked to the work items in a released version

[Parag Shah]

Folks,

Need help on a tricky automation rule that I am trying to setup.

I have 4 work items - A, B, C, D.

I have cloned B from A and D from C.

Created a version, 1.0.0 and included A and C.

When I release this version, I want label in B and D to be set to Released. These are actually the linked items of A and C.

I don't want to use any add-on like ScriptRunner. Native Jira cloud automation solution will be much appreciated!

[Trudy Claspill · Accepted solution]

Hello @Parag Shah 

You could accomplish this with 2 automation rules.

Rule #1 would be triggered by the version being released. It would loop over the items in that version and call Rule #2.

Rule #2 would look up the items linked to the items in the released version. It would iterate through the linked issues and transition them.

Let's start with Rule #1. It is pretty simple. When the version is released, collect the issues in it, iterate through that list, and take some action. For now we will use the Log action as a placeholder.

The above Log action will eventually be replaced by a call to Rule #2, supplying the item key of each item in the released version.

For Rule #2 we start with the basic structure that we can test to make sure it works

TRIGGER: Manual
FOR EACH: Related item/JQL
-- JQL: issue in linkedIssues("{{triggerIssue.key}}","is cloned by")
  CONDITION: Field Value
    Field: Status
    condition: does not equal
    Value: Released

  ACTION: Transition Item
    To status: Released

You may want to test this with a dummy project, dummy release, and dummy issues.

Trigger it from an item (abc-1) that has items linked to it as "is cloned by" to confirm that the items created by cloning abc-1 are found and transitioned.

In my example the status value is "A Done".

After you are sure that is working properly, then we modify the rule.

Change the Trigger from Manual to Incoming Webhook.

In the branch, change the JQL to:

issue in linkedIssues("{{webhookData.issue.key}}","is cloned by")

{{webhookData}} is the smart value for the data passed to this rule in the call to its incoming webhook.

From the Incoming Webhook trigger for this rule, copy out the Webhook URL value and the Secret value. We're going to use those in Rule #1.

Now, back in Rule #1 we are going to add a Send Web Request action after the Log action.

We'll paste the Webhook URL from Rule #2 into the Web Request URL field of this action. And at the end of that pasted URL we are going to add ?issue={{issue.key}}
That will cause the current issue referenced in the branch iteration to be passed through the webhook to Rule #3, where we extract it with the {{webhookData}} smart value.

For the Web Request Body we will select Issue data (Jira format)

In the Header section in the Key field we paste in X-Automation-Webhook-Token
And in the Value field we paste in the Secret from Rule #1

So, for Rule #1 we have:
WHEN a version is Released
FOR EACH item in the version
EXECUTE Rule #2

And for Rule #2 we have:
WHEN triggered
FOR EACH item linked as "is cloned by" to the item from the trigger
IF the item's Status is not Released
THEN transition the item to Released

The JQL in Rule #2 can be refined so it selects only the linked issues that are in a status currently that has a valid transition path to "Released".

[Bill Sheboy]

Hi @Trudy Claspill 

Another way to do this in one rule is using a dynamic JQL expression:

• the rule triggers on version released
• using the Lookup Work Item Data action, gather the items in the released version
• extract only the keys (or the linked work items directly from the results by link-type) to build a dynamic JQL expression using iteration, storing that in a Created Variable
• finally, use a Branch on JQL over the dynamic expression to act upon the relevant work items (or use the Bulk Transition endpoint to do this in one step without a branch)

One advantage of this approach is the Status check may be added directly to the JQL, thus it only attempts to process items which need the transition.

Kind regards,
Bill

[Trudy Claspill]

Thanks, @Bill Sheboy . You are the rock star of Automations!  I was not able to figure out how to get it done in one rule.

Can you show how we would build the third bullet?

[Bill Sheboy]

Hi, @Trudy Claspill 

A quick test showed me the inward and outward link type names are not available with Lookup Work Item Data in the issuelinks smart value (which I should have guessed as some linked data is found just-in-time :^).  Thus, an adjustment is needed to my suggestion...we need two lookup calls:

• trigger: version released
• action: lookup work items, to gather the ones in the version with JQL; add more JQL expressions as needed to refine it

project = myProject
  AND fixVersion = "{{version.name}}"

• smart values condition: to confirm something was found
  • first value: {{lookupIssues.size|0}}
  • condition: greater than
  • second value: 0
• action: lookup work items, to gather the linked ones to the first set using dynamic JQL, checking the status at the same time

(
  {{#lookupIssues}}
    issue IN linkedIssues( {{key}}, "is cloned by" )
    {{^last}} OR {{/}}
  {{/}}
)
  AND status != Released

• smart values condition: to confirm something was found
  • first value: {{lookupIssues.size|0}}
  • condition: greater than
  • second value: 0
• branch on JQL: now we use one last dynamic JQL to get at the work items

key IN ( {{lookupIssues.key.join(", ")}} ) 

• action: transition the work item

[Parag Shah]

Thank you both.

@Bill Sheboy I went ahead with your solution, for simplicity sake, and it worked like a charm.

@Trudy Claspill I will certainly try yours too and will update.

[Evgenii]

Hi, @Parag Shah 

You can use an Automation rule to perform the required actions.

When the rule is triggered, simply add a branch where you can:

• Select the linked issues based on a specific link type (e.g., "relates to", "blocks", etc.), Or "clones", in your case.
• Then apply the desired changes to those selected issues.

This allows you to automatically update, transition, or edit fields in linked issues.

[Parag Shah]

Hi Evgenii,

Thank you for your reply. However, it is not that straight forward.

I am aware about automation rule branching. I had already tried the method you have mentioned above but it is not working. That is because I need to loop through each work item in the version, find its related item and set its label. The rule has to trigger on Version Released.

Is it possible for you to tweak and test the rule on your side and provide me exact details step by step.