Policy items in the ClearQuest page

• For submitting records from a ClearCase client
• For WorkOn
• For delivery
• For changing activity

For submitting records from a ClearCase client

Disallow Submitting of Records from ClearCase

Set this policy to prevent developers from creating a new activity record. In the developer user interfaces, the New button in the checkout, checkin, and add to source control windows is disabled. The Allowed record types policy is unavailable. The purpose is to restrict creation of activity records to users, for example, project managers, who have specific permission within the Rational ClearQuest schema.

If you clear this check box, developers can create a new activity and, therefore, a new record in the Rational ClearQuest user database. Allowed record types is made available so that you can specify record types for activities.

Allowed record types

If the Disallow Submitting of Records from ClearCase check box is clear, this area is enabled. Select the entry for the record type to determine which record types can be used when a developer creates an activity. Click Select All to set all available record types. Click Deselect All to clear all record types. Select at least one record type.

By default, the record types that are enabled by the UCM package except UCMUtilityActivity are allowed.

For WorkOn

The following policy applies when the developer clicks WorkOn in the Rational ClearQuest record.

Perform ClearQuest Action Before Work On

This policy is invoked when a developer attempts to work on an activity. The default policy script checks whether the developer's user name matches the name in the Rational ClearQuest record 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.

For delivery

The following policies apply when developers deliver their work in this project.

Perform ClearQuest Action Before Delivery

This default policy script is a placeholder: it does nothing. This policy is invoked when a developer attempts to deliver an activity in a UCM-enabled project. Your Rational ClearQuest administrator should edit the script to implement an approval process to control deliver operations. For example, she may want to add an Approved field to the activity record type and require that the project manager set it before allowing developers to deliver activities.

For information about policy invocation for interproject deliveries from this project to another project that is enabled for Rational ClearQuest, see Policies and interproject deliveries

Transfer ClearQuest Mastership Before Delivery

The Transition to Complete 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 Transfer Mastership Before Delivery policy.

The behavior of the Transfer 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 the operation is left in a posted state. The project integrator at the remote site completes the deliver operation.

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

• If all activities in the deliver operation are mastered by the remote replica, the deliver operation is allowed to proceed.
• If the deliver operation contains activities that are mastered by the local replica, mastership of those activities is transferred to the remote replica. To have mastership of those activities transfer back to the local replica after the integrator at the remote site performs any required merges and completes the deliver operation, set the Transfer ClearQuest Mastership After Delivery policy also.
• If the deliver operation contains activities that are mastered by a third replica, the deliver operation fails.

This policy is not customizable.

For information about policy invocation for interproject deliveries from this project to another project that is enabled for Rational ClearQuest, see Policies and interproject deliveries

Perform ClearQuest Action After Delivery

This policy is called at the end of a deliver operation for each activity included in the deliver operation. The default policy script is a placeholder; it does nothing. You may want to edit this script to implement a post-delivery development practice. For example, you might want the script to send an e-mail message to all developers on the project telling them that a deliver operation has just finished.

For information about policy invocation for interproject deliveries from this project to another project that is enabled for Rational ClearQuest, see Policies and interproject deliveries

Transition to Complete After Delivery

This policy is called at the end of a deliver operation for each activity included in the deliver operation. The policy uses the activity default action to transition the activity to a Complete type state and unset the activity from its view. These actions prevent the checkouts of versions in the change set from subsequently being associated with the activity.

If the default action requires entries in certain fields of the activity record, and one of those fields is empty, the policy 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 record and resume the deliver operation. If the developer started the deliver operation from a graphic user interface (GUI), the Rational ClearQuest record form is displayed so that the developer can fill in the required fields.

This policy is not customizable.

For information about policy invocation for interproject deliveries from this project to another project that is enabled for Rational ClearQuest, see Policies and interproject deliveries

Transfer ClearQuest Mastership After Delivery

Use this policy only in conjunction with the Transfer ClearQuest Mastership Before Delivery policy. The Transfer ClearQuest Mastership Before Delivery policy transfers mastership of activities involved in a remote deliver operation from the local replica to a remote replica. Set this policy if you want mastership of those activities to transfer back to the original (local) replica after the project integrator at the remote site completes the deliver operation.

This policy is not customizable.

For information about policy invocation for interproject deliveries from this project to another project that is enabled for Rational ClearQuest, see Policies and interproject deliveries

For changing activity

The following policies apply when developers work on their activities.

Perform ClearQuest Action Before Changing Activity

This default policy script is a placeholder: it does nothing. This policy is invoked when a developer attempts to finish an activity. The finish activity operation checks in all files that belong to the change set of the activity and performs Rational ClearQuest actions. For example, it transitions the activity to a Complete state, based on policies that are set. When the finish activity operation is invoked in a single-stream project or on the integration stream of a multiple-stream project, it is similar to a deliver operation in a multiple-stream project. Both operations share changes with the rest of the team.

You can edit the script to implement an approval process to control finish activity operations. For example, you may want to add an Approved check box to the activity record type and require that the project manager select it before allowing developers to finish activities.

Perform ClearQuest Action After Changing Activity

This policy is called when a developer attempts to finish an activity. If the Perform ClearQuest Action Before Changing Activity is set, that policy is called first. The default policy script behaves as follows:

• For developers working in a single-stream project or on the integration stream of a multiple-stream project, allow the finish activity operation.
• For developers working on a development stream, check in all files that belong to the change set of the activity, but do not perform any Rational ClearQuest actions.

You may want the Rational ClearQuest administrator to edit this script to implement a post-finish activity development practice. For example, you might want the script to send an e-mail message to all developers on the project telling them that a developer has just checked in files and finished an activity.

Transition to Complete After Changing Activity

This policy is called at the end of a finish activity operation. The policy uses the activity default action to transition the activity to a Complete type state. If the default action requires entries in certain fields of the activity record, and one of those fields is empty, the policy returns an error. To recover from an error, the developer needs to fill in the required fields in the activity record.

You may want to transition activities to a Complete type state depending on whether the developer works in an integration stream.

• To transition activities only for developers who work in a single-stream project or on the integration stream of a multiple-stream project, set this policy and the Perform ClearQuest Action After Changing Activity policy.
• To transition activities regardless of which stream the developer works on, set this policy and clear the Perform ClearQuest Action After Changing Activity policy.

This policy is not customizable.

Policies and interproject deliveries

These policies are invoked for the project of the source stream only if the following conditions are true:

• The source and target streams are integration streams.
• The target stream is the default deliver target for the source stream.