Change Management Preferences
Preference settings determine a variety of change object behavior.
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 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:
• “User” means that an individual user, context administrator, organization administrator, or site administrator can view or set the preference.
• “Context” means the preference can be set for a site, organization, product, library, project, or program.
• “Organization” means that organization and site administrators can view or set the preference.
• “Site” means that only site administrators can view or set the preference.
However, your local administrators might change the default preference visibility.
|
Change Management
The Change Management preference group determines the behavior for change objects.
Affected End Items Display
|
Visibility
|
Context
|
|
Default
|
Yes
|
|
Description
|
Determines the visibility of the Affected End Items table.
If set to Yes, the Select Affected End Items step appears when creating or editing problem reports, variances, and change requests: | If set to No, this preference is ignored for problem reports, variances, and change requests that already have existing affected end items, or for changes that exist in project contexts. |
|
Associated Issues Display
|
Visibility
|
Context
|
|
Default
|
No
|
|
Description
|
Determines the visibility of the Associated Issues and Variances table.
If set to Yes, the Associated Issues and Variances table appears when creating change tasks.
|
|
If set to No, this preference is ignored for change tasks that have existing associated issues or variances.
|
|
Automatic Change Notice Creation
|
Visibility
|
Organization
|
|
Default
|
Yes
|
|
Description
|
Automatically create a change notice from the task page of a change request.
|
|
• This preference only applies when Windchill is in Legacy change association mode.
|
|
CAD Model On Same Change Notice
|
Visibility
|
Context
|
|
Default
|
Yes
|
|
Description
|
This preference affects mass change operations when working with parts built from CAD documents.
When set to Yes, any parts built from CAD must have the correct associated CAD model on the corresponding change notice when performing mass change operations.
|
Change Baseline Report Display
|
Visibility
|
Organization
|
|
Default
|
No
|
|
Description
|
If set to Yes, the Change Baseline Report is included in the list of reports that is available from the product structure reports.
|
Change Implementation State Definition
|
Visibility
|
Context
|
|
Default
|
Implementation
|
|
Description
|
The life cycle state that determines when a change notice is in the implementation phase.
The value specified marks the change notice workflow under the implementing phase. The value also starts the change sequence plan; a change sequence plan is started only when the change notice is in the specified state. Only one life cycle state can be specified as the implementing state.
|
Change Information Propagation
|
Visibility
|
Context
|
|
Default
|
Yes
|
|
Description
|
The preference determines whether the Propagate information checkbox is available when creating a creating a change request, problem report, variance, or change notice from an existing change object. For example, when selecting > > from the information page of a change request: The information that is propagated includes attributes, affected objects, and attachments. • Yes—The checkbox appears, but is not selected by default. • Selected—The checkbox appears and is selected by default. • No—The checkbox does not appear. |
Change Modification Tracking
|
Visibility
|
Organization
|
|
Default
|
No
|
|
Description
|
This preference controls whether revisions are allowed for change objects. Revision information is available in the Revision History table for the change object.
The use of the feature requires proper process design. Life cycle templates must define revise transitions and users must be granted revise permission at the appropriate life cycle states. For more information, see Phase Transitions and Setting Permissions. |
Change Notice with Embedded Change Task
|
Visibility
|
Organization
|
|
Default
|
No
|
|
Description
|
When set to Yes, simplified change notices are enabled.
This means that if there is only one change task associated with the change notice, the Implementation Plan table is not displayed on the change notice information page.
Instead, the Implementation Plan tab displays information about the change task, the Affected Objects table, and the Resulting Objects table.
|
Change Notice without Change Request
|
Visibility
|
Context
|
|
Default
|
No
|
|
Description
|
Determines whether users can create a change notice without first creating a change request:
• Yes—Users can create change notices at any time.
• No—Users can only create a change notice from an existing change request.
|
|
• This preference only applies when Windchill is in Legacy change association mode.
|
|
Change Request to Change Notice Cardinality
|
Visibility
|
Organization
|
|
Default
|
No
|
|
Description
|
• Yes—Users can associate multiple change requests to multiple change notices.
• No—This is the equivalent to a “1:many or many:1” link. The association is limited depending on which association is created first. For example, you link a change request to a change notice. If you link a second change request to the change notice, then a 1:many cardinality is enforced. The change notice can be linked to multiple requests, but the change request can only be linked to a single change notice.
|
|
• This preference only applies when Windchill is in Legacy change association mode.
|
|
Change Request to Problem Report Cardinality
|
Visibility
|
Organization
|
|
Default
|
No
|
|
Description
|
• Yes—Users can associate multiple change requests to multiple problem reports.
• No—This is the equivalent to a “1:many or many:1” link. The association is limited depending on which association is created first. For example, you link a problem report to a change request. If you link a second change request to the problem report, then a 1:many cardinality is enforced. The problem report can be linked to multiple requests, but the change request can only be linked to a single problem report.
|
|
• This preference only applies when Windchill is in Legacy change association mode.
|
|
Collector
|
Visibility
|
User
|
|
Description
|
These are a set of preferences that determine the default collection rules.
You can set default rules when collecting objects for the following tables:
• Affected Objects
• Resulting Objects
|
Copy Superseded Parts to Resulting Data Table
|
Visibility
|
Organization
|
|
Default
|
No
|
|
Description
|
When parts are superseded, they can be set to an alternate state to show that they have been superseded.
• Yes—The superseded parts are copied to the Resulting Objects table so that their state can be changed when the change notice is released.
• No—The superseded parts are not copied to the Resulting Objects table and no changes are made to their state.
|
|
If you enable this preference, you must also configure the corresponding life cycle template with the appropriate transition configured to automatically or manually pick the target state.
|
|
Expose Organization for Change Management Objects
|
Visibility
|
Organization
|
|
Default
|
No
|
|
Description
|
Expose the organization for all change objects.
|
Inline Editing of Dispositions
|
Visibility
|
User
|
|
Default
|
Yes
|
|
Solution
|
Windchill Risk and Reliability
|
|
Description
|
• Yes—You can perform inline edits for disposition values.
• No—Inline editing is disabled. However, this improves performance if you are attempting to make mass changes.
|
Localized Create New Change Notice Task Name
|
Visibility
|
Organization
|
|
Default
|
Create New Change Notice
|
|
Description
|
Change the “Create New Change Notice” workflow task name that is generated in the change request workflow process.
When you provide a localized name as the value in this preference, you also update the label for the checkbox that appears allowing you to automatically create a change notice from the change request task page.
|
|
The name you provide must match the name of the corresponding workflow activity in the change request workflow.
|
|
|
• This preference only applies when Windchill is in Legacy change association mode.
|
|
Lock Annotations
|
Visibility
|
Organization
|
|
Default
|
Yes
|
|
Description
|
Set this preference to Yes to automatically lock annotations when a change object is manually moved to a terminal state. Annotations are not locked if the state changes through a workflow process or when imported.
When set to No, annotations associated to a change object are not locked.
|
Multiple Release Targets
|
Visibility
|
Context
|
|
Default
|
Yes
|
|
Description
|
Determine whether users can select the release target for resulting objects:
• Yes—The Release Target column of the Resulting Objects table displays a drop-down menu.
• No—The Release Target column displays either the default value as read-only or the persisted target.
|
Optional Assignee and Reviewer States
|
Visibility
|
Context
|
|
Default
|
<not set>
|
|
Description
|
You can use this preference to defer the assignment of the assignee and reviewer to a later life cycle state.
When you select a life cycle state, this means that the change task assignee and reviewer are optional for selected life cycle states.
By default, no states are selected. As a result, all life cycle states require assignee and reviewer assignments.
|
Prevalidation Compare Icon
|
Visibility
|
Site
|
|
Default
|
No
|
|
Description
|
This preference determines the type of validation that should be performed on objects in the Resulting Objects table of a change task. The validation determines the visibility and availability of the Compare action.
• Yes—Perform a full validation on objects in the Resulting Objects table. The Compare action is available for all objects. However, this can affect system performance when change tasks have a large number of resulting objects. • No—Perform a partial validation on objects in the Resulting Objects table. However, the Compare action icon  might appear for objects where the action is not applicable. |
Problem Reports in Projects
|
Visibility
|
Context
|
|
Default
|
No
|
|
Solution
|
Windchill ProjectLink
|
|
Description
|
• Yes—Users can create problem reports for objects shared to a project.
• No—Users cannot create problem reports for shared objects. However, existing problem reports remain visible.
|
Sequenced Plan Execution Order
|
Visibility
|
Context
|
|
Default
|
No
|
|
Solution
|
Windchill ProjectLink
|
|
Description
|
A sequenced implementation plan allows the change notice author to determine which change tasks should be completed before other change tasks can be started.
• Yes—When creating or editing a change notice, you can optionally specify the order in which change tasks should be implemented.
• No—Change notices do not support change task sequences.
When enabled, the Sequence column appears in the Implementation Plan table: | This preference only applies when Windchill ProjectLink is installed. If you are using sequenced implementation plans and manually perform a Set State action, the following occurs: • If the state is set to a resolved or canceled state, change tasks are marked as completed in the implementation plan. • If the state is set to a state other than resolved or canceled, then all executing change tasks are permitted to complete, but the processing of the sequenced implementation plan is suspended. |
|
Set Resolution Date
|
Visibility
|
Organization
|
|
Default
|
Yes
|
|
Description
|
Set this preference to Yes to automatically set the resolution date to the current time when a change object is manually moved to a terminal state. The resolution date is not set if the state changes through a workflow process or when imported. If the resolution date is already set, the change object is not updated with a new resolution date.
|
Unincorporated Change Creation
|
Visibility
|
Organization
|
|
Default
|
No
|
|
Solution
|
Windchill Aerospace and Defense
|
|
Description
|
• Yes—Allow users to create unincorporated changes.
• No—Users cannot create unincorporated changes. However, existing unincorporated changes remain visible.
|
Variance Effectivity
|
Visibility
|
Context
|
|
Default
|
No
|
|
Description
|
If set to Yes, effectivity statements can be specified for the affected objects of a variance.
|
Variance Owner Role Name
|
Visibility
|
Context
|
|
Default
|
VARIANCE AUTHOR
|
|
Description
|
The role name of the variance owner.
If you change the value of this preference, you must also modify the variance life cycle and workflow to include the corresponding role.
|
Variances in Projects
|
Visibility
|
Context
|
|
Default
|
No
|
|
Solution
|
Windchill ProjectLink
|
|
Description
|
• Yes—Users can create variances for objects shared to a project.
• No—Users cannot create variances for shared objects. However, existing variances remain visible.
|
Create and Edit
The following preferences are available from the preference manager under the Create and Edit preference group.
Change Notice Create Default Type
|
Visibility
|
Context
|
|
Default
|
WCTYPE|wt.change2.WTChangeOrder2
|
|
Description
|
The default type used when creating a new change notice:
• To specify the wt.change2.WTChangeOrder2 class (or one of its subclasses), enter the following:
WCTYPE|wt.change2.WTChangeOrder2 (or one of its subclasses)
• To specify a change notice subtype, enter the following:
WCTYPE|wt.change2.WTChangeOrder2|com.ptc.<ChangeNotice>
• To indicate that the user must select a change notice type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
|
Change Request Create Default Type
|
Visibility
|
Context
|
|
Default
|
WCTYPE|wt.change2.WTChangeRequest2
|
|
Description
|
The default type used when creating a new change request:
• To specify the wt.change2.WTChangeRequest2 class (or one of its subclasses), enter the following:
WCTYPE|wt.change2.WTChangeRequest2 (or one of its subclasses)
• To specify a change request subtype, enter the following:
WCTYPE|wt.change2.WTChangeRequest2|com.ptc.<ChangeRequest>
• To indicate that the user must select a change request type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
|
Change Task Create Default Type
|
Visibility
|
Context
|
|
Default
|
WCTYPE|wt.change2.WTChangeActivity2
|
|
Description
|
The default type used when creating a new change task:
• To specify the wt.change2.WTChangeActivity2 class (or one of its subclasses), enter the following:
WCTYPE|wt.change2.WTChangeActivity2 (or one of its subclasses)
• To specify a change task subtype, enter the following:
WCTYPE|wt.change2.WTChangeActivity2|com.ptc.<ChangeTask>
• To indicate that the user must select a change task type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
|
Problem Report Create Default Type
|
Visibility
|
Context
|
|
Default
|
WCTYPE|wt.change2.WTChangeIssue
|
|
Description
|
The default type used when creating a new problem report:
• To specify the wt.change2.WTChangeIssue class (or one of its subclasses), enter the following:
WCTYPE|wt.change2.WTChangeIssue (or one of its subclasses)
• To specify a problem report subtype, enter the following:
WCTYPE|wt.change2.WTChangeIssue|com.ptc.<ProblemReport>
• To indicate that the user must select a problem report type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
|
Promotion Request Create Default Type
|
Visibility
|
Context
|
|
Default
|
WCTYPE|wt.maturity.PromotionNotice
|
|
Description
|
The default type used when creating a new promotion request:
• To specify the wt.maturity.PromotionNotice class (or one of its subclasses), enter the following:
WCTYPE|wt.maturity.PromotionNotice (or one of its subclasses)
• To specify a promotion request subtype, enter the following:
WCTYPE|wt.maturity.PromotionNotice|com.ptc.<PromotionRequest>
• To indicate that the user must select a promotion request type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
|
Variance Create Default Type
|
Visibility
|
Context
|
|
Default
|
WCTYPE|wt.change2.WTVariance|com.ptc.Deviation
|
|
Description
|
The default type used when creating a new variance:
• To specify the wt.maturity.WTVariance class (or one of its subclasses), enter the following:
WCTYPE|wt.change2.WTVariance (or one of its subclasses)
• To specify a variance subtype, enter the following:
WCTYPE|wt.change2.WTVariance|com.ptc.<Variance>
• To indicate that the user must select a variance type, enter the following:
com.ptc.core.foundation.type.common.commonResource:SELECT_A_TYPE
|
Promotion Process
For information on the
Promotion Process preference group, see
Promotion Process Preferences.
