UI for editing workflow

[Gervase Markham]

Benton, Kevin wrote:
> I think that taking it a bit further might be even better.  Offering
> users the ability to configure which statuses are possible versus those
> that are not really helps.  I think that we're missing the ability to
> configure which statuses are open versus those that are closed. 

We do need this ability, but I think it is a function of the status 
itself, and so would be configured in the same UI where you create and 
remove statuses (rather than the one where you express their 
relationships). I imagine this UI will end up being very like the field 
editing UI we have now.

> For 3.2, I think we ought to rename Resolution to Sub_Status or Reason,
> then add a substatus table that includes the list of statuses and
> possible sub-statuses.  

Basically, you are asking for status-dependent resolutions. I haven't 
seen any demand for this elsewhere...

> This is critical when processes allow a DEFERRED
> or PENDING status of sorts.  For process management, it's important to
> know why something is deferred, not just that it's deferred.  

Except that we killed REMIND and LATER because they sucked. IMO, the 
ideas of DEFERRED or PENDING should be implemented in a workflow using 
milestones. Right tool for the right job.

Gerv