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.
The existing open redlines can still be opened, deleted, or merged with the affected object version if the wt.change.enableChangeIntent property is disabled. However, the opened redlines are cancelled during the synchronization when the wt.change.enableChangeIntent property is disabled.
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, Audit Change Summary table of audit change notice, and Associated Changes table. 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.
For more information on synchronization of the redline and affected objects, see the Synchronizing the Changes to Other Open Change Notices section in Redline Process and the Synchronization of the Affected Object Version to the Latest Released Resulting Object section in How Change Notice and Change Activity Workflows Work Together.
Access Control for the BOM Redline
The Read permission is the minimum permission for any affected objects type on any Change Management object, such as Problem Report, Change Request, Change Notice, and Change Task.
The BOM redlines have a Redline Life Cycle associated to them OOTB, which can be different from the life cycle associated with the affected objects types.
When working with the BOM redlines in a Change Task, a user with Read permission to the affected object can perform the following actions:
Create the BOM redline with Create permission to the BOM redline initial life cycle state.
Open the BOM redline with Modify permission to the BOM redline life cycle state.
View the BOM redline with Read permission to the BOM redline life cycle state.
Delete the BOM redline with Delete permission to the BOM redline life cycle state.
View the BOM redline with minimal Read permission when the BOM redline is closed or locked.
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:
Site > Utilities > Preference Management > Change Management > Redline Version Prefix
Organization > Utilities > Preference Management > Change Management > Redline Version Prefix
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:
<!-- set the lifecycle -->

<AttrValue id="adhocVersionInfo" algorithm="wt.rule.algorithm.StringConstant">

<Arg></Arg>
</AttrValue>

<AttrValue id="lifeCycle.id" algorithm="com.ptc.core.foundation.lifecycle.server.impl.LifeCycleTemplateAttributeAlgorithm">
<Value algorithm="wt.rule.algorithm.CaseBranch">
<Value algorithm="wt.rule.algorithm.StringEqualsTest">
<Attr id="adhocVersionInfo"/>
<Arg>adhoc</Arg>
</Value>
<Arg>Redline Life Cycle</Arg>
<Arg>Basic</Arg>
</Value>
</AttrValue>
Was this helpful?