Share this page

# 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.

Areas: Work items, Tasks, List nodes

In this topic:

## 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
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
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
Releases | All work items | Epics, features, quality stories, user stories, and defects can be associated with an owner. | release
Sprints | Sprints are associated with releases. | release

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/<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/<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"
           }
       },
         ...
         ...
         ...

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

   Response

       {
           "total_count": 5,
           "data": [
               {
                   "type": "list_node",
                   "logical_name": "list_node.task_item_type.research",
                   "name": "Research",
                   "list_root": {
                       "type": "list_node",
                       "id": "list_node.task_item_type"
                   },
                   "id": "list_node.task_item_type.research",

               },
               {
                   "type": "list_node",
                   "logical_name": "list_node.task_item_type.develop",
                   "name": "Develop",
                   "list_root": {
                       "type": "list_node",
                       "id": "list_node.task_item_type"
                   },
                   "id": "list_node.task_item_type.develop",

               },
               {
                   "type": "list_node",
                   "logical_name": "list_node.task_item_type.document",
                   "name": "Document",
                   "list_root": {
                       "type": "list_node",
                       "id": "list_node.task_item_type"
                   },
                   "id": "list_node.task_item_type.document",

               },
               {
                   "type": "list_node",
                   "logical_name": "list_node.task_item_type.test",
                   "name": "Test",
                   "list_root": {
                       "type": "list_node",
                       "id": "list_node.task_item_type"
                   },
                   "id": "list_node.task_item_type.test",

               },
               {
                   "type": "list_node",
                   "logical_name": "list_node.task_item_type",
                   "name": "Task Item Type",
                   "list_root": null,
                   "id": "list_node.task_item_type",

               }
           ],
           "exceeds_total_count": false
       }

4. 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^}}))"`

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 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
             }
          ]
       }

Back to top

See also:

- How to work with the REST API
- Common flows and ER diagrams

https://admhelp.microfocus.com ALM Octane 8942
Tips to improve your search results... ValueEdge & ALM Octane Help Center ValueEdge ALM Octane Help 16.0.100-16.0.400 All View Local Help Center View Online Help Center back Go back in browser history forward Go forward in browser history Remove search highlights next topic Go to next topic previous topic Go to previous topic Print the current topic Version: