Add "test" tasks to work items that have none

This flow demonstrates how to get a list of work items that are missing tasks of type test, and then add tasks as needed.

Areas: Work items, Tasks, List nodes

Entity relationship diagram

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

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
Tasks Work items can be associated with tasks. child_task
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

Phases Tasks must be associated with a phase. phase
Users Tasks must have one owner. owner
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.

 
Features

Epics can be associated with features.

 
Features Work items

Features are subtypes of work_items.

There is no field that relates back to the aggregate resource collection, work_items.

 

Epics

Features can be associated with epics.

parent

Stories, and defects

Features can be associated with user stories, quality stories, and defects.

 
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.

 
Features

User stories can be associated with features.

parent
Defects

User stories can be associated with defects.

 
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.

 
Features

Quality stories can be associated with features.

parent
Defects

Quality stories can be associated with defects.

 
Defects Work items

Defects are subtypes of work_items.

There is no field that relates back to the aggregate resource collection, work_items.

 
Features

Defects can be associated with features.

parent
Stories

Defects can be associated with stories.

 
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

Back to top

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.

  1. 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/<shared_space_id>/workspaces/<workspace_id>/work_items&query="(subtype EQ ^story^)"

  2. 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/<shared_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.

  3. 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/<shared_space_id>/workspaces/<workspace_id>/list_nodes?query="logical_name EQ ^list_node.task_item_type*^"

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

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

    GET .../api/shared_spaces/<shared_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^}}))"

  5. 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 Working with draft entities.

    POST .../api/shared_spaces/<shared_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
          }
       ]
    }

Back to top

See also: