Message: 5
Date: Wed, 23 Jun 2004 17:08:32 -0400
From: Jesse jesse@bestpractical.com
Subject: [rt-users] Request for comments: Configurable Status
To: rt-users@lists.bestpractical.com
Message-ID: 20040623210832.GF20975@pallas.eruditorum.org
Content-Type: text/plain; charset=us-asciiIn 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?Best,
Jesse
Custom Status messages IMHO is a nice to have. Almost any business processes can be adapted to fit into the categories available. Indeed, we have used them to help define and streamline the workflow which was in danger of drowning under its own weight. The restricted choices have crystalised the whole procedure from receipt to closure of a ticket.
The ability to add a limited number to the default ones may well appeal to a new audience, but adding more complex processes to the back end of Status may just make it even more difficult for non Perl people to understand and potentially scare off those same new auudiences.
Rik