Is it possible to auto-resolve JSD issues when their linked issues are released?

[Gil]

Hi all,

I'm trying to figure out how to do the following using Automation for Jira.

Scenario:

1. A bug or a feature request is raised in JSD.
2. Support agent creates a linked Jira issue (bug/feature request) in a Jira project.
3. That Jira issue is assigned with a fixVersion 1.0.0
4. The fix or new feature is deployed to prod.
5. I manually go to the Releases tab in Jira and mark version 1.0.0
6. Automation for Jira is triggered and looks for all issues that had fixVersion 1.0.0
7. It then looks if they had JSD linked issues. If true: Automation will auto-resolved (transition) the JSD issues to resolved status and add a public Jira comment.

So I know Automation for Jira has a trigger "Version Released"

The problem is that I am not sure what is the best way to filter the issues that have a fixVersion with linked support tickets.

Any ideas?

[Gil · Accepted solution]

Ok, I found it!

So with one simple rule, I'm able to transition JSD issues to RESOLVED with resolution FIXED when a bug/task/story is linked to a JSD issue.

• Create a rule in JSD with When: Incoming Webhook trigger and COPY the URL.
• In Jira System settings > Webhooks, generate a new webhook and name it Version Released
• Under Project related events, tick released.
• In the URL on that same screen, I also pass ${version.name} just to be safe it works.
• Save your Jira webhook
• Back in your AJ rule, you need to execute this automation rule with: Issues provided by running the following JQL search
• The JQL in my case is: 

issueType = "Technical Support" AND fixVersion = {{webhookData.version.name}}

•  Then a simple IF status condition
• Transition issue to Resolved. In my case, I have my Jira workflow that when a JSD issue is in status = "internally resolved" and it transitions to "resolved", to set the resolution field to FIXED (because I assume it requires a code change)
• I re-fetch the issue to get the updated status of my JSD issue and then add public comment for the customer.

The only manual work for me is to click the 'Release' button in Jira. In the future will hook it with Gitlab and it will be fully automatic.

:D

[Victor Seger]

Hi Gil,

Thank you very much for sharing your solution! I’m glad it worked fine!

Just as a suggestion, you don’t need to use the “re-fetch issue data”, since it updates the information inside the rule, instead of acting directly on your issue. So, to your use case, it will not have a practical effect and not using it can give you process advantages :)

In case you have any other question about this, please feel free to reach us again.

Cheers,

Victor

[Victor Seger]

Hi Gil,

Thank you for replying.

I saw that you and Stanislaw have some points that became quite confusing during this topic. So let me try to explain some aspects of your questions below:

• Is it possible to have a smart value in labels? 

Yes, it is. However, you can only add the smart values, not combining it with pure text. So, in your use case, you would use simply {{version.name}}. I even suggest you to set “Copy from issue” together with the smart values. Please see below:

But I wouldn't suggest you using smart values here, and I'll explain it further*.

• For the 1st rule, do I need to include an If condition after branch, in order to limit the editing action to only linked issues? 

Actually, you don’t need but you can if you want to as it will restrict adding the label only to Software issues that has linked issues with a "Causes" link type. Please see that this rule will add the label in each software issue that has the released version set as a value on the field “Fix Version/s”. 

This field is a default in Jira Software projects. Maybe my first explanation wasn’t that clear, and I apologize for that, but the idea is to only label the Jira Software issues.

As you can see in the example below, my Jira Software issue has 1.0 version in the “Fix Version/s” field. I have released this version. So, as my first rule demands, “1.0” became a label of this issue.

Below I send you a screenshot of what the 1st rule would seem if you choose to use smart values on it:

• Ok, and what will the second rule do? 

Everytime the field label is edited, if it contains the label added on the first rule, the second rule will check for all linked issues (service desk issues) to the trigger issue (Software issue with the desired label on it) and transition those linked issues to a  resolved status + add a comment.

*Note that unfortunately it is not possible to use smart values on the condition, so you will have to manually inform a value referring to a released version, which must have been already set as a label. That's why I wouldn't suggest you using smart values for labels on this scenario as it will make the maintenance of this rule quite complex. 

Look at the example below:

Instead, I’d suggest you to use a generic name as “versionreleased,” as below:

1ST RULE

2ND RULE

Please see that you don’t need to set “1.0”, “1.1” anymore. You can simply set “versionreleased” and Automation will filter all issues which contains this generic text as label, what is faster than manually specify all released.

After doing this filter, the rule will apply the “linked issues” branch and finally execute the actions configured. In this second rule, you will notice that I added an If condition between the branch and actions, in order to check if the issue isn’t already in “Resolved” status, avoiding it to transition again to the same point.

So, the actions of both rules will be combined and enable you to reach the desired result. :)

Could you please give it a try again and let me know how this works for you?

Look forward to hearing from you.

Cheers,

Victor

[Gil]

Hi Victor.

Again, thank you very much for the detailed reply. I now understand what you mean.

I think I'm a bit lost as to when I should use a global rule and when not.

The majority of my rules or local to their projects.

Recently, I started using global rules because I need to "bridge" between JSD and Jira software projects.

--

In any case, before I proceed with your suggestion, why is it not possible to use Jira webhook for 'releases'?

I created a webhook for releases in Jira system settings. I fed it with the URL given by the Webhook trigger which is a rule I set in JSD project.

I created a dummy version in Jira software. When I release the version, the automation in JSD picks up the correct version when I use the LOG action {{webhookData.version.name}} I can see the version value being passed on.

So releasing in Jira software, using a webhook in JSD project as a trigger and logging for {{webhookData.version.name}} value is working fine.

The problem is I can't seem to use this value and match it against JSD issues with that same {{version.name}} in JSD.

Any suggestions?

[Stanisław Juźwicki]

I think that was a typo in Victor's reply. You cannot directly label JSD issues in the first rule, because that would require nested branching (first branch: for all issues fixed in version, second branch: for all linked issues) and that is not possible. But definitely Victor is the expert here, so maybe he can comment :)

In my opinion, in the first rule you need to label the core (non-JSD) issues with a label and then the second rule would trigger on the (non-JSD) issues labeled and follow the links to the JSD issues. Using that assumption it is logical that the second rule should also sit in the non-JSD project.

Hope that helps :)

[Gil]

I think that was a typo in Victor's reply. You cannot directly label JSD issues in the first rule, because that would require nested branching 

I think it is possible IF it's a global rule. I'll give it a go later tomorrow.

Currently, I've tried to set up a webhook from Jira when I release a version.

What is working is that I can get the {{webhookData.version.name}} value, but I can't compare it to the fixVersions field in my JSD for some reason.

If this part is solved, then this is the better approach, using a webhook.

[Victor Seger]

Hi Gil Levy,

I'm Victor, from Automation for JIRA Support team.

So, by using as the rule trigger the “Version released” option, we could set “Issues fixed in version” as Branch and then an If Condition to limit only the issues with other SD project linked issues. The problem here would be that, to make the transition to the linked issues, we would need to use another branch inside the branch already being used, what is not available at this time.

So, similar to what nicely suggested by Stanisław Juźwicki, you could break your demand into two different and complementary rules:

1. Create a rule in which, everytime a version is released (trigger), in all issues fixed in version (branch), the label “version-released”- for example - is set into SF bug issues (action). Of course, you can set a custom field to attend this, but using a label would be faster and simpler. :)
2. Create another rule in which, every time the label value is changed (trigger) and it contains “version-released” (issue fields condition), for all the linked issues (branch), these issues will be transitioned and commented (actions).

Important: in order for the rules work together successfully, you need to check the box “Allow rule trigger” on the second rule details:

I hope it helps! Please let me know how this works for you.

In case you have any other problems or questions, please feel free to contact us again.

Cheers,

Victor

[Gil]

Hi @Victor Seger and @Stanisław Juźwicki 

Thanks for your detailed reply.

I did the 1st part as suggested. can you please confirm if this is what you meant:

I currently set the label value to: version-released.

Is it possible to have a smart value in labels? example: version-released-{{version.name}}

I set this rule as a GLOBAL rule.

The 2nd rule will be created in the JSD project. 

is this ok?

[Stanisław Juźwicki]

Hi Gil,

Not sure about smart values in labels, think it should work, but I hope Victor can confirm.

Your first rule looks ok.

As for the second - if I understood your requirement right, the second rule should also be global (or set to the core projects when you have your issues that are released), not set in JSD. This is because the trigger (adding labels) happens in the Jira core project, not in the JSD project. So the rule will have a trigger in a core project and the actions in JSD.

Edit: hmmm… I am just wondering whether you really need that condition "if linked issues present" in the first rule. I would think about "labeling" all the issues released in a version, also if they were not caused by a JSD issue - but that is another discussion I guess, not connected with this requirement. Even if you do not have that filter in your first rule, the second rule will only iterate over the links, so it anyway won't work on issues that don't have links.

[Gil]

Hi Stanislaw,

Let's review my rule.

1. It's a global rule because any Jira project that has versions released, can be linked to my single JSD project. Furthermore, I need to look at issues that are released in Jira projects and then edit my issues in the JSD project. Therefore, I must have this rule "sitting" above all Jira/JSD projects.
   
   
2. When a version is released in any Jira project.
3. Branch for issues that are fixed in this version
4. Do these issues have linked issues with 'Causes' type? If yes, then
5. Edit the JSD issue with a label.

So for #4 - I didn't know what to select, and "Are present" seemed appropriate because it's checking that the branch rule has released issues in this version with linked issues in JSD project.

Or, did I get it completely wrong?

Another way I'm exploring is using Jira builtin webhook. So when I release a version, Jira will fire a webhook and AJ will pick it up and transition the JSD issues.

[Stanisław Juźwicki]

Ok, maybe I got something wrong :)

In the original post you wrote:

3. That Jira issue is assigned with a fixVersion 1.0.0

4. The fix or new feature is deployed to prod.

5. I manually go to the Releases tab in Jira and mark version 1.0.0

From that I assumed that your non-JSD issues get labeled. But in your last reply you say:

"5. Edit the JSD issue with a label."

Which would mean that the JSD issues are labeled :)

[Gil]

Oh, that's because I'm following Victor's suggestion to label the issue.

My original post indeed referred to utilising the fix version field as a mechanism to pass the rule.

[Stanisław Juźwicki]

My first idea was to use a branch rule "for all linked issues". However you have to first use a branch rule "for issues fixed in version", and Automation will not let you use two levels of branching in one rule (performance reasons I guess?).

So then I thought about a bit of a barbaric approach :) Let's make two rules:

1. The first rule triggers on version release and has a branch rule "for issues fixed in version". What it does is to change a specially prepared custom field on all those issues; the custom field might be named "Auto-resolve linked JSDs" or whatever.

2. Then the second rule is triggered on this field change and has a branch rule "for all linked issues". Of course you can set it to follow only a specific link type and so on. Also remember to enable this rule to trigger from another rule.

The only potential problem I see is that this effectively does what (presumably) Automation folks at Codebarrel did not want us to do: create many nested rule executions. So probably some performance considerations might come into play if you use this extensively.

Hope that helps :)