You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by David E Jones <jo...@hotwaxmedia.com> on 2007/12/12 11:50:50 UTC
Task (WorkEffort) Statuses
Hans has started an effort to expand/refine task statuses in this issue:
https://issues.apache.org/jira/browse/OFBIZ-1509
I think this is complex enough that a mailing list discussion might be
helpful.
To define the point of this, as I see it, we're trying to create the
most expansive set of statuses we can, in other all statuses that
anyone might need or want for a task. The status transitions can then
take into account that certain statuses don't have to be used, and
those can of course be added or removed during customization, or other
things like SECA services can check constraints of course.
Here's a pass at this (based on the current set of statuses, and some
ideas from Hans in the aforementioned issue):
Roles:
- client
- analyst (task creator/writer)
- task performer
- peer of performer
Statuses:
- Needs Action (initial status, from task creator/writer (analyst))
- Approved (by client)
- Sent (to task performer)
- Accepted (by performer)
- Completed (by performer)
- Tested (scope of task, by performer or peer of performer)
- Reviewed (in perspective of larger scope that task fits into, by
task creator/writer (analyst))
- Changes Needed (failed to go to Tested or Reviewed)
- Accepted (by client)
- Declined (by performer)
- Delegated (by performer)
- On Hold (by client)
- Cancelled (by client)
That's a fairly quick first pass... anyone have any thoughts on other
roles or statuses (ie steps in the process)?
-David
Re: Task (WorkEffort) Statuses
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Hans,
The date sounds good enough to me (even if maybe not as obvious as a task status, but one have to learn how to use what one needs.
In a sophisticaded UI colors may be used... futur...)
Thanks
Jacques
De : "Hans Bakker" <ma...@antwebsystems.com>
> Hi Jacques,
> Thanks for your interest in this.
> If a task is completed or not, is documented in the actual enddate.
>
> If the performer reports his time (assumed is dayly) it is known the
> task is in progress. Further, from my own experience, it is already
> difficult enough to get people to report their time. With this extra
> status there will be more burdon on them....
>
> are you still sure we need an extra task status here?
>
> Regards,
> Hans
>
> On Thu, 2007-12-13 at 15:12 +0100, Jacques Le Roux wrote:
> > Maybe a new task status
> > - In Progress (by performer)
> > between
> > > - Accepted (by performer)
> > > - Completed (by performer)
> >
> > To note that the work is currently done, not in a wating state.
> >
> > Jacques
> >
> > ----- Message d'origine -----
> > De : "David E Jones" <jo...@hotwaxmedia.com>
> > À : <de...@ofbiz.apache.org>
> > Envoyé : mercredi 12 décembre 2007 11:50
> > Objet : Task (WorkEffort) Statuses
> >
> >
> > >
> > > Hans has started an effort to expand/refine task statuses in this issue:
> > >
> > > https://issues.apache.org/jira/browse/OFBIZ-1509
> > >
> > > I think this is complex enough that a mailing list discussion might be
> > > helpful.
> > >
> > > To define the point of this, as I see it, we're trying to create the
> > > most expansive set of statuses we can, in other all statuses that
> > > anyone might need or want for a task. The status transitions can then
> > > take into account that certain statuses don't have to be used, and
> > > those can of course be added or removed during customization, or other
> > > things like SECA services can check constraints of course.
> > >
> > > Here's a pass at this (based on the current set of statuses, and some
> > > ideas from Hans in the aforementioned issue):
> > >
> > > Roles:
> > > - client
> > > - analyst (task creator/writer)
> > > - task performer
> > > - peer of performer
> > >
> > > Statuses:
> > > - Needs Action (initial status, from task creator/writer (analyst))
> > > - Approved (by client)
> > > - Sent (to task performer)
> > > - Accepted (by performer)
> > > - Completed (by performer)
> > > - Tested (scope of task, by performer or peer of performer)
> > > - Reviewed (in perspective of larger scope that task fits into, by
> > > task creator/writer (analyst))
> > > - Changes Needed (failed to go to Tested or Reviewed)
> > > - Accepted (by client)
> > >
> > > - Declined (by performer)
> > > - Delegated (by performer)
> > > - On Hold (by client)
> > > - Cancelled (by client)
> > >
> > > That's a fairly quick first pass... anyone have any thoughts on other
> > > roles or statuses (ie steps in the process)?
> > >
> > > -David
> > >
> > >
> >
> >
> --
> http://Antwebsystems.com : OFBiz Quality support for competitive rates.
>
>
>
Re: Task (WorkEffort) Statuses
Posted by Hans Bakker <ma...@antwebsystems.com>.
Hi Jacques,
Thanks for your interest in this.
If a task is completed or not, is documented in the actual enddate.
If the performer reports his time (assumed is dayly) it is known the
task is in progress. Further, from my own experience, it is already
difficult enough to get people to report their time. With this extra
status there will be more burdon on them....
are you still sure we need an extra task status here?
Regards,
Hans
On Thu, 2007-12-13 at 15:12 +0100, Jacques Le Roux wrote:
> Maybe a new task status
> - In Progress (by performer)
> between
> > - Accepted (by performer)
> > - Completed (by performer)
>
> To note that the work is currently done, not in a wating state.
>
> Jacques
>
> ----- Message d'origine -----
> De : "David E Jones" <jo...@hotwaxmedia.com>
> À : <de...@ofbiz.apache.org>
> Envoyé : mercredi 12 décembre 2007 11:50
> Objet : Task (WorkEffort) Statuses
>
>
> >
> > Hans has started an effort to expand/refine task statuses in this issue:
> >
> > https://issues.apache.org/jira/browse/OFBIZ-1509
> >
> > I think this is complex enough that a mailing list discussion might be
> > helpful.
> >
> > To define the point of this, as I see it, we're trying to create the
> > most expansive set of statuses we can, in other all statuses that
> > anyone might need or want for a task. The status transitions can then
> > take into account that certain statuses don't have to be used, and
> > those can of course be added or removed during customization, or other
> > things like SECA services can check constraints of course.
> >
> > Here's a pass at this (based on the current set of statuses, and some
> > ideas from Hans in the aforementioned issue):
> >
> > Roles:
> > - client
> > - analyst (task creator/writer)
> > - task performer
> > - peer of performer
> >
> > Statuses:
> > - Needs Action (initial status, from task creator/writer (analyst))
> > - Approved (by client)
> > - Sent (to task performer)
> > - Accepted (by performer)
> > - Completed (by performer)
> > - Tested (scope of task, by performer or peer of performer)
> > - Reviewed (in perspective of larger scope that task fits into, by
> > task creator/writer (analyst))
> > - Changes Needed (failed to go to Tested or Reviewed)
> > - Accepted (by client)
> >
> > - Declined (by performer)
> > - Delegated (by performer)
> > - On Hold (by client)
> > - Cancelled (by client)
> >
> > That's a fairly quick first pass... anyone have any thoughts on other
> > roles or statuses (ie steps in the process)?
> >
> > -David
> >
> >
>
>
--
http://Antwebsystems.com : OFBiz Quality support for competitive rates.
Re: Task (WorkEffort) Statuses
Posted by David E Jones <jo...@hotwaxmedia.com>.
Hans: do you have any thoughts or comments on this? Especially given
that you are the main person working on it now your feedback is very
valuable.
-David
On Dec 13, 2007, at 9:06 AM, Jim Barrows wrote:
> I'll second that.... I'll accept a bug in jira, but won't start on it
> until my current task is done all the time. This tracks that.
> In addition, how about a task state called waiting-on, and a reference
> to who or what the task is waiting on. At the very least, a reference
> to a party, a reference to another task, and a blank field for a
> description. This state should be able to entered into from almost
> any point.
> Thinking about the approval status... it seems to say approval is
> needed by more then one person. In the IT world, sometimes things
> need approved by more then person.
> In a manufacturing shop of a friend of mine, any changes over a
> certain amount need to be approved by him, the supervisor and the
> client. I think maybe the easiest way to handle approvals would be to
> provide an easy entry into the business rules for this task. Course,
> that could be true of any of these!
>
> On Dec 13, 2007 7:12 AM, Jacques Le Roux
> <ja...@les7arts.com> wrote:
>> Maybe a new task status
>> - In Progress (by performer)
>> between
>>> - Accepted (by performer)
>>> - Completed (by performer)
>>
>> To note that the work is currently done, not in a wating state.
>>
>> Jacques
>>
>> ----- Message d'origine -----
>> De : "David E Jones" <jo...@hotwaxmedia.com>
>> À : <de...@ofbiz.apache.org>
>> Envoyé : mercredi 12 décembre 2007 11:50
>> Objet : Task (WorkEffort) Statuses
>>
>>
>>>
>>> Hans has started an effort to expand/refine task statuses in this
>>> issue:
>>>
>>> https://issues.apache.org/jira/browse/OFBIZ-1509
>>>
>>> I think this is complex enough that a mailing list discussion
>>> might be
>>> helpful.
>>>
>>> To define the point of this, as I see it, we're trying to create the
>>> most expansive set of statuses we can, in other all statuses that
>>> anyone might need or want for a task. The status transitions can
>>> then
>>> take into account that certain statuses don't have to be used, and
>>> those can of course be added or removed during customization, or
>>> other
>>> things like SECA services can check constraints of course.
>>>
>>> Here's a pass at this (based on the current set of statuses, and
>>> some
>>> ideas from Hans in the aforementioned issue):
>>>
>>> Roles:
>>> - client
>>> - analyst (task creator/writer)
>>> - task performer
>>> - peer of performer
>>>
>>> Statuses:
>>> - Needs Action (initial status, from task creator/writer (analyst))
>>> - Approved (by client)
>>> - Sent (to task performer)
>>> - Accepted (by performer)
>>> - Completed (by performer)
>>> - Tested (scope of task, by performer or peer of performer)
>>> - Reviewed (in perspective of larger scope that task fits into, by
>>> task creator/writer (analyst))
>>> - Changes Needed (failed to go to Tested or Reviewed)
>>> - Accepted (by client)
>>>
>>> - Declined (by performer)
>>> - Delegated (by performer)
>>> - On Hold (by client)
>>> - Cancelled (by client)
>>>
>>> That's a fairly quick first pass... anyone have any thoughts on
>>> other
>>> roles or statuses (ie steps in the process)?
>>>
>>> -David
>>>
>>>
>>
>>
>
>
>
> --
> James A Barrows
Re: Task (WorkEffort) Statuses, any further comments?
Posted by Hans Bakker <ma...@antwebsystems.com>.
Can I ask the community to check the last project Task status proposal?
If there are no further comments i will implement the proposal below in
a couple of days in the special component 'project manager'
The final proposal about the project task status was:
The status on a task is largely system controlled (1-4) and user controlled (5-6):
----------------------------------------------------------------------------------
1: unassigned -> the task has no performers and has not started.
2: assigned -> the task has one or more performers but has still not started
3. in-progress -> at least one performer has registered, the task is started
time on the task
4. completed -> all attached performers have set their assign
status to completed
5. onHold -> the projectmanager can set this status and
can be set back to status 1-3
6. cancelled -> again can be set by the projectmanager
The status of the assignment of a party to the task is manual
controlled:
-------------------------------------------------------------
1. assigned -> the task is assigned to the party with
from/thru dates to show when active
2. completed -> the party has done his part (work,approval,
test etc) on the task and has indicated he is ready.
--
http://Antwebsystems.com : OFBiz Quality support for competitive rates.
Re: Task (WorkEffort) Statuses, another view
Posted by Jacques Le Roux <ja...@les7arts.com>.
I like it, though maybe I would prefer labelling onHold to reviewing.
No end task status (resolved, closed)? Is it managed at the project or phase level ?
Jacques
De : "Hans Bakker" <ma...@antwebsystems.com>
> I thought more about it and like to present a different approach for the
> status on a task.
>
> To allow for many approval authorities:
> Anybody who need to approve the task will be a performer with a
> appropriate roleTypeId
>
> the status on a task is largely system controlled (1-4):
>
> 1: unassigned -> the task has no performers
> 2: assigned -> the task has one or more performers
> 3. in-progress -> at least one performer has registered
> time on the task
> 4. completed -> all attached performers have set their
> status to completed
> 5. onHold -> the projectmanager can set this status and
> can be set back to status 1-3
> 6. cancelled -> again can be set by the projectmanager
>
> Internally in the system the status is as follows:
> 1. created (further specified by the system as stated above)
> 2. completed
> 3. cancelled
> 4. onhold
>
> what is the opinion of the community?
>
> Regards,
> Hans
>
Re: Task (WorkEffort) Statuses, another view
Posted by Hans Bakker <ma...@antwebsystems.com>.
I thought more about it and like to present a different approach for the
status on a task.
To allow for many approval authorities:
Anybody who need to approve the task will be a performer with a
appropriate roleTypeId
the status on a task is largely system controlled (1-4):
1: unassigned -> the task has no performers
2: assigned -> the task has one or more performers
3. in-progress -> at least one performer has registered
time on the task
4. completed -> all attached performers have set their
status to completed
5. onHold -> the projectmanager can set this status and
can be set back to status 1-3
6. cancelled -> again can be set by the projectmanager
Internally in the system the status is as follows:
1. created (further specified by the system as stated above)
2. completed
3. cancelled
4. onhold
what is the opinion of the community?
Regards,
Hans
Re: Task (WorkEffort) Statuses
Posted by Jim Barrows <ji...@gmail.com>.
Ok, then as a manager, I need to rebalance the tasks. How do I as the
system what is not being worked on? Just ask for tasks that don't
have a time record, and been accepted? That could work, but the state
I think works better.
I was thinking, as soon as someone enters time, comments etc, you just
auto move the task to in-process/working-on state. Not something
that's an extra step.
I can see having more then 2 approvals very easily, as I pointed out.
On Dec 14, 2007 12:03 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
> Hi Jim,
>
> Thanks for your reply, can you please also read my reply to Jacques?
> Remember we now have two status values:
> 1. for the assignment of a single person
> 2. for the overall task.
>
> We could send a warning on a task which is over the latest start date
> (the planned end date - the planned required days) I am not sure why we
> need to have a manual flag for this.
>
> About the approval I agree we surely need at least 2 approvals, one by
> the provider and one by the client. Remember the implementor has his own
> status.
>
> for me we need the current 2 status values:
> 1. I think accepted/completed is enough for the implementer
> 2. the task status, please read that in my reply to Davids's request
>
>
> Regards, Hans
>
>
>
>
> On Thu, 2007-12-13 at 09:06 -0700, Jim Barrows wrote:
> > I'll second that.... I'll accept a bug in jira, but won't start on it
> > until my current task is done all the time. This tracks that.
> > In addition, how about a task state called waiting-on, and a reference
> > to who or what the task is waiting on. At the very least, a reference
> > to a party, a reference to another task, and a blank field for a
> > description. This state should be able to entered into from almost
> > any point.
> > Thinking about the approval status... it seems to say approval is
> > needed by more then one person. In the IT world, sometimes things
> > need approved by more then person.
> > In a manufacturing shop of a friend of mine, any changes over a
> > certain amount need to be approved by him, the supervisor and the
> > client. I think maybe the easiest way to handle approvals would be to
> > provide an easy entry into the business rules for this task. Course,
> > that could be true of any of these!
> >
> > On Dec 13, 2007 7:12 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
> > > Maybe a new task status
> > > - In Progress (by performer)
> > > between
> > > > - Accepted (by performer)
> > > > - Completed (by performer)
> > >
> > > To note that the work is currently done, not in a wating state.
> > >
> > > Jacques
> > >
> > > ----- Message d'origine -----
> > > De : "David E Jones" <jo...@hotwaxmedia.com>
> > > À : <de...@ofbiz.apache.org>
> > > Envoyé : mercredi 12 décembre 2007 11:50
> > > Objet : Task (WorkEffort) Statuses
> > >
> > >
> > > >
>
> > > > Hans has started an effort to expand/refine task statuses in this issue:
> > > >
> > > > https://issues.apache.org/jira/browse/OFBIZ-1509
> > > >
> > > > I think this is complex enough that a mailing list discussion might be
> > > > helpful.
> > > >
> > > > To define the point of this, as I see it, we're trying to create the
> > > > most expansive set of statuses we can, in other all statuses that
> > > > anyone might need or want for a task. The status transitions can then
> > > > take into account that certain statuses don't have to be used, and
> > > > those can of course be added or removed during customization, or other
> > > > things like SECA services can check constraints of course.
> > > >
> > > > Here's a pass at this (based on the current set of statuses, and some
> > > > ideas from Hans in the aforementioned issue):
> > > >
> > > > Roles:
> > > > - client
> > > > - analyst (task creator/writer)
> > > > - task performer
> > > > - peer of performer
> > > >
> > > > Statuses:
> > > > - Needs Action (initial status, from task creator/writer (analyst))
> > > > - Approved (by client)
> > > > - Sent (to task performer)
> > > > - Accepted (by performer)
> > > > - Completed (by performer)
> > > > - Tested (scope of task, by performer or peer of performer)
> > > > - Reviewed (in perspective of larger scope that task fits into, by
> > > > task creator/writer (analyst))
> > > > - Changes Needed (failed to go to Tested or Reviewed)
> > > > - Accepted (by client)
> > > >
> > > > - Declined (by performer)
> > > > - Delegated (by performer)
> > > > - On Hold (by client)
> > > > - Cancelled (by client)
> > > >
> > > > That's a fairly quick first pass... anyone have any thoughts on other
> > > > roles or statuses (ie steps in the process)?
> > > >
> > > > -David
> > > >
> > > >
> > >
> > >
> >
> >
> >
> --
> http://Antwebsystems.com : OFBiz Quality support for competitive rates.
>
>
>
>
--
James A Barrows
Re: Task (WorkEffort) Statuses
Posted by Hans Bakker <ma...@antwebsystems.com>.
Hi Jim,
Thanks for your reply, can you please also read my reply to Jacques?
Remember we now have two status values:
1. for the assignment of a single person
2. for the overall task.
We could send a warning on a task which is over the latest start date
(the planned end date - the planned required days) I am not sure why we
need to have a manual flag for this.
About the approval I agree we surely need at least 2 approvals, one by
the provider and one by the client. Remember the implementor has his own
status.
for me we need the current 2 status values:
1. I think accepted/completed is enough for the implementer
2. the task status, please read that in my reply to Davids's request
Regards, Hans
On Thu, 2007-12-13 at 09:06 -0700, Jim Barrows wrote:
> I'll second that.... I'll accept a bug in jira, but won't start on it
> until my current task is done all the time. This tracks that.
> In addition, how about a task state called waiting-on, and a reference
> to who or what the task is waiting on. At the very least, a reference
> to a party, a reference to another task, and a blank field for a
> description. This state should be able to entered into from almost
> any point.
> Thinking about the approval status... it seems to say approval is
> needed by more then one person. In the IT world, sometimes things
> need approved by more then person.
> In a manufacturing shop of a friend of mine, any changes over a
> certain amount need to be approved by him, the supervisor and the
> client. I think maybe the easiest way to handle approvals would be to
> provide an easy entry into the business rules for this task. Course,
> that could be true of any of these!
>
> On Dec 13, 2007 7:12 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
> > Maybe a new task status
> > - In Progress (by performer)
> > between
> > > - Accepted (by performer)
> > > - Completed (by performer)
> >
> > To note that the work is currently done, not in a wating state.
> >
> > Jacques
> >
> > ----- Message d'origine -----
> > De : "David E Jones" <jo...@hotwaxmedia.com>
> > À : <de...@ofbiz.apache.org>
> > Envoyé : mercredi 12 décembre 2007 11:50
> > Objet : Task (WorkEffort) Statuses
> >
> >
> > >
> > > Hans has started an effort to expand/refine task statuses in this issue:
> > >
> > > https://issues.apache.org/jira/browse/OFBIZ-1509
> > >
> > > I think this is complex enough that a mailing list discussion might be
> > > helpful.
> > >
> > > To define the point of this, as I see it, we're trying to create the
> > > most expansive set of statuses we can, in other all statuses that
> > > anyone might need or want for a task. The status transitions can then
> > > take into account that certain statuses don't have to be used, and
> > > those can of course be added or removed during customization, or other
> > > things like SECA services can check constraints of course.
> > >
> > > Here's a pass at this (based on the current set of statuses, and some
> > > ideas from Hans in the aforementioned issue):
> > >
> > > Roles:
> > > - client
> > > - analyst (task creator/writer)
> > > - task performer
> > > - peer of performer
> > >
> > > Statuses:
> > > - Needs Action (initial status, from task creator/writer (analyst))
> > > - Approved (by client)
> > > - Sent (to task performer)
> > > - Accepted (by performer)
> > > - Completed (by performer)
> > > - Tested (scope of task, by performer or peer of performer)
> > > - Reviewed (in perspective of larger scope that task fits into, by
> > > task creator/writer (analyst))
> > > - Changes Needed (failed to go to Tested or Reviewed)
> > > - Accepted (by client)
> > >
> > > - Declined (by performer)
> > > - Delegated (by performer)
> > > - On Hold (by client)
> > > - Cancelled (by client)
> > >
> > > That's a fairly quick first pass... anyone have any thoughts on other
> > > roles or statuses (ie steps in the process)?
> > >
> > > -David
> > >
> > >
> >
> >
>
>
>
--
http://Antwebsystems.com : OFBiz Quality support for competitive rates.
Re: Task (WorkEffort) Statuses
Posted by Jim Barrows <ji...@gmail.com>.
I'll second that.... I'll accept a bug in jira, but won't start on it
until my current task is done all the time. This tracks that.
In addition, how about a task state called waiting-on, and a reference
to who or what the task is waiting on. At the very least, a reference
to a party, a reference to another task, and a blank field for a
description. This state should be able to entered into from almost
any point.
Thinking about the approval status... it seems to say approval is
needed by more then one person. In the IT world, sometimes things
need approved by more then person.
In a manufacturing shop of a friend of mine, any changes over a
certain amount need to be approved by him, the supervisor and the
client. I think maybe the easiest way to handle approvals would be to
provide an easy entry into the business rules for this task. Course,
that could be true of any of these!
On Dec 13, 2007 7:12 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
> Maybe a new task status
> - In Progress (by performer)
> between
> > - Accepted (by performer)
> > - Completed (by performer)
>
> To note that the work is currently done, not in a wating state.
>
> Jacques
>
> ----- Message d'origine -----
> De : "David E Jones" <jo...@hotwaxmedia.com>
> À : <de...@ofbiz.apache.org>
> Envoyé : mercredi 12 décembre 2007 11:50
> Objet : Task (WorkEffort) Statuses
>
>
> >
> > Hans has started an effort to expand/refine task statuses in this issue:
> >
> > https://issues.apache.org/jira/browse/OFBIZ-1509
> >
> > I think this is complex enough that a mailing list discussion might be
> > helpful.
> >
> > To define the point of this, as I see it, we're trying to create the
> > most expansive set of statuses we can, in other all statuses that
> > anyone might need or want for a task. The status transitions can then
> > take into account that certain statuses don't have to be used, and
> > those can of course be added or removed during customization, or other
> > things like SECA services can check constraints of course.
> >
> > Here's a pass at this (based on the current set of statuses, and some
> > ideas from Hans in the aforementioned issue):
> >
> > Roles:
> > - client
> > - analyst (task creator/writer)
> > - task performer
> > - peer of performer
> >
> > Statuses:
> > - Needs Action (initial status, from task creator/writer (analyst))
> > - Approved (by client)
> > - Sent (to task performer)
> > - Accepted (by performer)
> > - Completed (by performer)
> > - Tested (scope of task, by performer or peer of performer)
> > - Reviewed (in perspective of larger scope that task fits into, by
> > task creator/writer (analyst))
> > - Changes Needed (failed to go to Tested or Reviewed)
> > - Accepted (by client)
> >
> > - Declined (by performer)
> > - Delegated (by performer)
> > - On Hold (by client)
> > - Cancelled (by client)
> >
> > That's a fairly quick first pass... anyone have any thoughts on other
> > roles or statuses (ie steps in the process)?
> >
> > -David
> >
> >
>
>
--
James A Barrows
Re: Task (WorkEffort) Statuses
Posted by Jacques Le Roux <ja...@les7arts.com>.
Maybe a new task status
- In Progress (by performer)
between
> - Accepted (by performer)
> - Completed (by performer)
To note that the work is currently done, not in a wating state.
Jacques
----- Message d'origine -----
De : "David E Jones" <jo...@hotwaxmedia.com>
À : <de...@ofbiz.apache.org>
Envoyé : mercredi 12 décembre 2007 11:50
Objet : Task (WorkEffort) Statuses
>
> Hans has started an effort to expand/refine task statuses in this issue:
>
> https://issues.apache.org/jira/browse/OFBIZ-1509
>
> I think this is complex enough that a mailing list discussion might be
> helpful.
>
> To define the point of this, as I see it, we're trying to create the
> most expansive set of statuses we can, in other all statuses that
> anyone might need or want for a task. The status transitions can then
> take into account that certain statuses don't have to be used, and
> those can of course be added or removed during customization, or other
> things like SECA services can check constraints of course.
>
> Here's a pass at this (based on the current set of statuses, and some
> ideas from Hans in the aforementioned issue):
>
> Roles:
> - client
> - analyst (task creator/writer)
> - task performer
> - peer of performer
>
> Statuses:
> - Needs Action (initial status, from task creator/writer (analyst))
> - Approved (by client)
> - Sent (to task performer)
> - Accepted (by performer)
> - Completed (by performer)
> - Tested (scope of task, by performer or peer of performer)
> - Reviewed (in perspective of larger scope that task fits into, by
> task creator/writer (analyst))
> - Changes Needed (failed to go to Tested or Reviewed)
> - Accepted (by client)
>
> - Declined (by performer)
> - Delegated (by performer)
> - On Hold (by client)
> - Cancelled (by client)
>
> That's a fairly quick first pass... anyone have any thoughts on other
> roles or statuses (ie steps in the process)?
>
> -David
>
>
Re: Task (WorkEffort) Statuses
Posted by Hans Bakker <ma...@antwebsystems.com>.
Hi David,
I waited a little on my comment because they were already known in the
related Jira Issue. I see however some good points in the others so i
changed my point of view.
first comments on your proposal:
isn't 2 statuses for a performer enough? 1. Received/Completed?
if a task is received, the performer can start on the job, or can reject
it by deleting the assignment or assign it to another person. Even
halfway the task, it can be reassigned and can later return to this same
person. Reporting can be used to see if tasks are over their latest
startdate with not enough or no assignments.
Is client approval before the task can start required? Isn't it so that
tasks are only in a project if the client has approved the initial
customer request or the total project before the start?
As mentioned to a mail to Jacques we need 2 approvals:
1. from the provider tester
2. from the client.
so for me i would like to suggest:
-------------------------------
performer status:
1. accepted
2. completed
task status:
1. created
2. reviewed(provider) (when all performers are completed)
3. completed(client)
4. onhold
5. cancelled
Regards,
Hans
On Wed, 2007-12-12 at 03:50 -0700, David E Jones wrote:
> Hans has started an effort to expand/refine task statuses in this issue:
>
> https://issues.apache.org/jira/browse/OFBIZ-1509
>
> I think this is complex enough that a mailing list discussion might be
> helpful.
>
> To define the point of this, as I see it, we're trying to create the
> most expansive set of statuses we can, in other all statuses that
> anyone might need or want for a task. The status transitions can then
> take into account that certain statuses don't have to be used, and
> those can of course be added or removed during customization, or other
> things like SECA services can check constraints of course.
>
> Here's a pass at this (based on the current set of statuses, and some
> ideas from Hans in the aforementioned issue):
>
> Roles:
> - client
> - analyst (task creator/writer)
> - task performer
> - peer of performer
>
> Statuses:
> - Needs Action (initial status, from task creator/writer (analyst))
> - Approved (by client)
> - Sent (to task performer)
> - Accepted (by performer)
> - Completed (by performer)
> - Tested (scope of task, by performer or peer of performer)
> - Reviewed (in perspective of larger scope that task fits into, by
> task creator/writer (analyst))
> - Changes Needed (failed to go to Tested or Reviewed)
> - Accepted (by client)
>
> - Declined (by performer)
> - Delegated (by performer)
> - On Hold (by client)
> - Cancelled (by client)
>
> That's a fairly quick first pass... anyone have any thoughts on other
> roles or statuses (ie steps in the process)?
>
> -David
>
--
http://Antwebsystems.com : OFBiz Quality support for competitive rates.