|
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.
|
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.
|
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.
For more information, see Automatic Revision During Promotion.
|
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.
|
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.
For more information, see Configuring the Initial Collection of Objects for Actions.
|
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.
|
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:
|
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 |
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: |
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.
|