Automation Rule to transition issue without knowing current status of issue.

[carlos andrade]

I developed an automation rule aimed at transitioning an issue to a REVIEW status; however, the rule's effectiveness is hindered by my lack of knowledge regarding the issue's current status. This limitation means the rule only functions correctly when the issue's present status is directly linked to the REVIEW status. To circumvent this, I'm contemplating the feasibility of retrieving the issue's current status. This would potentially enable me to systematically transition the issue through intermediate statuses until it reaches REVIEW. However, I'm uncertain about the practicality of this approach within the context of Jira Data Center, even though I have ScriptRunner at my disposal. Is there a viable method to implement this process effectively?

[Kalyan Sattaluri]

Hello, welcome to the community.

Actual requirement is not clear from your post. In automation, if you are working with an issue, you have access to its data using smart values like {{issue.status}} etc.

Anyways, I am jumping the gun. Please share an example of an issue and the criteria of when you want to transition this to "Review".

[carlos andrade]

Sorry. My question was poorly written. I can find out the status of the issue, but if that status doesn't have a direct transition in the workflow to the destination status I want, how can I transition that issue?

Thanks do much for replying.

[Kalyan Sattaluri]

@carlos andrade  - To clarify, you know your possible transition options correct? That is, an "Analysis" issue can only go to "In Development" or an "In Development" can only go to "Validation" status etc.

Because if you dont know that part, I suggest you first understand the transitions available for each status.

Now to the rule part:

I cannot think of any easy way to do this, maybe I am missing something and others can help you out with a solution.

But below is my solution and requires 2 rules,

---

First rule is your basic scheduled rule with JQL, which simply calls (sends a webrequest) to another (second, see below) rule with issue key in its  payload for each of the issues.

The second rule is where most of your implementation is.

Trigger - incoming webhook, which has issue key in its payload from  above step.. depending on how you send the JSON in step 1, you can access this issue key as {{webhookData.key}} for example.

Action - look up of the issue to get its current status.

----Now below you write series of conditions which check for status and transition to it next.

Condition - If {{lookupIssues.status}} equals to "Analysis"

Action - Transition to "In Dev"

Action - Send webrequest to this same rule with issue key to transition to next step.

Condition - If {{lookupIssues.status}} equals to "In Development"

Action - Transition to "Validation"

Action - Send webrequest to this same rule with issue key to transition to next step.

This series of conditions, combined with last step of sending a request back to this rule will take care of transitioning.

---

My solution is not straight forward and involves being familiar with advanced options of automation like webrequests / webhook. Not sure if you have worked with them before.. so let me know your comfort level with this approach..

Also, as mentioned, there maybe a simpler solution which I cannot think of right now so hopefully others can pitch in as well..

[carlos andrade]

>>To clarify, you know your possible transition options correct?

Yes. I know all the possible transitions options.

Thank you so much! I was thinking along those lines.

Will this work if the issue is currently in "Analysis"? Will it transition it first to "In Development" and then to "Review"? Would it transition twice in the same rule execution like you have it in your example?

"Analysis" -> "In Development" ->"Review"

[Kalyan Sattaluri]

hey @carlos andrade 

If you look at the second rule steps above, especially the condition section, the last action is that once we transition an issue to "In Dev", we call the same rule again, this time it will transition it from "In Dev" to "Review".

• Condition - If {{lookupIssues.status}} equals to "Analysis"
• Action - Transition to "In Dev"
• Action - Send webrequest to this same rule with issue key to transition to next step.

If you have not worked with webrequest / webhook before, I suggest you first:

• Get an access token first (see here),
• Then you start with rule 2, with trigger = incoming webhook. At this point you just need the URL from this rule so after you have the trigger, and set up an action -> log action and capture {{webhookData}}. Thats it, give it a name and publish.
• then start working on setting up rule #1

1. In rule #1, first step is easy, set up scheduled trigger. give one issue in JQL such as key = KKJK-123, of course this issue should not be in "Review" status
2. In action of rule #1, then you will choose action -> send webrequest, use the URL from rule #2 above, then give your credentials and do a POST to that endpoint with payload like below:
3. { "key" = "{{issue.key}}" }
4. Then run the rule #1 and checks logs of both rules, if rule 1 is successful, you will see in rule #2 the payload you sent...

above is the prerequisite. if you can do until here... then your rule #2 you can complete.

I can guide you on next steps but try above and share screenshots so I can help you if you get stuck.

[carlos andrade]

Brilliant! Thanks so much Kalyan!