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 <[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 > > > > > > > > > > > > > -- http://Antwebsystems.com : OFBiz Quality support for competitive rates.
