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
