[rt-users] Request for comments: Configurable Status
Kelly D. Lucas
lucaskeli at fastmail.fm
Thu Jun 24 09:31:53 EDT 2004
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
>
>
>
>
More information about the rt-users
mailing list