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.
