Advanced Customization > Business Logic Customization > Customizing Workflow Administration > Customizing Workflow Task Pages > Configuring Workflow Task Detail Pages > Process Overview > Identify Tables to Render and Configure
  
Identify Tables to Render and Configure
The steps below will explain how to add the Affected Objects Table and Maturity History Table
1. Identify the PBO-related tables which should be rendered on task details page. It could be OOTB or your own customized tables.
Identify table component id along with its type-based information.
To identify the component id and componentConfigBuilder used by the component, refer to the debugging section of Customizing Information Page Components.
Refer to the JavaDoc for the builder of the component to check if the builder is defined with TypeBased annotation or not. Consider that the component id for the component is ‘changemanagement.affecteddatatable’ and the builder is configured to be a TypeBased.
For more information on TypeBased, see the “TypeBased: section in MVC Components Overview.
2. Configure the identified tables above into a workitem task action model.
Define a new action in a custom actions file for the component (e.g. Affected Data table) to display in the configurable workflow pages. The component name needs to be "workflowTask.pbo", the component id needs to be passed as pboCompId in the urlParams and the useTypeBased needs to have the value based on the finding in previous step.
For example:
<action name="TestAffectedData"
resourceBundle="wt.workflow.worklist.worklistResource" >
<component name="workflowTask.pbo"
urlParams="pboCompId=changemanagement.
affecteddatatable&amp;useTypeBased=true"/>
<includeFilter name="configurableTypeBaseFilter"/>
</action>
The includeFilter tag provides the filtering mechanism. The filter framework is applicable for table components/actions where includeFilter tag is used.
In the TaskFormTemplate UI, table actions display based on the PBO class selected for task form template.
In the code soft types are already supported. However, if you have applied filter for hard types (supported as true) and through UI if any soft type instance is provided as its owns type, but it does not exist it checks for its super class.
In the Customized tab on the Workitem Info page, actions displayed in the Customized menu is filtered based on the work items PBO type.
3. Create an action validator for the new action (TestAffectedData) created in the previous step. OOTB an abstract validator (WorkFlowTaskPBOComponentValidator class) and an override method (isComponentValidFor) is provided by the framework that filters the component based on PBO object type. The action validator for the new action need to override isComponentValidFor that defines whether PBO object type is valid or not for the given component.
package com.ptc.windchill.enterprise. workitem.validators;

import com.ptc.core.ui.validation.DefaultUIComponentValidator;
import com.ptc.core.ui.validation.UIValidationCriteria;
import com.ptc.core.ui.validation.UIValidationKey;
import com.ptc.core.ui.validation.UIValidationResult;
import com.ptc.core.ui.validation.UIValidationResultSet;
import com.ptc.core.ui.validation.UIValidationStatus;
import com.ptc.netmarkets.util.beans.NmCommandBean;
import com.ptc.core.meta.common.TypeIdentifier;
import com.ptc.windchill.enterprise.history.validators.
LifecycleHistoryNavValidator;

public class TestAffectedDataValidator extends
WorkFlowTaskPBOComponentValidator {

@Override
protected boolean isComponentValidFor(UIValidationKey validationKey,
UIValidationCriteria validationCriteria, WTReference pboRef) {

if (pboRef != null && pboRef.getObject() instanceof
LifeCycleManaged))
return true;

return false;
}

}
4. Configure the validators in the appropriate .properties files. The following code sample continues the example about PboMaturityHistory. Add these actions in the Workitem-service-properties.xconf file.
...
<Option cardinality="singleton" requestor="java.lang.Object"
serviceClass="com.ptc.windchill.enterprise.workitem.validators.
WorkflowTaskPboMaturityHistoryValidator"
selector="PboMaturityHistory"/> [Option cardinality="singleton"
requestor="java.lang.Object" serviceClass="com.ptc.windchill.enterprise.workitem.
validators.TestAffectedDataValidator" selector="TestAffectedData"/>
All these actions should be part of model “workitem third nav configurable” which is added to the Netmarkets-actionmodels.xml file.

...

<model name="workitem third nav">
<action name="attributes" type="workitem"/>
<action name="routingStatus" type="workitem"/>
<action name="notebook" type="workitem"/>
<action name="discussions" type="workitem"/>
<action name="setupParticipant" type="workitem"/>
<action name="adhocActivities" type="workitem"/>
<action name="workflowTaskPboAttributes" type="object"/>
<action name="saveComplete" type="workitem"/>
<action name="workflowTaskPboAction" type="workitem"/>
<action name="PboMaturityHistory" type="history"/>
<action name="TestAffectedData" type="change"/>
</model>
All the above actions are validated in super set defined in the configuration file (ConfigurableWorkflowTask-typeBasedActionFiler.properties.xconf).
Actions which are displayed on task details page should be present in the super set. If they do not exist then the task form template won’t be loaded and it will not be configurable from the TaskForm template UI.
In the configuration file you must make entries in following pattern:
<Property name="actionType.actionName.configurablePbo.supportedTypes/ nonSupportedTypes” overridable="true" default="object Type<comma separated fully qualified class names will be acceptable>"/>
Filtering is not applied for workitem actions. It should be applicable for the PBO type which is associated with workitem.