Add "test" tasks to work items that have none

The goal of this flow is to make sure that each of our stories has at least one task assigned to it that is of type test, and then add tasks as needed.

Entity relationship diagram

We need to access the following entities for this flow, and understand the relationships between these entities.

Entity relationship diagram to add "test" tasks to work items that have none.

The following shows the relations in the flow.

Entity	Relationships in this flow	Description of relationship	Reference / relationship fields
Work items	Epics, features, defects, user stories, and quality stories	This aggregate resource collection represents types of work items, including epics, features, defects, user stories, and quality stories.	subtype
Work items	Tasks	Work items can be associated with tasks.	child_task
Work items	Releases	Work items can be associated with releases.	release
Tasks	Work items	Tasks must be associated with one quality story, user story, or defect. Tasks cannot be associated with other work items, such as epics and features. User stories, quality stories, and defects can be associated with multiple tasks.	story defect
Tasks	Phases	Tasks must be associated with a phase.	phase
Tasks	Users	Tasks must have one owner.	owner
Tasks	List nodes	The type of each task can be referenced by querying the list_node resource collection.	item_type
Epics	Work items	Epics are subtypes of work_items. There is no field that relates back to the aggregate resource collection, work_items.	None
Epics	Features	Epics can be associated with features.	None
Features	Work items	Features are subtypes of work_items. There is no field that relates back to the aggregate resource collection, work_items.	None
Features	Epics	Features can be associated with epics.	parent
Features	Stories, and defects	Features can be associated with user stories, quality stories, and defects.	None
User stories	Work items	User stories are subtypes of work_items. There is no field that relates back to the aggregate resource collection, work_items.	None
User stories	Features	User stories can be associated with features.	parent
User stories	Defects	User stories can be associated with defects.	None
Quality stories	Work items	Quality stories are subtypes of work_items. There is no field that relates back to the aggregate resource collection, work_items.	None
Quality stories	Features	Quality stories can be associated with features.	parent
Quality stories	Defects	Quality stories can be associated with defects.	None
Defects	Work items	Defects are subtypes of work_items. There is no field that relates back to the aggregate resource collection, work_items.	None
Defects	Features	Defects can be associated with features.	parent
Defects	Stories	Defects can be associated with stories.	None
Phases	Features, quality stories, user stories, and defects	Features, quality stories, user stories, and defects must be associated with a phase.	phase
Users	All work items	Epics, features, quality stories, user stories, and defects can be associated with an owner.	owner
Releases	All work items	Epics, features, quality stories, user stories, and defects can be associated with an owner.	release
Releases	Sprints	Sprints are associated with releases.	release

Flow

The goal of this flow is to make sure that each of our stories has at least one task assigned to it that is of type test.

Let's create the REST API call step-by-step.

We want all stories to have tasks set up for them. Therefore, as a first step, we list all work items that are user stories.

To do this, we enter a query clause that lists only those work items whose subtype is story.

GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/work_items&query="(subtype EQ ^story^)"
If we look at the tasks resource collection, we can see that the item_type field is the one that lists the task type. This is a reference field, pointing to the list_node resource.

GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/tasks

In the response below, the item_type shows that an id of list_node.task_item_type.document indicates that this task happens to be of document type.
Response
Here is a partial response showing a task whose type is test, as indicated by referencing the list_node resource.
```
{
   "type": "task",
   "phase": {
       "type": "phase",
       "id": "phase.task.new"
   },
   "item_type": {
       "type": "list_node",
       "id": "list_node.task_item_type.document"
   },
   "remaining_hours": 9,
   "invested_hours": 0,
   "estimated_hours": 9,
   "name": "fixed and closed legends are the same color",
   "id": "1171",
   "story": {
       "type": "story",
       "id": "1070"
    }
},
  ... 
  ...
  ...
```

Now that we know how to see tasks for our stories, and we know the field to use to look up the type in list_nodes, how can we know the available task types?

We can see this by querying the list_node resource for any list node whose logical_name starts with list_node.task_item_type using the * wildcard.

Five types are returned. One is the root for list nodes for task items. The other four are the different task types available: research, development, document, and test.

GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/list_nodes?query="logical_name EQ ^list_node.task_item_type*^"

Now we have all the information we need to GET a list of all stories that are missing test tasks.

Note the use of the Not operator ! to get only the non-test tasks.

GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/work_items?fields=name,id&order_by=id&query="(subtype EQ ^story^;!(child_tasks EQ {item_type EQ {id EQ ^list_node.task_item_type.test^}}))"
If we want each story to have a test task, we add a new task for each one.

Note how we assign reference field values to certain fields when POSTing.

Also, this request demonstrates the usage of the is_draft feature to create draft entities. Draft entities let you bypass specifying values for required fields when creating the entities. Later, when updating the entities (PUT), the required fields will be mandatory. For details, see Draft entities.

POST .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/tasks

Payload
```
{"data":
   [   
      {   "item_type":
                {"type":"list_node",
                 "id":"list_node.task_item_type.test"},
          "phase":
                {"type":"phase",
                "id":"phase.task.new"},
          "story":
                {"type":"work_item",
                "id":"1220"},
          "owner":
                {"type":"workspace_user",
                "id":"1001"},
          "name":"Testing",
          "is_draft":true
      }
   ]
}
```