Hello, I am having trouble locating good / more examples or instructions how to use a valid regular expressions in that type of transition validator. I see this stuff: * [0-9]{4}-[0-9]{4} would allow numbers such as: 1245-7783 * [0-9]+ EUR$ would allow price tags such as: 34 EUR * [a-z]* would allow an empty string, or any lower case word such as: yellow * Option [A,B] would allow a selection of options: Option A, Option B or both. What I am really after is to check a required text field to ensure its just not full of spaces or 'whitespace' in the custom field. Want to ensure the people are not just skipping the required field by typing a few spaces and moving past. I know, I wish people would just fill it in. An expression I tested in a utility I found seems to be /^\s*$/ but not sure how to use it in Jira field or if that is possible.

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; } } }

Better instructions or examples of regular expressions for regular expression check validator

Jason_Brastad

Hello, I am having trouble locating good / more examples or instructions how to use a valid regular expressions in that type of transition validator.

I see this stuff:

[0-9]{4}-[0-9]{4} would allow numbers such as: 1245-7783
[0-9]+ EUR$ would allow price tags such as: 34 EUR
[a-z]* would allow an empty string, or any lower case word such as: yellow
Option [A,B] would allow a selection of options: Option A, Option B or both.

What I am really after is to check a required text field to ensure its just not full of spaces or 'whitespace' in the custom field. Want to ensure the people are not just skipping the required field by typing a few spaces and moving past. I know, I wish people would just fill it in.

An expression I tested in a utility I found seems to be /^\s*$/ but not sure how to use it in Jira field or if that is possible.

Accepted answers

Randy_dyxb6i

You can try to enforce it programmatically with a validator but if folks are already trying to bypass it by adding spaces, how do you know they wont just switch to a single . or other character/word to bypass?

Alternately, you can audit what folks are filling in and get to the root cause on why they aren't entering values into the field.

Questions to ask yourself:

Are they able to get the work done without the information filled? What would that say about the value that field provides?

Are they unaware of the impacts downstream in the workflow of not supplying the information?

Do they even know what the expectations are for what should be entered?

All comments

Randy_dyxb6i

Alternately, you can audit what folks are filling in and get to the root cause on why they aren't entering values into the field.

Questions to ask yourself:

Are they able to get the work done without the information filled? What would that say about the value that field provides?

Are they unaware of the impacts downstream in the workflow of not supplying the information?

Do they even know what the expectations are for what should be entered?

Jason_Brastad

Ya, I get what your saying trust me on that, what your saying is true. If this check was fast to put in I was going to do it just for this scenario and move on as that is whats happening now to skirt it. Expectations are known for the field, and I don't have time to police people, this is just an extra 'message' being sent to fill in the field. I can't check all cases, get that.

Randy_dyxb6i

To answer your question directly, /^\s*$/ that you posted above would be the correct expression. Just put it in the expression field for the validator.

With that said, i generally avoid validators due to the poor UX involved. Users wont get much info from Jira on why they can't perform a transition.

Jason_Brastad

Ya, interface isn't very good on the error message you can't control it.

The above does not work I see unless I am doing something wrong. I tried a few cases, it fails to move through the workflow if there is a character present.

I used ' d' in the field and result is: 'Field RCA with actual value ' d' does not match regular expression /^\s*$/'

I used 'test asdf' and the result is: 'Field RCA with actual value 'test asdf' does not match regular expression /^\s*$/'

These above should pass, what should fail is only spaces in the field.

Mykenna Cepek

First, it's important to realize that the RegExp type of validator for a workflow transition specifies the acceptance, not rejection, criteria. The field content must match the regexp in order to execute the transition.

So your proposed example would force the field to always include only whitespace characters. That's not what you want.

Note also that you should omit the leading and trailing slash characters in a regexp when entering in for a workflow validator. That "slash quoting" syntax is for some languages (such as Groovy) but Jira validators don't use that.

Something simple to try instead is to set a minimum number of characters for this field. Here is a regular expression for requiring 15 characters or more:

.{15,}

Of course 15 space characters will pass.

Another downside to using a regexp for a workflow validator is that you can't customize the error message. So when the above fails, for example, the user will get a message like:

Transition failed
Field Description with actual value 'too short' does not match regular expression .{15,}

Not very user friendly, and your smarter users will figure out the minimum number of characters fairly quickly.

Atlassian itself seems to use a "minimum number of characters or words" validator -- I've seen them bypass it by using phrases like "Adding this to pass validation".

Speaking of words, you could experiment with something like this regexp

.*?(\S+\s+){3,}.*?

which forces at least three words and word separators, with an optional amount of stuff before or after.

However, even with this in place, a user can enter

x x x x

and pass this validation, but the following

All tests pass

will fail (no word separator after the third word). In my opinion, this approach is a losing battle with your users.

A different approach to consider is making the values that people enter for this field more visible to everyone. A dashboard, filter, or Confluence page with a "Jira issue/filter" macro would make it easy for everyone to see actual values which have been entered lately. You could use this at a Team Retrospective for further discussion with the team.

If you have multiple teams, you could even gamify the proper usage of the field. Rank the teams each week on their overall (proper) use of the field and publicize the results. Get the company to spring for a pizza lunch for the winning team after a month. Just an idea.

Jason_Brastad

yep I am going to just opt for doing nothing.. thanks for the advice anyway.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

atl-gruland