Writing Rules

General Syntax

Rules consist of an action and an optional condition. If a Condition is omitted, the action will always occur; otherwise the action will be taken if all the conditions are true.

Rules will have one of the following syntaxes:

  • <Rule Action>
  • if (<Rule Condition >) <Rule Action> ; <Rule Action>
  • if (<Rule Condition > && <Rule Condition> ...) {
       <Rule Action> ; <Rule Action>;
       <Rule Action> ; <Rule Action>;
       <Rule Action> ; <Rule Action>;
       <Rule Action> ; <Rule Action>;
    }

There is also a special syntax for negative conditions:

if !(<Rule Condition >)

Rules also support the following conditional operators. These conditional operators will work with all numeric and date display field types. They also work as operators using a string compare operator when used with text and list display types.

Operator Meaning
> Greater than
< Less than
<= Less than or equal to
>= Greater than or equal to

Note: The condition(s) may extend over multiple lines, and are controlled by the parentheses.

Note: You may not set the value of the fields AREA and PROJECT with a load, refresh or clone directive. Within the rules, all referenced fields must exist in the data dictionary, and must appear on the layout to which the rule applies. You cannot define variables or new fields "on-the-fly".

Assignment

By definition, all fields have a type, specified by its display type in the data dictionary. As with all other computer languages, assignments must be made between fields with the result being of the correct type. For example, you can assign a text field to another text field, but cannot assign a text field to a number field. However, you might assign the a value in a list field to a text field, as the individual values within the list field are of type text.

For the most part, automatic conversions are made between different data types. For example, if you assign a list type field to a text field, the display title of the list value is automatically provided and used. Similarly, if you assign a text field to a list value, then a reverse lookup is performed on the text value to populate the list field. Of course, if you make an assignment of this last type, then the value in the text field must correspond to an existing value of a list title else an error will be generated.

An important feature of rules within ExtraView is that you can only perform a single operation with a single rule. For example, to add two fields together (FLD_1 and FLD_2) and place the result in a third field (FLD_TOTAL) you must take two steps:

FLD_TOTAL = FLD_1;
FLD_TOTAL += FLD_2;

You cannot and must not use the form:

FLD_TOTAL = FLD_1 + FLD_2;

When applied to a repeating row field, the above syntax updates the field value on all repeating row fields. The following syntax demonstrates how you make an assignment to a repeating row field on a single row. Note that the repeating rows are numbered from zero, not from one.

RR_FIELD[0] = 'value1';
RR_FIELD[1] = 'value2';

"IF" statements

IF statements allow the conditional processing of statements. For example, consider the following rule:

if (PROJECT = 'Customer Tickets') {
  ASSIGNED_TO = 'BSMITH';
}

This will work equally well as a load rule, an onchange rule or a preupdate rule. It will not work as a postupdate rule, as no update will be made once the rule has been read and executed. Next, consider this rule:

if (PROJECT.{changed to:'Customer Tickets'}) {
  ASSIGNED_TO = 'BSMITH';

}

This will only work as an onchange or a preupdate rule, as it is during these times that changes can be detected.

Nested if statements, else / else if, (), and or clauses are not supported at this time. However, you may write statements in a way that achieves your purpose. For example, a statement such as:

if (AREA = 'Customer Support') {
  if (STATUS='Submitted') {
    SUB_STATUS = 'Needs Review'; 
    OWNER = ASSIGNED_TO;
    DUE_BY_DATE = SYSDAY;
  }
} else if (AREA = 'Bugs') {
  STATUS = 'New';
} else {
  STATUS = 'Unassigned';
}

IS NOT SUPPORTED It should, and must be, written as:

if (AREA='Customer Support' && STATUS='Submitted') {
  SUB_STATUS='Needs Review'; 
  OWNER=ASSIGNED_TO;
  DUE_BY_DATE = SYSDAY;
}
if (AREA = 'Bugs') {
  STATUS = 'New';
}
if (AREA != 'Customer Support' && STATUS != 'Submitted' && AREA !='Bugs') {
  STATUS = 'Unassigned';
}

Recognizing a User's Changes within the ONCHANGE Directive

You must always write a rule that recognizes the changes a user makes when they alter a field value.  This is achieved within the onchange directive, and you must consider and use one of three change events.

  • changed
  • changed from
  • changed to

You must have one, and only one, of these qualifiers in a statement. For example, the following rule will work:

if (CATEGORY.{changed to:"Software"} && PRIORITY = "P 1")   { IMPORTANCE = "High" }

whereas the following will not work:

if (CATEGORY.{changed to:"Software"} && PRIORITY.{changed})   { IMPORTANCE = "High" }

The reason is that a user implicitly changesonly one item on the user interface at one moment. The rule will never trigger the change if it looks for two or more changes at the same moment.