Re: Workflow (was Re: [cvs] commit: ...)

This sounds awesome.  The object serialization looks sweet and would 
really allow people to 'fit' Whups to their needs.

That was the main issue we had with existing systems - their workflow 
was either non existant or fairly rigid.  While whups doesn't have much 
in place now - the nature of its code made it clear that we could add it 
later as needed - but this type of setup is even better!

Mike

Robert E. Coyle wrote:

>
> The main difference between a full workflow and Whups as it currently 
> stands
> is the ability to specify state transitions aswell as states.  For 
> example, in
> a bug tracking system you could describe a process where a bug must go 
> through
> a testing state before being marked as resolved by making a transition 
> from
> 'broken' to 'tested', and only then to 'fixed'.  When it's marked as 
> fixed, it
> gets assigned to a QA tester, and only they can move it to 'fixed' (or 
> back to
> broken as the case may be).  This way you can create a very well 
> defined process
> for tracking tickets (whatever they represent in the specific use). 
> You would
> also have to be able to specify actions to take when a user moves a 
> ticket from
> one state to the next.
>
> This is fairly straighforward to represent:
>
>   CREATE TABLE whups_state_transitions (
>       transition_id    INT NOT NULL,     -- for permissions
>       type_id          INT NOT NULL,
>       state_from       INT NOT NULL,
>       state_to         INT NOT NULL,
>       actions          some datatype);
>
> There are a couple of ways to represent the actions - you could keep 
> it simple
> and define a few types of action ('Mail Someone', 'Escalate Ticket' 
> etc), you
> could define some sort of language (I think that's what Gary Weinreb 
> meant with
> Nag / Whups integration in his mail 'new to whups', 4th november). 
> The most
> flexibly way would be to serialise php objects into the database and 
> run them
> when when the transition is used.
>
> The serialised object would only need a simple interface:
>
>     class WhupsAction { /* abc - the actual actions inherit this */
>         function  performAction($ticket_id, $state_from, $state_to);
>         function &getConfigForm($vars);
>     }
>
> Then installations could code whatever actions they need.



-- 
Whups mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]