ksc_copy_request

This special command makes a copy of a specified request automatically, with no user intervention. As distinct from the "create request" workflow command which raises the standard request form in the user interface for the user to manually fill in and submit.

In addition, when the ksc_copy_request special command is run, the resulting ID of the new request must be made available so that it can be captured and used in subsequent commands. This is similar to the ksc_set command, in which you can specify a "temporary token" and assign a value to it. In this case, a temporary token named "[COPIED_REQUEST_ID]" holds the ID of the new request, and is available within the same run context. If it is necessary to persist this new request ID on the existing request driving the commands, then it should be stored to a request field using the ksc_store special command.

Table 3-2. ksc_copy_request parameters

Parameter

Description

FROM_REQUEST_ID

The ID of the request from which to make the copy. This is a required parameter, and should default to the token for the ID of the current request ("[REQ.REQUEST_ID]").

REQUEST_TYPE_ID

The ID of the request type to use when creating the new request. This is an optional parameter, and should be specified only if it is desired that the new request be of a request type different than that of the request being copied (specified by the FROM_REQUEST_ID parameter). If this parameter is left blank, then the new request created by this special command will be of the same request type as the one specified by the FROM_REQUEST_ID parameter.

WORKFLOW_ID

The ID of the workflow to use when creating the new request. This is an optional parameter, and should be NULL by default.

COPY_FIELDS

Valid values are "Y" or "N." If "Y" then copy the values of every field whose token maps to a token in the new request. Default value is "Y."

NOTE: Resources are not copied from the original request because, in most cases, the new request will be worked on by different resources.

COPY_NOTES

Valid values are "Y" or "N." If "Y" then copy all the notes from the original request to the new request. The default value is "N" since it is reasoned that the notes from the original request are typically not relevant for the new request, and thus will not be copied in most cases.

CREATE_REFERENCE

Valid values are "Y" or "N." If "Y" then create a reference between the new request and the original request. The default value is "Y."

REF_RELATIONSHIP_ID

Specifies the relationship of the reference, if CREATE_REFERENCE=Y, otherwise this parameter is ignored. Valid values are:

  • 12 (Duplicate Request)

  • 13 (Original of Duplicate Requests)

  • 14 (Parent of this Request)

  • 15 (Child of this Request, this is the default value)

  • 16 (Related to this Request)

  • 422 (Successor)

  • 423 (Predecessor)

SUBMIT

Valid values are "Y" or "N." If "Y," then submit the new request. The default value is "Y."

STATUS_NAME

The status name to set for the new request. The default value is NULL and typical configurations will want to use the initial status name specified by the new request's type configurations. Note that if a status name is provided, its value should be set after the request is submitted (if SUBMIT=Y).

PROCESS_RULE

Valid values are "Y" or "N." If "Y," then process rules for the "Apply on creation" rule event. If "N," then rules are not processed for the "Apply on creation" rule event. The default value is "Y."

USER_ID

Specifies creator user ID of the new request.

VALIDATION_NAME

Specifies a validation to store copied fields with different tokens.

The value of the destination token will be replaced by the value of the source token.

The source token, source visible token, token type, and destination token are stored in the user data of validation values. You can configure multiple validation values to store multiple pairs of source and target fields.

For information about configuring user data for validation values to store field token mappings between source and target requests, see Enabling User Data Tab for Validations.

Example using ksc_copy_request 

ksc_copy_request FROM_REQUEST_ID="[REQ.REQUEST_ID]"
USER_ID="[USER_ID]" VALIDATION_NAME="[VALIDATION_NAME]"