Jira Expressions: Workflow Transition to Look For Comment with Script Runner

[Rachael Axtman]

Hi! I am looking to create the following with Script Runner Cloud: 

• A validator that will look for variances of the word: test, Test, Testing, test in the comment of an issue
• If that word does not appear in the comments then the ticket cannot be transitioned and a pop up will appear that tells the user that testing information must be in the comments. 

I am also looking to create the following validator: 

• If a PR is merged (we are connected with Github) then a custom field must be filled out. If it's not filled out then don't allow for the transition.

[Oliver Siebenmarck _Polymetis Apps_ · Accepted solution]

Hi @Rachael Axtman ,

For the first case you'll want an expression like this

issue.comments.filter(c => c.body.plainText.includes("test") ).length > 0

Depending on how exact you want to match, you could also use .match() with a regular expression.

As for the second case, that's even easier you just need to know the custom field's id. Your validator could then look like this:

issue.customfield_10005 != null

There is a pretty good documentation for Jira Expression here.  

Hope that helps,
 Oliver

[Rachael Axtman]

Oliver, 

For the custom field is there a way for me to write something to detect status of a PR? 

The code you wrote on the first answer looks pretty close to what I came up with yesterday. Thanks again!

-Rachael

[Oliver Siebenmarck _Polymetis Apps_]

Hi @Rachael Axtman 

I had to poke around a bit and I am still not 100% sure it will work the same with Github, but here's what I found:

issue["customfield_10000"].includes('state=MERGED')

It's not really all that well documented, but it seems like the information from the "Development" field is always in the custom field with the id 1000. Unfortunately, the content of that field is not syntactically correct JSON, so you cannot just parse it with JSON.parse() and look at the different attributes. 

However, you can look for the corresponding "state=MERGED" string, which should work pretty well.

Best regards, 
 Oliver

[Rachael Axtman]

Thank you! 

[Rachael Axtman]

Hey Oliver - there has been an additional condition added to this and I was wondering if you could help. If the custom field is in a merged state then the issue can transition only if there is another custom field (fix version) that isn't empty. If fix version is empty and the PR is merged the user cannot transition their ticket as done. 

[Oliver Siebenmarck _Polymetis Apps_]

Hi @Rachael Axtman ,

I hope I'm getting this right. So, only if the PR is merged and fix version is not empty, then the validator should return true. That could look like this:

issue["customfield_10000"].includes('state=MERGED') && issue.fixVersions.length > 0

 The interesting part here is that you can link different expressions together with && (=AND) or || (=OR). 

The above example uses the native fixVersions field; if you are using a different you'll have to change that of course.

Cheers,
 Oliver

[Rachael Axtman]

You're wonderful! Thank you! I will get this setup and tested and let you know what happens 

[Rachael Axtman]

It did end up working, but it is requiring a fix Version even when there is no PR. I checked and the fix version field is not marked as required in our settings.

[Oliver Siebenmarck _Polymetis Apps_]

Hi @Rachael Axtman ,

So, if there is no PR you want to be able to just close the issue? In that case we will need to check for that, too. Here's how:

issue["customfield_10000"] == "{}" || (issue["customfield_10000"].includes('state=MERGED') && issue.fixVersions.length > 0)

 This adds another check at the beginning: If the development field (where the PR and commits appear) is empty, then pass immediately. If not, then it'll check if there is a merged PR and if there is a fixVersion present.

Cheers,
 Oliver

[Rachael Axtman]

Thank you so much, Oliver! You truly are wonderful for helping out. I'll try this out this morning and let you know what happened. 

[Rachael Axtman]

It worked out great! We had a use case that it didn't account for, but just ended up adjusting our error message to guide the users. 

Thanks again Oliver!