Issues have their lifecycle. They are being created, they are processed by the users, and finally they are being closed. By changing the Status of the Issue, the user is managing the lifecycle of the Issue. The lifecycle of the Issues is defined by Workflows.
In Workflows, first you define the Issue Type, then the project role, and finally the 'Start Statuses' and the available 'Destination Statuses'. It means, that by the defined Issue Type (e.g. Task) only the defined project role (e.g. Reporter) can change the specified start Status (e.g. 'New') to the specified destination Status (e.g. 'In Progress' and 'Closed'). Workflows are fully customizable. qmsWrapper includes default Workflows, and you also have the option to change them or create new ones.

In our example, we are going to demonstrate how to work on Issues, through the lifecycle of a Bug type Issue. Let’s say, a 'Developer' user discovered a glitch in our software.

  1. Let’s say, a 'Developer' user discovered a glitch in our software. The 'Developer' user should now report the bug in qmsWrapper somehow. 
  2. The user is going to create a new 'Bug' Issue accordingly, and assign it to a user to work on it.
  3. According to the defined Workflow of the Bug Issue type, the Developer can change the Status of a Bug from ‘New’ to 'In Progress' or 'Closed'. The assigned 'Developer' user who is working on the Bug, is opening up the Issue. By editing the Issue, the user sets the Status to ‘In Progress’. This indicates that the user started working on the Issue.
  4. According to the defined Workflow of the Bug Issue type, the Developer can change the Status of a Bug from ‘In Progress’ to 'Resolved', 'Feedback' or 'Rejected'. The user has finished working on the Bug, and the user is updating the Status from 'In Progress' to 'Resolved'. The user is then assigning the Bug to the 'Manager' user, who is supervising the resolved Issues.
  5. According to the defined Workflow of the Bug Issue type, the Manager can change the Status of a Bug from ‘Resolved’ to any other Status. The 'Manager' user is updating the Status of the Bug to 'Closed'.
    In some cases, the 'Manager' user can change the Status from ‘Resolved’ to ‘Feedback’ and assign the Issue back to the 'Developer' user. This is usually done if additional information or feedback is needed about the Bug from the 'Developer' user.
    In some cases, the 'Manager' user can change the Status from 'Resolved' to ‘Rejected’. This is usually done if the bug was not resolved successfully. The 'Manager' can reopen the Issue again.
  6. When the Status of the Issue is set to ‘Closed’, it's lifecycle is ended and the work is done.