{ADD [AS role] [NOWAIT]: AREA = area_1, PROJECT = project_1, field_1 = value_1
                         [, field_2 = value_2] … … [, ATTACHMENT[.{selected}]]}

This will add a new item to the ExtraView database, based upon a set of name value pairs, where the fields are the data dictionary names of the fields, and the values are valid for the display type of the field. This action only works within the postupdate directive, as it is essential to perform the underlying update before you initiate actions that are dependent. As an example, the following will add a new record when a button named ADD_SERIAL_BUTTON is pressed:

if (ADD_SERIAL_BTN.{changed} && UNIT_SERIAL.{not null}) {
  { ADD: AREA=’Calibration’,
    PROJECT=’Unit’,
    UNIT_SERIAL,
    COMPONENT,
    SITE,
    FACILITY};
  } }

Note: You should always provide the parameters and values for the AREA and PROJECT fields with the ADD command. It is indeterminate as to which Business Area and Project into which the issue will be added without these.

The above example demonstrates the use of an implied assignment.  When a field name is used in the rule like this:

    UNIT_SERIAL,
​
it implies that the rule is executed as:

    UNIT_SERIAL = UNIT_SERIAL,

If the field that provides the values for the ADD operation is of type Log Area (e.g. the COMMENTS field), then only the last entry from the source issue is added to the new issue.

The as role optional syntax allows the action to be implemented by altering the user’s current role to the role, purely for the action. The role is the title of the role, not its name. This is useful when you need to add a record to a different Business Area or Project where the current user may not have sufficient permissions.

The optional NOWAIT keyword provides the facility to execute the ADD action as a background task, not waiting for the result of the action before returning control back to the user. This may be used if you have many ADD actions to perform, and you do not want the user to wait for these to complete before they may carry on working in the user interface. This keyword should be used with caution, as there are no indications to the user if there is a failure from the action. Any failures are reported in the application server log file. Also, note that if you place the action within an onchange directive, as opposed to within a preupdate or postupdate directive, then the values within the issue as they stand at that moment will be added to the new issue, as opposed to the final values when the user has submitted the issue for insertion or updating. The ADD_UPDATE task must be running for this option to work successfully.

The optional ATTACHMENT keyword allows all or selected attachments to be copied from the current issue to the new issue being created. If the ATTACHMENT keyword is further qualified with {selected}, then only attachments that the user has individually selected with the Select? checkbox will be copied. The Select? checkbox is enabled on the user interface with the security permission keys named PR_ADD_PROBLEM.ATTACH_SELECT and PR_RESOLUTION.ATTACH_SELECT.

The ADD action is not supported in these directives: load, clone, mail