Task (WorkEffort) Statuses

[David E Jones]

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

[Jacques Le Roux]

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" <[hidden email]>
À : <[hidden email]>
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
>
>

[Jim Barrows]

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 <[hidden email]> 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" <[hidden email]>
> À : <[hidden email]>
> 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

[David E Jones]

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  
> <[hidden email]> 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" <[hidden email]>
>> À : <[hidden email]>
>> 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

[hans_bakker]

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" <[hidden email]>
> À : <[hidden email]>
> 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.

[hans_bakker]

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.

[hans_bakker]

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 <[hidden email]> 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" <[hidden email]>
> > À : <[hidden email]>
> > 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.

[Jacques Le Roux]

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" <[hidden email]>

> 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" <[hidden email]>
> > À : <[hidden email]>
> > 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.
>
>
>

[Jim Barrows]

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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]>
> > > À : <[hidden email]>
> > > 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

[hans_bakker]

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

[Jacques Le Roux]

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" <[hidden email]>

> 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
>

[hans_bakker]

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.