Value Identifiers are one of the following:
-
A Data Dictionary Name, e.g. DESCRIPTION or DATE_CREATED
-
A Data Dictionary Name, qualified with a Layout Name, e.g. ADD_PROBLEM.DESCRIPTION
-
A User ID, e.g. BILL.SMITH
-
A User Role, e.g. ADMIN or QA
-
A Special Value as defined on this page.
These must be upper case, and must match the internal name of the respective value. Value Identifiers are interpreted first as a Data Dictionary Name, then User ID, and then User Role unless an IDENT: is specified. Rule values are expressions of the form:
-
'Value' – Values can be quoted or left unquoted if their interpretation is unambiguous – i.e. there are no embedded spaces, etc. If this is a lookup field (typically this is a field with a display type of LIST, TAB, or POPUP) this will be treated as the Display title and verified against the database
-
Special values are what their name implies: a placeholder for a value the system will provide. These are values, such as USER or SYSDATE. See this page for a full list of special values
-
DD_NAME – A Data Dictionary name may be used to reference the value associated with that data element, such as ASSIGNED_TO. Data Dictionary names may be used on either side of the operator. Data dictionary names should always be expressed in uppercase.
-
(link name).DD_NAME – A link name may be specified before a DD_NAME to reference the value contained in a related issue. The link name must be specified in a Link Directive
-
Qualifiers - Complex identifiers consist of an optional link expression, a DD_NAME followed by one or more qualifiers. Qualifiers are properties, such as {is external}, or conditions, such as {changed}. They may also be complex conditions, as {changed_from:'value'}, where 'value' is interpreted as a simple value. See this page for a list of qualifiers
-
IDENT:’Value’ – This is a special form, used to force evaluation of an identifier as a specific type. For example, this can be used to force evaluation of a value as a User ID if there happens to be a Data Dictionary entry with the same value. Use one of the following forms:
-
EMAIL to specify an email address
-
USER to specify a User ID
-
ROLE to specify a User Role
Comparison of Field Values
The internal and external representations of fields vary across their display type. When fields within rule expressions are compared (using relational operators such as "<", ">", "!=", or "="), the field values are coerced into objects that are appropriate or capable of comparison. The coercions used in rules are defined in the following:
-
LIST – LIST : display titles in the default locale are compared as strings. Includes aliased lists
-
LIST – TEXTFIELD: display title of list value in default locale is compared to the TEXTFIELD
-
LIST – DATE: the display title of the list value is parsed as a date and compared to DATE field as Calendar object
-
LIST – DAY: same as LIST – DATE
-
LIST – NUMBER: the display title of the list value is parsed as a double (floating point) and compared to the NUMBER field as a Double object
-
LIST – DECIMAL: the display title of the list value is parsed as a decimal and compared to DECIMAL field as a BigDecimal object
-
LIST – CURRENCY: the display title of the list value is parsed as a currency and compared to CURRENCY field as a BigDecimal object
-
LIST – USER: the display title of the list value is compared to the display name of the USER field as Strings
-
TEXTFIELD – TEXTFIELD: the text field values are compared as Strings
-
TEXTFIELD – DATE: the text field value is parsed as a date and compared to the DATE field as a Calendar object
-
TEXTFIELD – DAY: same as TEXTFIELD – DATE
-
TEXTFIELD – NUMBER: the text field value is parsed as a double and compared to the NUMBER field as a Double object
-
TEXTFIELD – DECIMAL: the text field value is parsed as a decimal and compared to the DECIMAL field as a BigDecimal object
-
TEXTFIELD – CURRENCY: the text field value is parsed as a currency and compared to the CURRENCY field as a BigDecimal object
-
TEXTFIELD – USER: the text field value is compared to the display name of the USER field as Strings
-
DATE – DATE: the DATE fields are compared as Calendar objects
-
DATE – DAY: same as DATE – DATE
-
DATE – NUMBER: unequal
-
DATE – DECIMAL: unequal
-
DATE – CURRENCY: unequal
-
DATE – USER: unequal
-
DAY – DAY: same as DATE – DATE
-
DAY – NUMBER: unequal
-
DAY – DECIMAL: unequal
-
DAY – CURRENCY: unequal
-
DAY – USER: unequal
-
NUMBER – NUMBER: compared as double (floating point) numbers
-
NUMBER – DECIMAL: the DECIMAL field value is converted to BigDecimal, and then Double, then the fields are compared as double (floating point) numbers
-
NUMBER – CURRENCY: same as NUMBER-DECIMAL
-
NUMBER – USER: unequal
-
DECIMAL – DECIMAL: the DECIMAL field values are compared as BigDecimal objects
-
DECIMAL – CURRENCY: same as DECIMAL-DECIMAL
-
DECIMAL – USER: unequal
-
CURRENCY – CURRENCY: same as DECIMAL-DECIMAL
-
CURRENCY – USER: unequal
-
USER – USER: the user display names are compared