Promotion Process Preferences
There are several preferences available in the Preference Management utility that affection promotion request behavior.
For information on using the
Promotion Preference Management utility, see
Promotion Preference Management Utility.
The visibility of preferences is determined by how you access the Preference Management utility:
• Some preferences are set at the user level.
To view and modify your individual user preferences, select
Quick Links > > > .
• Some preferences are set at the context, organization, or site level by an administrator.
From the
Navigator, select
Utilities under a specific context, organization, or site. Click
Preference Management under the
Business Administration utility category.
If a preference is visible but cannot be edited, then this preference has been locked at a higher level.
To change a preference, select
Set Preference from the right-click actions menu of the preference you want to change. For more information, see
Preference Management and
Setting a Preference.
|
|
In the tables below, “Visibility” indicates the lowest level at which the preference can be set. For example, “Site” means that only site administrators can view or set the preference. “Context” means the preference can be set for a site, organization, product, library, project, or program. “User” means that an individual user, context administrator, organization administrator, and site administrator can view or set the preference. However, your local administrators might change the default preference visibility.
|
The following preferences are available under the Promotion Process preference group:
Access Check for Promote
|
Visibility
|
Context
|
|
Default
|
Yes
|
|
Description
|
Check access before allowing a user to create a promotion request:
• Yes—Windchill checks to ensure that you have Modify or Set State access permission for the objects that you are trying to promote. If you do not have either permission, the object cannot be promoted.
• No—Windchill does not perform an access permission check. You can create a promotion request even if you do not have Modify or Set State permission on promotion objects.
|
Automatic Revision Mode
|
Visibility
|
Context
|
|
Default
|
Do nothing
|
|
Description
|
Allow automatic revisions when an object is promoted.
• Do nothing—No automatic revisions can occur.
• Automatically revise all the promotion candidates—All promotion candidates are automatically revised when the promotion process completes.
• Automatically revise only the promotion candidates with versioning scheme changed—Administrators can create an enhanced promotion process so that promoted objects undergo a versioning scheme change.
|
Automatic Revision States
|
Visibility
|
Context
|
|
Description
|
This preference only applies if the Automatic Revision Mode is set to allow automatic revisions.
Perform automatic revision of promotion candidates based on a selected life cycle state. You can select one ore more states.
The automatic revision occurs after the promotion request is approved. The preference values are evaluated in the context of the promoted objects.
|
Collector
|
Visibility
|
User
|
|
Description
|
These are a set of preferences that determine the default collection rules. You can automatically apply these rules when you select the Apply default collection checkbox in the New Promotion Request window.
|
Default for the Apply Default Collection Checkbox for Promotion Requests
|
Visibility
|
User
|
|
Default
|
No
|
|
Description
|
This preference determines whether the Apply default collection option is selected by default when creating a new promotion request.
The option determines whether the Collector preferences are automatically applied to the initially selected objects.
|
Default Promotion Processes
|
Visibility
|
Context
|
|
Default
|
Promotion Request Approval Process
Promotion Request Review Process
|
|
Description
|
This preference defines the following:
• The workflow processes that appear under the Select Participants step when creating a new promotion preference.
• The workflow process that is selected by default.
To set this preference, complete the following steps:
1. Select one or more processes under Available Processes. Press the Ctrl key to select multiple processes.
Your selections appear under the Select Participants step.
2. The Default Process menu updates to reflect your selections. Choose the process that should be selected by default.
For example, the following preference setting: Results in the following changes: |
Fixed Roles For Promote
|
Visibility
|
Context
|
|
Default
|
APPROVER=PROMOTION APPROVERS|REVIEWER=PROMOTION REVIEWERS
|
|
Description
|
This preference maps required team roles assigned a workflow process role.
For example, by default, the Approver role is assigned to users in the Promotion Approvers team role. Users can assign additional participants, but cannot deselect the checkbox next to Promotion Approvers: The preference value must be formatted using the following pattern: [key]=[values]|[key]=[values] Each value in [values] must be separated by a tilde "~" character. Both the keys and values are role constants defined in the following file: wt/project/RoleRB.rbInfo |
Group Members Display
|
Visibility
|
Context
|
|
Default
|
No
|
|
Description
|
If a Windchill group is assigned to a team role, this preference allows users to select individual members within the group. If multiple groups are assigned to a role, you can select individual groups to include.
For example, your organization creates a group named “Promotion Request Review Group” and assigns the group to the Promotion Reviewers team role.
When the preference is set to No, selecting a team role also automatically selects every subgroup and group member: If you set this preference to Yes, you can select individual groups or group members: |
Latest Iteration Refresh
|
Visibility
|
Context
|
|
Default
|
Refresh promotion candidates
|
|
Description
|
This preference determines which promotion objects to update if the promotion request is modified. Objects are updated to the latest iteration of their current revision.
For example, you create a promotion request and include an object with version A.4. Several users continue to work on the object to eventually create version A.8. Then, another user revises the A.8 version to create a B.1 version. When the refresh occurs, the object is updated to A.8.
• Do nothing—Do not refresh any promotion objects.
• Refresh promotion candidates—Only refresh objects marked for promotion.
• Refresh all objects—Refresh all promotion objects.
|
|
If you create a promotion request with a reference baseline, configurable parts within the baseline are not refreshed.
|
|
