![]() |
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.
|
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: ![]()
|
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.
|
Visibility
|
Organization
|
||
Default
|
Yes
|
||
Description
|
Automatically create a change notice from the task page of a change request.
|
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.
|
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.
|
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.
|
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. |
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.
|
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.
|
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.
|
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.
|
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.
|
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
For more information, see Configuring the Initial Collection of Objects for Actions.
|
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.
|
Visibility
|
Context
|
||
Default
|
(Default task) Modify affected objects
|
||
Description
|
The name of the automatically generated change task that appears in the implementation plan of a change notice.
|
Visibility
|
Organization
|
Default
|
Yes
|
Description
|
Expose the organization for all change objects.
|
Visibility
|
User
|
Default
|
Yes
|
Solution
|
Windchill Quality Solutions
|
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.
For more information on working with dispositions, see The Windchill Nonconformance Process.
|
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.
|
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.
For more information, see Administration of Terminal States for Change Management Objects.
|
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.
For more information, see Administration of Change Process Transitions and Phase Transitions.
|
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.
|
Visibility
|
Context
|
Default
|
No
|
Description
|
Determine whether change tasks are required to be reviewed.
• Yes—Reviews for change tasks are optional, and you are not required to specify a reviewer.
• No—Change tasks require reviewer assignments, which are made when the change task is created.
|
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 ![]() |
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.
For more information, see Administration of Problem Reports and Variances in Projects.
|
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: ![]()
|
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.
For more information, see Administration of Terminal States for Change Management Objects.
|
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.
For more information, see About Unincorporated Changes.
|
Visibility
|
Context
|
Default
|
No
|
Description
|
If set to Yes, effectivity statements can be specified for the affected objects of a variance.
|
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.
|
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.
For more information, see Administration of Problem Reports and Variances in Projects.
|
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
|
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
|
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
|
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
|
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
|
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
|