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