nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Any option other than regex to perform workflow validation?

Sue Wilson

I'm a long time JIRA Server Admin and just recently switched to JIRA Cloud Admin. We installed Scriptrunner to help with some workflow and reporting use cases. I have found the Cloud version of Scriptrunner extremely disappointing. Everything we wanted to use it for is not there OR isn't admin friendly to configure.

My primary scenario is this:

We have Resolution + two custom drop downs, let's call them Defect Resolution & Defect Root Cause. The requirement is to either show only those Defect Resolutions that apply to the Resolution selected or display an error to pick an appropriate one. Then, Defect Root Cause should be appropriate to the Defect Resolution selected. I know I can use a Cascading Select for Defect Resolution -> Defect Root Cause, but that only resolves half the issue.

In server, most, if not all, of this could be resolved using Behaviours and/or validations using groovy scripting. Neither of these features/functionalities are available on Cloud.

I've looked through a lot of documentation for different plugins and they all seem to point to the use of Regular Expressions. I have only ever written one or two simple regex before and believe this ask is much more complicated than regex may be able to handle, but with my limited knowledge, I'm not even sure.

So, I ask you a) is there an alternate solution or b) is regex capable of handling this complex requirement and, if so, 3) how do I even get started writing the regex I need?

Any and all suggestions would be much appreciated!

Sue

Comments

Mike Rathwell

Hi, @Sue Wilson

I feel your pain. I have been there and do miss the crispness of Groovy along with the features that don't exist in Cloud.

However...

I did see that ScriptRunner behaviors are coming to Cloud. Other than that it will exist, I do not know if it will bring the full panoply of features to Cloud.

I keep ScriptRunner because it has some good stuff in Cloud but I also really recommend adding Jira Misc Workflow Extensions to your environment as well. It is intensely powerful and let me solve a lot of the things you are facing.

Sue Wilson

Hi @Mike Rathwell the struggle is real.

Funny story....I was asked to review Scriptrunner because the users wanted it so bad. I compared it to JMWE and actually leaned toward the latter myself, mostly because of the former's limitations. I agree, having Scriptrunner in the arsenal isn't a bad thing, but the organization had me go through a complete JIRA audit to remove everything not in use and everyone not using. So, keeping this one around when it failed their expectations isn't an option. Oh well, moving off my soap box. I'm going to give JMWE a shot and see if I can't get this one solved. Thanks so much for your input & suggestion!

Mike Rathwell

The OTHER thing I use JMWE for, @Sue Wilson , is for a lot of the automations that Automation for Jira is ostensibly supposed to do.

I have found the selectivity, validation, and consistency to be a soothing balm, not to mention it can deal with attachments because attachments are a Thing. I took to doing the real automation at a system level in JMWE and let project admins do their snowflakey things in Automation for just their project.

Sue Wilson

Ah, yes. In the prior life, we had Scriptrunner & JMWE for server, among others. So much functionality. I used to automate in that way, too. Came here and Automation is included, but nothing like what I was used to. Seems a bit clunky and does not always provide the expected results. Would be great to have an alternate way to automate. We limit the Project Admin power to a select few. I've seen it used & abused too many times. I'd rather take the time to address their wish list than clean up after them.

Darryl Lee

Hey yeah, so yeah the thing with Cloud is, all validators and conditions use have to use something called Jira Expressions, and that's the case whether you're using ScriptRunner, JMWE, or any number of other options.

To your question, it's very possible to do validations like you need, with Jira Expressions. I don't think you necessarily need to use Regular Expressions, but you definitely will need to learn (or copy) Boolean logic. I wrote a bit about this, and have pointers to various "recipes' and examples:

Jira Expressions - But Why?

Here's one that I did a while back, that's probably applicable to your case:

"Foo" or "Bar" Part (13461) can only be selected if Build Phase (13719) is Alpha or Beta.

(!['Alpha', 'Beta 1', 'Beta 2'].includes(issue.customfield_13719.value) && 
![Foo, Bar].includes(issue.customfield_13461.value)) || 
['Alpha', 'Beta 1', 'Beta 2'].includes(issue.customfield_13719.value)

If you run into trouble, post what you've tried here, and we can try to help you out. :-}

Darryl Lee

Oh boy, this brings back some memories (and headaches).

A few tips:

Install Expression Tester. It's FREE, but I would pay money for it. No no, I take that back. But it is invaluable for debugging.
Remember this tiny bit of the REST API:
https://YOURHOST.atlassian.net/rest/api/3/issue/TESTISSUE-17

So then, you might see this in the REST API:

  "customfield_10049": {
     "self": "https://YOURSITE.atlassian.net/rest/api/3/customFieldOption/10016",
     "value": "Some Resolution",
     "id": "10016",
     "child": {
       "self": "https://YOURSITE.atlassian.net/rest/api/3/customFieldOption/10018",
       "value": "Some Root Cause",
       "id": "10018"
  }

This will show you the syntax for the fields you'll be referencing with Expressions. Then with Expression Tester you could start playing with Boolean Expressions like:

issue.customfield_10049.child.value == "Some Root Cause"

Where, if your test issue has a cascading child value of "Some Root Cause" then that would evaluate as true.

You can combine these with && and || (for me this is where the headaches come in) to create more elaborate tests. But with Expression Tester, you can try them against specific test issues and figure it out.

Leonard Hussey

As I'm lazy, for the REST API call mentioned by @Darryl Lee, I always append:

 ?expand=names

... so I can search the name of the field, and from there get the desired customfield_xxxxx

And does not hurt to have a JSON parser add-on already installed for pretty printing the output.

Darryl Lee

Oh man, great tips. I don't even think I knew the ?expand=names trick so I was just looking in the ticket for option names that matched. :-}

For Chrome I use:

JSON Viewer (Chrome extension for viewing JSON files)
- You'll need to enable it to "Allow access to file URLs" to view downloaded rules.

Firefox has a built in JSON viewer, which is nice.

Bogdan Gorka

Hi @Sue Wilson

For me regular expressions was also something I wanted to avoid. This was simply hard for me to understand. However, this is sometimes very useful in Jira Automation and in other plugins so I finally decided to learn it at any price.

The good news is that it turned out to be not that difficult (and I am not a developer).

I found this YouTube tutorial and the rest was 'plain sailing'. I highly recommend this to you as well; maybe not specifically for the use case you described but for other occasions.

https://youtu.be/rhzKDrUiJVk

Mike Rathwell

I should have mentioned that there are some stellar regex testers available. When you don't live in regex, as many of us don't, one needs a bit of guidance with syntax to get it right and avoid unfortunate regex-induced faceplants.

The three I keep in my bookmark list (each has it's own flavor and abilities; I often bounce one off the other) are:

Sometimes you just can't avoid it...

Darryl Lee

So I was thinking about this some more, and having created complex validators in the past, I have to say, you shouldn't do this.

@Sue Wilson you wrote:

I know I can use a Cascading Select for Defect Resolution -> Defect Root Cause, but that only resolves half the issue.

Why won't a Cascading Select work? It's exactly what you're trying to replicate with Validators, but if you use Validators, you violate a key user interface/experience principle: Don't Piss Off Your User.

Here's some thoughts:

To make this clear, you'll have to add a bunch of description text for the fields, saying "Hey remember if you choose Resolution X make sure that you only choose X Root Causes, not any of the other ones."
When somebody chooses the wrong option and then hits Submit they get an error message. They shouldn't have to hit Submit to figure out what the rules are.

Good UI makes it easy for people to do the right thing. Using Validators here makes it hard.

So I'm going to guess maybe that the reason a Cascading Select won't work is because you actually want users to set a Resolution.

I have a workaround: add a Done step (or insert a step before your last step) and automatically set the Resolution using Automation Rules to match the parent option from the Cascading Select field.

Here's how it would work:

The world's most boring workflow:

Screen Shot 2022-05-25 at 10.38.24 PM.png

And here's a cascading field Resolution/Root Cause

The primary values match the real Resolutions (this is important):

So you need a Validator to make this field required in the Resolved transition screen: Screen Shot 2022-05-25 at 11.16.31 PM.png

You might want also want to create a Validator to make sure a Child value is selected. JMWE and ScriptRunner both let you do this with a scripted validator (known as "ScriptRunner Script Validator")

Automation time!

It's time to write an Automation Rule! (Don't worry. This is how you do things in Cloud. it's built-in, and it's incredibly powerful.)

The rule is below:

So the cool thing is, Automation is smart enough to let you set the Resolution to the value of the parent option in the Resolution/Root Cause custom field, using the Smart Value {{issue.customfield_10106.value}}. This is why it's important your custom field's parent options match your Resolutions exactly.

So NOW when you transition from In Progress to Resolved, there is a split second or two where it says "Resolved", but then it will flip to "Done" automatically, and set the Resolution to match with the parent option from the Resolution/Root Cause custom field, as shown below:

I realize this is a lot to take in, but honestly it's WAAAAY more maintainable than hacking together a validator, and most importantly, it is WAY more user-friendly to the user.

Caveats

You probably should scope your rule to just the one project where it should work.
If you need this rule to work across multiple projects, you might need to upgrade your Cloud plan. Alternately if it's just a few projects, you could just copy it for each project.
There's like a split second where the "Resolved" step shows up and it's possible that somebody might be fast enough (or Automation might be slow enough) where they could manually click Done before the rule fires. So it might make sense to use the Hide From User condition for the Automatic Done transition to avoid that edge case.

Darryl Lee

If you really miss ScriptRunner, you could probably use a Post Function to set the Resolution from the parent option of the Cascading field (you might even need Groovy for this!) and use the "Fast-track Transition Issue" post function to move it to Done.

Sue Wilson

@Darryl Lee I'm not quite sure I understand all of the above. I was able to validate the correct Defect Resolution is selected based on Resolution selected. Now that I have that worked out, the next step would be to validate the Defect Root Cause options based on the value of Defect Resolution. I feel like, to make this work, I may need to repeat similar validators against these two fields and place them after the initial Resolution=>Defect Resolution validations? Automations don't do validations, so I don't know if using it here would help other than forcing a specific selection, except there are multiple possible options. Am I misreading the intent?

Dirk Ronsmans

Just a side note since you mention Behaviours on Cloud, they are actually in Beta right now!

https://www.adaptavist.com/products/atlassian-apps/the-future-scriptrunner-for-jira-cloud

Darryl Lee

Hi - sorry, I was basically suggesting you not do what you're doing. :-}

As you mentioned in your original post, a Cascading Select would probably get you the data you need, letting you perfectly configure which Root Causes are valid for each Resolution, and most importantly, letting your USERS see which Root Causes are acceptable for each Resolution.

Using Validators makes this invisible.

Yes, you can add description text for the field laying out all the options. And yes, the error message for each validator can display what people did wrong.

But that is a lousy user experience.

So anyways, then I went on to show how you could implement a Cascading Select field that also sets Resolution.

I know Jira Server had Behaviours and Cloud does not, and there is a strong tendency to want to simply do things the way they worked. But Validators are a poor substitute for Behaviours. Cascading Select is a better option, from a USER's perspective.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-cloud

workflow

regex