Policy items in the ClearQuest page
For submitting records from a ClearCase client
These policies affect the configuration of the UCM project. They are not visible from Rational ClearQuest forms because they do not have corresponding Rational ClearQuest hooks.- 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
With one exception, the integration does not invoke the following policies when you deliver from one project that is enabled for Rational ClearQuest to another project that is enabled for Rational ClearQuest.- Perform ClearQuest Action Before Delivery
- Perform ClearQuest Action After Delivery
- Transition to Complete After Delivery
- Transfer ClearQuest Mastership Before Delivery
- Transfer ClearQuest Mastership After Delivery
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.