Share this page

# Mark stories done if tasks are completed

The following example demonstrates how to check if a user story's tasks are completed, and if so, mark the user story as done.

In this topic:

## Entity relationship diagram

The following entities are relevant to this example. The diagram illustrates the relationships between these 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, quality stories, and user 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
Tasks | Work items | Tasks must be associated with one user story, quality story, or defect. User stories, quality stories, and defects are work items. 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. | stories defects
Tasks | Phases | Tasks must be associated with a phase. | phase
Tasks | Users | Tasks must have one owner. | owner
Tasks | Attachments | Tasks can have attachments. | attachments
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
User Stories | Tasks | User stories can be associated with tasks. | story
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
Quality Stories | Tasks | Quality stories can be associated with tasks. | story
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 | User stories and quality stories | Defects can be associated with user stories and quality stories. | None
Defects | Tasks | Defects can be associated with tasks. | defect
Phases | Features, user stories, quality stories, and defects | Features, stories, and defects must be associated with a phase. | phase
Users | All work items | Epics, features, use stories, quality stories, and defects can be associated with an owner. | owner

Back to top

## Example

Using the REST API, check if a user story's tasks are completed, and if so, mark the user story as done.

To create the relevant REST API calls:

1. Using the GET operation, list all stories that are still in-progress.

   To do this, enter a query clause that lists only those work items whose subtype is story and whose phase is still in progress. Phase is a reference field, and we find the phase by id.

   Use the fields clause to control which fields are returned by the API call. Not all fields are returned automatically, so they must be specified. Add tasks_number to the list of fields to see if any of the in-progress stories are associated with tasks.

   `GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/work_items?fields=phase,release,name,id,tasks_number,subtype&query="(subtype EQ ^story^;phase EQ {id EQ ^phase.story.inprogress^})"`

2. For each story, check if the corresponding tasks are done.

   In this example, check the task corresponding to story 1019, because the previous API call showed that this story has one task, 1002, associated with it.

   This example also demonstrates the use of reference fields. Use the story reference field using the id to specify the story.

   `GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/tasks?query="(story EQ {id EQ ^1019^ } )"`

   Response

       {
           "total_count": 1,
           "data": [
               {
                   "type": "task",
                   "workspace_id": 1002,
                   "phase": {
                       "type": "phase",
                       "logical_name": "phase.task.completed",
                       "name": "Completed",
                       "index": 0,
                       "id": "1034"
                   },
                   "name": "This is my task.",
                   "id": "1002"
               }
           ],
           "exceeds_total_count": false
       }

3. The response shows that task 1002 did complete. Update the phase of the corresponding story, 1019, to Done.

   `PUT .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/work_items//1019`/

   Payload

       {

          "phase":{

               "type":"phase",

               "id":"phase.story.done"

              },

          "id":"1019"

       }

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: