[rt-users] Request for comments: Configurable Status

[ann at drop.2organize.com]

> In the traditional RT model, the "Status" field is a simple, limited
> list of possible states that a ticket can be in. Roughly: untouched,
> active, temporarily inactive, permanently inactive.  For more advanced
> workflow, we've recommended that users create custom fields or use
> multiple queues to represent different workflow stages.  Of late,
> there's been an upswing in the number of users who would rather simply
> modify the existing "status" field.
>
> Would a simple editable per-queue ordered list of possible statuses
> (stati?) be sufficient for your needs?  Do you need to control which
> status transitions are allowed? Do you need to be able to lock down
> certain statuses such that they're only selectable by specific users?

My opinion:

I think my users would be happy even without queue-based status fields.
They already agreed to the list that we use for status fields, and these
are used by all queues even though the list is not a perfect match for
all queues.

So, a queue-based list of possibilities would be sufficient.

I like the fact that the existing values are also grouped in to
categories, and that these categories can be used to determine the
display.  I would prefer that the groups be retained so that I could
modify templates to display depending upon groups, instead of hardcoding
status values in the templates.

For controling which are allowed, or enforcing a certain order, I would
expect to use custom code, although it would be nice to have an example
of how to do this.

I don't need to restrict values to certain people beyond the existing
'delete' restriction, but I can see how some people would.  I suspect
there would be the tempatation to roll 'approval' in to this section
(that's certainly our workflow--someone makes a new request, project
manager must appre, developer starts request, project manager tests,
project manager states change can go live, developer puts it live,
project manager checks and resolves request).

- Ann