States can be categorized into two classes: open and closed. Most states belong to the open category; the default configuration sets only state closed and suspended to category "closed". This allows for easy queries such as: "give me all open issues", meaning all those that are not in states closed or suspended. In the Track+ application the states can be easily configured and customized. The following describes the default configuration.
There are nine different states defined an issue can be in (the state category is shown in brackets):
|
initial |
the initial state of every issue if no other state is assigned. This means the issue has been filed. This state is optional and may be superceded by open [open] |
|
opened |
this means the issue has been filed and the person or group responsible for it has been notified [open] |
|
analyzed |
the issue has been examined and it has been evaluated whether a solution has to be pursued. Useful for e.g. problem reports and requirement changes [open] |
|
assigned |
the issue has been assigned to a $EXECUTOR [open] |
|
processing |
the issue is being processed by the $EXECUTOR [open] |
|
implemented |
the solution has been implemented and is ready for integration by $INTEGRATOR or $TESTER [open] |
|
assessed |
a solution has been found and assessed (tested) at the support site, and sent to the party who reported the problem; that party is validating the solution [open] |
|
closed |
the solution has been confirmed by the party which reported it, or the $TESTER [closed] |
|
suspended |
in some cases, it may be necessary to suspend work on an issue; in this case, its state changes to suspended rather than closed [closed] |
Figure 7: Valid State Transitions
Currently there is no enforcement of valid state transitions as this has shown to be not too helpful. All important state transitions (e.g. from an open state to a closed or suspended state) are being e-mailed to the people concerned anyway. Thus the risk of loosing an issue is rather small.