Difference between revisions of "Task Manipulation"
| Line 1: | Line 1: | ||
This artical is made due to standardizing requirements when manipulating with task. Task is a resource which is very distinguish with others because it has many people get involed and spends on several phases in its cycle life. | This artical is made due to standardizing requirements when manipulating with task. Task is a resource which is very distinguish with others because it has many people get involed and spends on several phases in its cycle life. | ||
| − | = <span style="color: #ff9900">PEOPLE INVOLED</span> = | + | = <span style="color: #ff9900">PEOPLE INVOLED</span> = |
The people are | The people are | ||
| Line 15: | Line 15: | ||
[[Image:TASK MANIPULATING.jpg]] | [[Image:TASK MANIPULATING.jpg]] | ||
| − | = <span style="color: #ff9900">STATUSES</span> = | + | = <span style="color: #ff9900">STATUSES</span> = |
In its life cycle, a task might spend on several statuses: | In its life cycle, a task might spend on several statuses: | ||
| Line 22: | Line 22: | ||
#IN PROGRESS : after being accepted, it goes to this status. | #IN PROGRESS : after being accepted, it goes to this status. | ||
#REJECTED : or it might go to this status when the responsible thinks it is not true. | #REJECTED : or it might go to this status when the responsible thinks it is not true. | ||
| − | #COMPLETED : after making the issue working, the responsible sets it complete. | + | #COMPLETED : after making the issue working, the responsible sets it complete. |
| − | #APPROVED : the task's supervisor retests the issue and see it workign properly and approve it for good. | + | #APPROVED : the task's supervisor retests the issue and see it workign properly and approve it for good. |
| − | #CANCELLED : the supervisor can cancel the task whenever he/she see it no need to be fixed any more. | + | #CANCELLED : the supervisor can cancel the task whenever he/she see it no need to be fixed any more. |
| − | Besides, we can see that there are two loops in the workflow above. Those loops happen when it happens the confliction or disagreement between responsible and supervisor. Specificly, supervisor can reject responsible rejection to get the task status back to NEED ACCEPTANCE, or when the issue does neither working properly nor causing another issue after fixing, he/she will disapprove which get the task back to IN PROGRESS. | + | Besides, we can see that there are two loops in the workflow above. Those loops happen when it happens the confliction or disagreement between responsible and supervisor. Specificly, supervisor can reject responsible rejection to get the task status back to NEED ACCEPTANCE, or when the issue does neither working properly nor causing another issue after fixing, he/she will disapprove which get the task back to IN PROGRESS. |
| + | |||
| + | = <span style="color: #ff9900">EXECUTIVE ACTIONS AND VALIDATIONS</span> = | ||
| + | |||
| + | The task status is changed when a manipulating action is executed. According to the workflow above, we can seethere are 7 actions whose names are clear to understand what they are. However, a question comes out. Who can do that? Is there any constraint on executing? | ||
| + | |||
| + | First at all, who can do that? The people can do that could be the responsibles or supervisors or observers which are considered basing on resource access. So instead of saying observer with a specific permission, I will use a minimium specific permission. And here is the range of who | ||
| + | |||
| + | #Responsible | ||
| + | #Supervisor | ||
| + | #Administrator (Full control) | ||
| + | #Manager (Write only) | ||
| + | #Observer (Read only) | ||
| + | |||
| + | |||
| + | |||
| + | #<span style="color: #800000">ACCEPT</span> | ||
| + | #<span style="color: #800000">REJECT</span> | ||
| + | #<span style="color: #800000">REJECT REJECTION</span> | ||
| + | #<span style="color: #800000">DONE (SET COMPLETE)</span> | ||
| + | #<span style="color: #800000">APPROVE/DISAPPROVE</span> | ||
| + | #<span style="color: #800000">CANCEL</span> | ||
Revision as of 09:34, 8 July 2009
This artical is made due to standardizing requirements when manipulating with task. Task is a resource which is very distinguish with others because it has many people get involed and spends on several phases in its cycle life.
PEOPLE INVOLED
The people are
- Responsible : the person will take care the task.
- Supervisor : the person monitors the process of task execution.
- Observer : the person who concern the task executing process.
The life cycle of a task is quite complicated but in short description, since a task is created, it will be accepted to carry out by the responsible and end at approval or calcellation. And the workflow below is describing in more details
STATUSES
In its life cycle, a task might spend on several statuses:
- NEED ACCEPTANCE : when created, a task needs to be assigned to someone.
- IN PROGRESS : after being accepted, it goes to this status.
- REJECTED : or it might go to this status when the responsible thinks it is not true.
- COMPLETED : after making the issue working, the responsible sets it complete.
- APPROVED : the task's supervisor retests the issue and see it workign properly and approve it for good.
- CANCELLED : the supervisor can cancel the task whenever he/she see it no need to be fixed any more.
Besides, we can see that there are two loops in the workflow above. Those loops happen when it happens the confliction or disagreement between responsible and supervisor. Specificly, supervisor can reject responsible rejection to get the task status back to NEED ACCEPTANCE, or when the issue does neither working properly nor causing another issue after fixing, he/she will disapprove which get the task back to IN PROGRESS.
EXECUTIVE ACTIONS AND VALIDATIONS
The task status is changed when a manipulating action is executed. According to the workflow above, we can seethere are 7 actions whose names are clear to understand what they are. However, a question comes out. Who can do that? Is there any constraint on executing?
First at all, who can do that? The people can do that could be the responsibles or supervisors or observers which are considered basing on resource access. So instead of saying observer with a specific permission, I will use a minimium specific permission. And here is the range of who
- Responsible
- Supervisor
- Administrator (Full control)
- Manager (Write only)
- Observer (Read only)
- ACCEPT
- REJECT
- REJECT REJECTION
- DONE (SET COMPLETE)
- APPROVE/DISAPPROVE
- CANCEL
