LShift Ltd.

Trac custom workflow

January 9th, 2008 david

I’ve been experimenting with Trac’s new customisable work-flow. This hasn’t made it into a stable release yet - I’m using the trunk source. Hopefully Trac 0.11 is not far away. The first beta has been released.

It looks very promising: plug-ins may return lists of actions they allow, given the current state of the ticket. Actions can render their own controls, so they can include inputs to be entered when the user selects the action. There is also a default work-flow plug-in which allows you to specify a state graph in trac.ini. It’s even possible to compose multiple work-flow plug-ins - all the actions offered by each plug-in are displayed to the user. The default work-flow plug-in can be queried for information about its configuration.

On the down side - it seems essential for the work-flow plug-ins to use fields in the ticket the user can’t edit. Trac does this itself - you can’t directly edit ’status’, ‘owner’ or ‘resolution’. A hack is just to create a plugin that protects a list of fields from being changed, but the user must discover by trial and error what can and can’t be edited. There is also no way for an action to reject input from its own controls.

I’ve started using Trac on a collaborative project with a client. We normally use bugzilla, so we are used to having a separate QA contact, and having Bugzilla track the functional QA process. We use flags for peer QA, but Trac could handle this with work-flow as well, and that would be desirable.

So far, I can’t quite get this to the point where it’s sufficiently user friendly for its intended audience. Hopefully it won’t be long before I can.

You can find out more about Trac here, and more specifically about the upcoming release here.

Entry Filed under: Technology