Customizing Task Options

This section describes ways to customize tasks.

For the best performance, only add properties to the page object if you want to change the value. Do not include properties if you want to use the default value.

For your first configured property, you must create a new page object. If you previously created a page object, open the page for editing instead.

This task shows you how to:

Customize the Task Type Hierarchy
Customize Task Deliverables
Automatically Complete Tasks On Deliverables Promotion
Activate Dependency Triggers
Define Default Policies for Task Types

Customize the Task Type Hierarchy

Project Management uses the type hierarchy defined for the Task Management type to determine the rules behind the creation of the task schedule.

For example, some customers may want to ensure that a project can only have "Phase" as parent tasks or summary tasks. By default, there is only one subtype and it is called "Task."

When importing a project from an ASCII file, only the standard task type can be used. The ASCII import does not currently recognize additional task types.

Here are examples of two task hierarchies:

If you create a task under the project node with Structure 1, the task types you have available include Task and Phase. If you create a child task of Phase, you can choose SubPhase1 or SubPhase 2 as the task type. If, however, you create a child of SubPhase 2, which does not have any children, the system lets you select from a list of SubPhase 3 and any of its siblings that also include SubPhase 1.

If you created a task under the project node with Structure 2, the task types available include Task, SubTask1, Phase, SubPhase1, SubPhase 1.1 and SubPhase 2. When you create a child of any of these tasks, since they do not have children, the parent and all its siblings are displayed.

To add additional task types to the schedule, follow these steps:

Log into MQL as a user with business administrator privileges.
Create a new subtype that is derived from Task Management.
```
MQL> add type "TYPE_NAME" derived "Task Management" attribute Status;
```
where TYPE_NAME is the type that you want to create.

Subtypes called Milestone and Phase are common customizations.
The Status attribute from type Task should be added to any type derived from Task Management.
Assign attributes to the new subtype as required. It automatically inherits all attributes of Task Management.
Assign the new subtype to the Project Task policy or to a custom policy.
To get the same access model used for the Project Task policy, create any new custom policies by duplicating the existing Project Task policy.
All policies for task types must have a state registered as state_Complete for filters and triggers.
Extract emxCommonMappingFile.properties from common.jar and edit the file to contain the new subtypes.
For example, if adding a new subtype called Phase, the line in emxCommonMappingFile.properties would look like: type_Phase=com.enovia.apps.common.Task
To register the subtype and policy:
1. Log in to Project Management with Business Admin privileges.
2. From the Compass, click Social and Collaborative Apps  and select Admin Tools > Property Registration > Admin Types.
  You see the Admin Type Property Registration page.
3. From the Admin Type list, select Type.
4. Select Project Space from the Registered Admin's list and select the new project subtype from the Un-Registered Admin’s list. Then click the Retrieve Registration button.
5. Change the Symbolic Name text field to type_[subtype name].
6. Select the Installed Date from its calendar field.
7. Click the Create Registration button.
  You see the new subtype under the Registered Admin's list.
Add the new subtype (and any new policies) to the Framework string resource file:
1. Open emxFrameworkStringResource.properties, located in ENOVIA_INSTALL/properties.
2. Add a key and value for the new type using the format emxFramework.Type.NAME=DISPLAY_NAME.
  For example: emxFramework.Type.Milestone=Milestone
3. Repeat these steps for each language and new type/policy, as required.
Create a copy of the policy to apply to the subtype.
1. Log into MQL as a user with business administrator privileges.
2. To create a copy of the policy to apply to the created subtype above, use the following syntax:
```
MQL> copy policy "Project Task" "POLICY_NAME";
```
  where POLICY_NAME is the name of the policy that you want to create.
Rebuild the archive files and restart the server.
Verify that the new subtype is listed in Project Management by adding a new task to a project. The Task Type list should include all new subtypes. If multiple policies exist, the New Task page includes a policy list.

Customize Task Deliverables

By default, task deliverables can be documents and types appropriate for use with Engineering BOM Management, such as parts, ECRs, and CAD drawings. You can configure the system so users can add other types and add an association that gives the project owner access to see task deliverables. You can also remove some of these types. The types you define are available in the chooser when users search for project content to add as a task deliverable.

To add types for task deliverables, follow these steps:
1. Log into MQL as a user with business administrator privileges.
2. To add a type to be available for Task Deliverables, use the following syntax:
```
MQL> modify relationship "Task Deliverable" to add type "TYPE";
```
  where TYPE is the type that you want to be available for selection in Deliverables.
3. Find the Task Deliverable relationship and open it for editing.
4. To add a type, add the type to the "To" end of the relationship.
5. Restart the server.
6. Verify the types that you defined can be added as a deliverable. From the navigation pane for a task, click Deliverables. Then click Add Project Content. From the Search page, click the chooser button for the Type field. The types you defined should be listed in the Chooser.
  Now that the type is available as a deliverable, you can configure a trigger so the task is auto-promoted to Complete when the deliverable is promoted. See Auto-Promoting Tasks Based on Deliverable Promotions.
To remove types for task deliverables, follow these steps:
1. Log into MQL as a user with business administrator privileges.
2. To remove a type to be available for Task Deliverables, use the following syntax:
```
MQL> modify relationship "Task Deliverable" to remove type "TYPE";
```
  where TYPE is the type that you want to remove availability from Deliverables.
3. Remove the type from the "To" end of the relationship.
4. Restart the server.
Note: Any existing connections of Task Deliverable to that type will remain connected.

Automatically Complete Tasks On Deliverables Promotion

The app includes a trigger that automatically promotes a task to Review when its deliverable is completed. The expected result would be to promote the task to Complete. Since the out-of-the-box functionality promotes the task to Review, if you want to change the default functionality, you must write custom code.

By default, this trigger is not implemented for any policy. Use these instructions to implement the trigger. The trigger is:

Type: eService Trigger Program Parameters

Name: DeliverablesPromoteTaskComplete

Rev: SetStateComplete

To configure a trigger to complete a task when a deliverable is completed:
Log into MQL as a user with business administrator privileges.
Find the policy that governs the type that is defined as a deliverable.
For example, suppose ECRs are defined as task deliverables (they are by default, see Define the Content of Project Bookmarks). You want to configure a trigger so when an ECR that is added as a deliverable is promoted to Complete, the task is also promoted. To do this, you would find the policy that governs ECRs
Add the trigger as a promote action trigger on the state the promotion from which should cause the trigger to fire. The Action is emxTriggerManager and the Input is DeliverablesPromoteTaskComplete.

If the state already has an action trigger executed by the trigger manager, add a space after the name of the first trigger, in the Input field, and enter DeliverablesPromoteTaskComplete.
If there are multiple triggers, update the eService Sequence Number for the eService Trigger Program Parameters objects so the triggers fire in the correct sequence.
Make sure the eService Trigger Program Parameters object is set to Active.

Activate Dependency Triggers

By default, the dependency between two tasks does not restrict the completion of a dependent task. A dependent task can finish before its predecessor task. To restrict a dependent task from becoming completed before its predecessor, six triggers need to be promoted to the "Active" state. (By default, these triggers are set to "Inactive".)

Below are the triggers you need to make "Active":


Trigger Name	Revision
PolicyProjectReviewStateCreatePromoteCheck	CheckDependency
PolicyProjectReviewStateReviewPromoteCheck	CheckDependency
PolicyProjectSpaceStateAssignPromoteCheck	CheckDependency
PolicyProjectSpaceStateReviewPromoteCheck	CheckDependency
PolicyProjectTaskStateAssignPromoteCheck	CheckDependency
PolicyProjectTaskStateReviewPromoteCheck	CheckDependency

Note: While promoting a task having a "rigid constraint," if the actual dates are different from the constraint date, you can display a notice message by promoting the PolicyProjectTaskStateAssignPromoteCheck trigger to the Active state.

Log into MQL as a user with business administrator privileges.
To promote a trigger object to active, use the following syntax:
```
MQL> promote businessobject "eService Trigger Program Parameters" "Trigger Name" "Revision";
```
where the Trigger Name and Revision are included in the above table. Repeat the command for each Trigger Name in the table.

Define Default Policies for Task Types

You can add a page object that associates default policies for both standard and customized task policies.

The default policy types are used when tasks are automatically created. When you create a task from a dialog, the policy menu first shows the default value. You can select another policy as required.

The default policy is enabled for the following use cases:

Creating a task while importing a project from a .csv file
Quick creation of a task from the schedule view
Creating a task from the Gantt chart
Creating a collaborative task
The Create Task form displays the "default" policy as the first option; however, you can select another policy.

A customized task policy does not apply to the following use cases. Instead the source task policy is applied:

Creating a new task structure from a template or project
Copying and pasting a task
Creating a new experiment or baseline

Define Default Policy for Task Types

Task types include Task, Phase, Gate, and Milestone.

Open the dpm-preference-custom page object.
Uncomment the " ds:service" tag.
Remove all "ds:item" tags (if any) that are not required.
Add the "ds:item" tag (as child of "ds:range"” tag) for the type and its default policy.

The "ds:item" tag represents the default policy preference for a single type and it should be a child of the "ds:range" tag. The "value" attribute represents the type name and the "display" attribute represents the default policy name.
When you are finished, close the dpm-preference-custom page object.

Run the following MQL commands:

set context user creator;

verb on;

modify page dpm-preference-custom file FILEPATH;

modify page master-services hidden !hidden;

Define a Custom Policy

Log into MQL as a user with business administrator privileges.

Add the custom policy in MQL:

MQL> add policy "NAME" type "TYPE_NAME" {,"TYPE_NAME"}| all state "STATE_NAME" property "NAME" value "STRING";

For Example:

MQL> add policy "Custom Policy" type "Task" state "Create" state "Assign" state "Active" state "Review" state "Complete" property state_Create value Create property state_Assign value Assign property state_Active value Active property state_Review value Review property state_Complete value Complete;

Register the policy in the "Property registration section."
Map the custom policy and its states in the schema properties file.

The properties file is emFrameworkStringResource.properties. (Do this also for other required language properties files.)

For example:

emxFramework.Policy.Custom_Policy=Custom Policy

emxFramework.State.Custom_Policy.Create=Create

emxFramework.State.Custom_Policy.Assign=Assign

emxFramework.State.Custom_Policy.Assign=Assign

emxFramework.State.Custom_Policy.Active=Active

emxFramework.State.Custom_Policy.Review=Review

emxFramework.State.Custom_Policy.Complete=Complete
Configure the customized page object:
1. Open the dpm-preference-custom page object.
2. Uncomment the " ds:service" tag.
3. Remove all "ds:item" tags (if any) that are not required.
4. Add the "ds:item" tag (as child of "ds:range"” tag) for the type and its default policy.
5. When you are finished, close the dpm-preference-custom page object.
6. Run the following MQL commands:
```
set context user creator;
```
```
verb on;
```
```
modify page dpm-preference-custom file FILEPATH;
```
```
modify page master-services hidden !hidden;
```