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