Share this page

# Add "test" tasks to work items that have none

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

In this topic:

## Entity relationship diagram

The following entities are required for this example. The diagram illustrates the relationships between the entities.

The following table shows the relations in the example.

Entity | Relationships in this example | 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

Back to top

## Flow

Create a REST API call that makes sure that each story has at least one task assigned to it that is of type test.

To create the REST API call:

1. List all work items that are user stories.

   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. In the tasks resource collection, 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 following response, the item_type shows that an id of list_node.task_item_type.document indicates that this task happens to be of document type.

   Here is a partial response showing a task whose type is test, as indicated by referencing the list_node resource.

   Response

       {
          "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. View the available task types 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. The following request gets 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. Add a new test task for each story.

   Note that you assign reference field values to certain fields when POSTing.

   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:

- REST API calls
- Common flows and ER diagrams

https://admhelp.microfocus.com Software Delivery Management 8942
Tips to improve your search results... OpenText™ Software Delivery Management Help Center OpenText™ Software Delivery Management Help 26.1 All View Local Help Center View Online Help Center Version: