REQUEST A DEMO

Adding additional properties to a task manager task definition

One of the modules within a Clarify system is Task Manager. In support environments, it’s typically used to automatically generate subcases. Task Manager can be kicked off by using the Jobs button on a case, or by having a business rule call the taskmgr executable.

A task definition defines the specifics of the object that is to be created (in this case, we’re talking about a subcase that gets created).

Out of the box, Clarify allows you to set the following subcase properties when a subcase is created via Task Manager:

  • title
  • description
  • required date
  • priority
  • status
  • severity
  • elapsed time

But, like most things in Clarify, we can setup additional properties.

Custom property – subcase type

For example, lets say we want to be able to set the subcase type. The valid subcase types are General and Administrative.

By default, Task Manager will create an Administrative subcase. Lets see how we can have it create a General subcase.

The properties that are available for setup in a task are stored in the cls_prop_map table.

To see the baseline ones that are available for subcases:

select * from table_cls_prop_map where focus_type = 24

We can see the seven baseline properties, the same ones I listed above.

So, lets add a new one for Subcase Type. We’ll create a simple DAT file like so:

OBJECT TYPE="cls_prop_map", NAME="subcaseType"
	FIELDS
		db_data_type=516;
		display_name="Subcase Type";
		sch_name="sub_type";
		flag=0;
		context_map="";
		src_typ_dsply="value";
		source_value="";
		focus_type=24;
		appl_id="";
		db_data_dsply="character";
		list_name="";
	END_FIELDS
END_OBJECT NAME="subcaseType"

 

This DAT file is available at: https://gist.github.com/gsherman/8669401

We can import that into our database using dataex or diet.

Task Definition UI

Now, when we try to create a new task definition (Policies & Customers –> New –> Task Definition), we can see that Subcase Type is now an available property:

task

 

Now I can set the subcase type to General, and save the task definition, and add that to a task set.

Now, if I run task manager (either from using the Jobs button a case, or using the taskmgr executable), I get a subcase created that has a type of General:

subcase

sweet!

 

Existing Task Definitions

But what about existing (already created) task definitions?

The properties that are defined in the cls_prop_map table are only used when creating a new task definition.

If you already have a task definition created, then the custom properties we added won’t show up.

That’s because when a task definition is created, it reads the properties from cls_prop_map. And it saves them to cls_prop. So for existing task definitions, it reads them from cls_prop.

So what we need to do is to add a new row to cls_prop for the particular task.

To be honest, this is a bit tricky, mainly due to the data model.

If you look at the data model for task sets, you’ll see it involves:

  • stage_task
  • cls_factory
  • cls_ref
  • cls_prop

We have a few different options here how to solve this.

  • Create a script (ClearBasic, Dovetail-SDK based, etc.) that traverses from the stage_task to cls_factory to cls_ref to cls_prop, sees if we have a Subcase Type cls_prop row defined. If not, add one, and relate to the appropriate cls_ref.
  • On the task manager form, we could add a button, such as a Add Missing Properties button, that adds the cls_prop rows and related to cls_ref.
  • Use a DAT file to import a new cls_ref row for a particular task definition.

I did a simple test using the 3rd option – using a DAT file.

This DAT file is available at: https://gist.github.com/gsherman/8670495

Edit it to define the stage_task that you want to add a custom property to, import it, and we now see that the Subcase Type shows up on the properties of the task definition:

existing-task

 

Summary

And there  you have it – how to add a custom property to a task set definition. This method will work on baseline fields (such as Subcase Type), custom fields, and even on relations. With relations, you’re cls_prop and cls_prop_map will have different values. My suggestion here is to examine the baseline ones (such as subcase status) and mimic its structure.

Hope this helps.