{UPDATE [AS role] [NOWAIT]: linkName field_1 = value_1 [, field_2 = value_2]
... ... [, ATTACHMENT[.{selected}]]}
This will update one or more records, based upon the definition of the link specification. If the link points to more than one record, all affected records will be updated. 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 update all customer contact records, if the contact is changed:
<== link custCSRInfo ==> AREA='CSR Calls', CUST_LIST
if (AREA = 'Customers' && CUST_CONTACT_PHONE.{changed}) {
{UPDATE: custCSRInfo CUST_CONTACT, CUST_CONTACT_PHONE}
}
If the field that provides the values for the UPDATE 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.
In the same way as with the ADD action, you may make implied assignments.
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 update a record in a different Business Area or Project where the current user may not have sufficient permissions. 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 key named PR_ADD_PROBLEM.ATTACH_SELECT and PR_RESOLUTION.ATTACH_SELECT.
The optional NOWAIT keyword provides the facility to execute the UPDATE 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 UPDATE 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 update to the 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.
There is a 5,000 issue limit to the number of linked issues which will be updated with this action.
The UPDATE action is not supported in these directives: load, clone, mail
