Product Documentation

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.

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.

Assignments within Search Layouts

There is a special form for assignment that is used within layouts of type SEARCH.  Consider a SEARCH layout that is embedded within an ADD_PROBLEM or EDIT_PROBLEM layout, or a Screen usage layout embedded within one of these.  This is the only occasion on which fields of the same name may reside within the same overall layout structure.

It can be useful to populate a field or fields within the SEARCH layout with the value of a field in one of the Screen usage layouts.  To differentiate the field within the SEARCH layout, from a field in the other layouts, where the same field name may be in use, within an ONCHANGE directive use the form:

SEARCH_LAYOUT_NAME.FIELD_NAME = FIELD_NAME2;

When the FIELD_NAME2 embedded within one of the Screen layouts is set to a value, or its value is changed, the value of the field FIELD_NAME within the SEARCH_LAYOUT_NAME is set to the value of FIELD_NAME2.

"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:

whereas the following will not work:

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.