[rt-users] Request for comments: Configurable Status

[Kelly D. Lucas]

I'm very new to the system, and not a Perl developer, nor do I want to 
be. So, there is a developer on my staff, but his opinion is the less 
programming we do, the better the system will be for us.  The 2 main 
reasons, which I think are obvious:

    * Time to deploy
    * Less risk involved

 From my perspective, the less amount of time we spend setting up the 
system, the better. Also, the more changes we implement at a code level, 
the greater chance we have of breaking the system. Especially when we 
upgrade or patch modules, etc.

With the above disposition, I favor some sort of menu under Config, that 
would allow the following functionality:

    * Add or remove status
    * OR
    * Add or remove a user defined status [I'll call it ticket state],
      and tie it to the logic flow of the ticket

If I could have it per queue, it is the most useful, as our organization 
is looking at using it in this way:

1) Tickets can be generated by a number of groups within [and later, 
maybe outside the company] for the purpose of issue tracking
2) The owner of the ticket may exchange hands numerous times, depending 
on if the issue is related to:

    * demo/installation [Sales Engineers]
    * system configuration [tech support]
    * enhancements or tech data [prod mgt]
    * bugs [dev/SQL]

3) So obviously there will be states like fixed, verified, that there 
won't be for the demo/installation issues. And in product marketing, 
they will have states regarding feature enhancements that other groups 
will not have.

So, with the above in mind, I'm not sure how to best implement it, not 
knowing the code internals, but this would be my goal. I'm also planning 
to have a custom field for:

    * issue category
    * issue severity
    * issue priority [probably 5 priorities]
    * product
    * product version
    * product serial number
    * customer and all customer contact info

So, in this system, we'll be able to capture the history of:

    * specific customers
    * specific products [by tracking serial numbers]
    * product versions
    * where most of our time is spent based on products, categories, or
      customers
    * and this will give our sales dept the ability to look in and see
      where issues are with their accounts

So, having said all this, do you think my plans are too all encompassing 
for RT?

Any comments welcomed.

kdl

K.D. Lucas
lucaskeli at fastmail.fm



Jesse wrote:

>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?
>
>
>	Best,
>	Jesse
>
>
>  
>