Redline Administration
An administrator can enable the redline feature by setting the wt.change.enableChangeIntent property. When the property is set to true, the creation of redline is enabled, and you can use the redline feature. When set to false (default), the creation of redline is disabled, and the redline feature is unavailable.
Follow this checklist to prepare the system for use of the redline features:
• Define and configure a Life cycle Template that will be used for the redline.
An OOTB example Life cycle Template is provided with Windchill. The use of any Life cycle Template requires OIR configuration. The supporting access control policies must be established based on the definition of the Life cycle Template and the desired business process that will be used for the redlines.
• Define redline revision labels.
The redline obtains its revision label from the released revision that is being used for planning changes. A revision label prefix and a sequential number are assigned to each redline created for a specific released revision. The choice of revision label prefix can be configured by the administrator.
• Define the Valid Release States for Specific Types of Objects.
The defined set of release states for any object determines when a version can have a redline and when versions will be synchronized.
• Define the Pending Implementation State for Change Notices.
A new life cycle state must be added to represent the staging area for change notices that have been planned, approved, and are ready to be implemented. Change notices that adopt the Pending Implementation state use the Start Execution action to trigger the implementation of the change notice in its workflow. You should manually set the state in the Pending Implementation state field in the Type and Attribute Management utility of the change notice.
• Expose the redline attribute in the Affected Objects tables.
The new redline attribute must be incorporated into the desired views of the Affected Objects table, and Change Summary table of change notice and Audit Change Summary of audit change notice. In addition, it is good practice to include the Change Intent attribute in these tables also.
• Map the change intent values to release targets.
The change intent values can be mapped to the specific release targets that should be assigned when releasing the corresponding resulting object.
• Adjust the change notice workflow.
The change notice workflow requires some adjustments to define how change notices are to be planned with the use of redlines, and where in the workflow they should become approved. In addition, any rework or refinement steps may require that the state of the redlines is reset for modification.
◦ Enhance the custom workflow.
To activate the redline actions, you must add a global workflow variable isRedlineSupported of type boolean and value true to the custom workflow. Otherwise, the old workflows will not have the redline actions visible without this variable.
The Release Changeables robot or WorkflowProcessHelper.releaseChangeables API must be used to release the affected objects for initiating the synchronization.
The WorkflowProcessHelper.setChangeRedlineState API must be used to manage the state of the redlines in a workflow, for example, for adding the Approval, Refinement (to reset to working states), and Cancellation paths for redlines.
You must define the Object Release States mapping rule to trigger the synchronization.
Defining the Object Release States Mapping Rule
The Object Release States mapping rule maps the affected object type to the released state. It controls the creation of redline.
The Mapping Rules table is available at the organization context when the wt.mappingRules.enableOrganizationRules property is set to true. By default, this property is set to false. The rule defined at the organization context take precedence over the site context rules.
For more information on how to define the
Object Release States mapping rule, see the Object Release States section in
Define Mapping Rules for Change Management.
Using the Redline Version Prefix Preference
To name a redline, use the Redline Version Prefix preference available at the organization and site level. The preference specifies the text to be applied as the prefix for the redline version label. PTC recommends that you set the preference as Chg- for the redline. When the redline is created for a part, it shows this prefix along with the released revision the redline was created from. For example, if a part’s name is “Engine” and the revision is A.1, when you create a redline for this part, the redline name is displayed as “Engine Chg-A-1.0”.
You can view this preference from the following launch points:
• 
> > > >
• 
> > > >
Using Redline Life Cycle Template
The Redline Life Cycle template is a default life cycle template created for the redlines and it has the
In Work,
Approved, and
Cancelled states. The Redline Life Cycle template is provided OOTB. If you want to use this template for the redline for your customized Object Initialization Rule (OIR) for the WTPart, you must update the OIR for the WTPart. For more information on how to update the OIR, see the Updating Object Initialization Rule for Redline in section
Redline Administration.
Updating the Object Initialization Rule for the Redline
This topic provides an example of customizing the existing object initialization rule for a WTPart. To assign a separate life cycle template to a redline, you must update the object initialization rule for a WTPart for the redline. Here is an example of updating the object initialization rule: