4.4 UCM-ClearQuest Integration

This section describes the policies that are available only when you enable the project to work with ClearQuest. ClearQuest uses scripts to implement these policies. You can modify a policy's behavior by editing its script. See Customizing ClearQuest Project Policies.

Check Before Work On

ClearQuest invokes this policy when a developer attempts to work on an activity. The default policy script checks to see whether the developer's user name matches the name in the ClearQuest record's Owner field. If the names match, the developer can work on the activity. If the names do not match, the Work On action fails.

The intent of this policy is to ensure that all criteria are met before a developer can start working on an activity. You may want to modify the policy to check for additional criteria.

Check Before ClearCase Delivery

This default policy script is a placeholder: it does nothing. ClearCase invokes this policy when a developer attempts to deliver an activity in a UCM-enabled project. We recommend that you edit the script to implement an approval process to control deliver operations. For example, you may want to add an Approved check box to the activity's record type and require that the project manager select it before allowing developers to deliver activities.

Do ClearQuest Action After Delivery

ClearCase calls this policy at the end of a deliver operation for each activity included in the deliver operation. The default policy script uses the activity's default action to transition the activity to a Complete type state. If the default action requires entries in certain fields of the activity's record, and one of those fields is empty, the script returns an error and leaves the deliver operation in an uncompleted state. This state prevents the developer from performing another deliver operation, but it does not affect the current one. It does not roll back changes made during the merging of versions.

To recover from an error, the developer needs to fill in the required fields in the activity's record and resume the deliver operation.

The integration runs this script for each activity in the deliver operation. The script may return success for any number of activities before returning an error on an activity. For the successful activities, the script may change their state when it invokes the default action. When you recover from an error and rerun the deliver operation, the script looks at all activities again. For those that succeeded previously, the script does not attempt to change state. If you modify the script, be sure that it adheres to this behavior. ClearQuest returns an error if you attempt to change the state of a record to its current state.

Check Mastership Before Delivery

The Do ClearQuest Action After Delivery project policy transitions activities to a Complete type state when a deliver operation completes successfully. For that policy to work correctly in a MultiSite environment, the activities being delivered must be mastered by the same replica that masters the target stream. To ensure that this is the case, you can set the Check Mastership Before Delivery policy.

The behavior of the Check Mastership Before Delivery policy depends on whether the deliver operation is local or remote. If the deliver operation is local, meaning that the target stream is mastered by the local PVOB replica, this policy causes the deliver operation to fail unless all activities being delivered are mastered locally.

A remote deliver operation is one for which the target stream is mastered by a remote PVOB replica. The developer starts the deliver operation, but ClearCase leaves the operation in a posted state. The integrator at the remote site completes the deliver operation.

For a remote deliver operation, the Check Mastership Before Delivery policy causes the following behavior:

• If all activities in the deliver operation are mastered by the remote replica, ClearCase allows the deliver operation to proceed.

• If the deliver operation contains activities that are mastered by the local replica, MultiSite transfers mastership of those activities to the remote replica. After the integrator at the remote site performs any required merges and completes the deliver operation, MultiSite transfers mastership of the activities back to the local replica.

• If the deliver operation contains activities that are mastered by a third replica, the deliver operation fails.