Re: Task (WorkEffort) Statuses

[David E Jones]

-David


On Dec 13, 2007, at 9:06 AM, Jim Barrows wrote:

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.

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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
À : <dev@ofbiz.apache.org>
Envoyé : mercredi 12 décembre 2007 11:50
Objet : Task (WorkEffort) Statuses

https://issues.apache.org/jira/browse/OFBIZ-1509


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

take into account that certain statuses don't have to be used, and

things like SECA services can check constraints of course.


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)


roles or statuses (ie steps in the process)?

-David

Hans has started an effort to expand/refine task statuses in this issue: I think this is complex enough that a mailing list discussion might be anyone might need or want for a task. The status transitions can then those can of course be added or removed during customization, or other Here's a pass at this (based on the current set of statuses, and some That's a fairly quick first pass... anyone have any thoughts on other

--
James A Barrows

smime.p7s
Description: S/MIME cryptographic signature