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 <[EMAIL PROTECTED]> 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 <[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. > > > > -- James A Barrows
