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

Jason_Brastad April 20, 2020

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.

2 answers

1 accepted

0 votes
Answer accepted
Randy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 20, 2020

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?

Jason_Brastad April 20, 2020

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 20, 2020

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 April 20, 2020

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.

Randy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 20, 2020

it might not like the literal expression.  try:

^\\s*$

Jason_Brastad April 20, 2020

I tried yours and got: Field RCA with actual value 'test asdf' does not match regular expression ^\\s*$

I tried this ^\s*$ and got: Field RCA with actual value 'test asdf' does not match regular expression ^\s*$

Randy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 20, 2020

Oops.  that's because we're setting an expression to only allow values of whitespace.  We need to do the inverse which would be:

^([^\\s]*)$

or 

/^([^\s]*)$/

Jason_Brastad April 20, 2020

when I tried that, it failed, it actually does the opposite, it allows the field filled with spaces to transition, and stops the field that has legitimate text.  So to my earlier point, this has taken to long, I actually am going to just tell them to fill in the field and just making the field required is all you can do to try to get info in it.

Good point earlier.

Like Randy likes this
Christoph Päper February 21, 2024
^\S.+\S$

This requires at least two characters and allows neither leading nor trailing whitespace.

2 votes
Mykenna Cepek
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 20, 2020

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 April 20, 2020

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

Suggest an answer

Log in or Sign up to answer