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

From: "Chuck Hagenbuch" <[email protected]>

> Hi Robert! Good to "see you" again. Are you back to having a little time to
> spend on Whups, and using it? Any comments on where things have been going
> lately?

Hi Chuck,

Yes, I'm using it currently to track implementation progress and bugs of a
couple of projects.  It's looking pretty sharp these days - I like the admin
and reports pages a lot.

As for the current direction - Workflow is the logical extension of Whups.

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.

For automatic escalation of tickets (Gary Weinreb also mentioned this), you'd
need a cron job running.  This would be fairly simple to implement.


Anyway - this is just an idea for implementing it.  There are more pressing
things that need to be done to make it work as a bug tracking system first.
Workflow is, in my view, much further down the line.


Rob.

--
10: Sin
20: Goto Hell
  - From the Futurama Robot Church




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