[rt-users] Adding more status types

[ann at drop.2organize.com]

Michael wrote:

> I know I've said this before, but if you feel a need to change the
> statuses, I would strongly suggest reconsidering a more RT like way of
> solving your work flow. There are no API guarantees for statuses which
> means that your custom statuses can break at any point with an upgrade.

I agree with Michael here, for what it's worth.  We needed slightly
more fine-grained control, to indicate whether a ticket was waiting
for client input, in testing, ready to put live, etc--all of which
fall under the 'open' status.

I actually did go to the code and add the additional states, but
decided not to apply the patch to the live server because it looked
as if it had the potential to make upgrades painful.

In the end, our solution was to add a custom field, 'phase', which
holds the additional values.  I then modified the template so that you
always see the phase in addition to the status, if it is present.

It actually turned out that this model more accurately represents
how we think about the tickets than additional status entries would,
because for status it is always a progression from new to resolved,
whereas the phase can bounce between different states.

Anyhow, this is just another suggestion on how the different states
could be handled.

- Ann