Purpose

Condition based on regular expression and Validation based on regular expression are two forms of a same feature for checking the value of a field or a text composed by various custom fields against a regular expression.

Example: How to validate US State codes entered in a custom field

In this example we show a configuration for validating the US state code entered in a custom field called "State":

Regular expression used is: ^((AL)|(AK)|(AS)|(AZ)|(AR)|(CA)|(CO)|(CT)|(DE)|(DC)|(FM)|(FL)|(GA)|(GU)|(HI)|(ID)|(IL)|(IN)|(IA)|(KS)|(KY)|(LA)|(ME)|(MH)|(MD)|(MA)|(MI)|(MN)|(MS)|(MO)|(MT)|(NE)|(NV)|(NH)|(NJ)|(NM)|(NY)|(NC)|(ND)|(MP)|(OH)|(OK)|(OR)|(PW)|(PA)|(PR)|(RI)|(SC)|(SD)|(TN)|(TX)|(UT)|(VT)|(VI)|(VA)|(WA)|(WV)|(WI)|(WY))$ 

Once configured, the validation will look like this: 

Configuration Parameters

We will explain in detail each of the configuration parameters of these features.

Field or parsed text to be checked for matching with the regular expression

These are two alternative parameters, i.e., only one of these parameters is used in each configuration at the same time.

• Field: Field whose value is going to be checked against the regular expression.
• Parsed text: Text composed by string literals and field codes. The text obtained once parsed, will be checked against the regular expression.

Field codes have the following formats:

• %{nnnnn}: for any field type. This field code will be replaced with the value of the field in current issue. Cascading Select List will be replaced with parent_value - child_value. Example: %{00001} is field code for issue Description.
• %{nnnnn.i}: for Cascading Select Lists fields. Index i can take value 0 for parent (or root) value, and 1 for child value. Example: %{10100.0} is field code for parent value of a cascading select field with field ID 10100.

Multi-Level Cascading Select custom fields are also supported. For these fields values higher 1 can be used for index i.

Field codes can be checked up in a dropdown list available in the configuration screen of these features.

Regular expression

This is the regular expression that will be used for validating the value of the selected field or parsed text entered.

JAVA regular expression syntax is used.

Field codes with formats %{nnnnn} and %{nnnnn.i} can be inserted. Regular expression will be preprocessed before being evaluated, in order to replace each field code with its corresponding value. This way, dynamic regular expressions that depend on the value of fields in current issue, can be entered.

Regular expression parsing modes

The way regular expressions are evaluated can be modulated with the following modes:

• Case Insensitive: Case-insensitive matching is done in a manner consistent with the Unicode Standard.
• Multiline: Expressions ^ and $ match just after or just before, respectively, a line terminator or the end of the input sequence. By default these expressions only match at the beginning and the end of the entire input sequence.
• Dot All: Expression . matches any character, including a line terminator. By default this expression does not match line terminators.
• Literal: Input string is treated as a sequence of literal characters. Metacharacters or escape sequences in the input sequence will be given no special meaning. Case-insensitive mode retains its impact on matching when used in conjunction with this mode.

Negate condition

When this option is checked, not matching the regular expression is the requirement set for field value or parsed text, instead of matching it.

Message to show when validation fails

This parameter is only available in the validator form of this feature. It's a custom message to explain the user the cause that is preventing him from executing the transition. 
Translations* to every language installed in the JIRA instance can be optionally entered. 
In Condition based on regular expression the transition is simply hidden whenever condition isn't satisfied, so this parameter is not present.