Like Gene, we use a CF for this, but also created some new Ticket
Status values to work in conjunction as well. Our process goes something
1) New ticket created; automatically set CF "Work-Status" value to
2) New ticket is reviewed; we change the Ticket Status to ‘pending rv’
and automatically set the CF “Work-Status” value to “Investigating Request”.
3) New ticket is approved; we change the Ticket Status to ‘rq approvd’
and automatically set the CF “Work-Status” value to “Estimating Effort”.
4) New ticket is opened for work; we change the Ticket Status value to
’open’ and automatically set the CF “Work-Status” value to “Developing
5) Ticket is worked on, goes thru several developing steps; ticket
owner is responsible to change the CF “Work-Status” to a value the
describes the step (like “Coding” or “Unit Testing” or “Sysytem Testing”).
6) Ticket is ready for QA/User Acceptance Testing; we change the TIcket
Status value to ‘pending qa’ and automatically set the CF "Work-Status"
value to “Acceptance Testing”.
7) Ticket passes QA testing; we change the Ticket Status to ‘qa
approvd’ and automatically set the CF “Work-Status” value to “Ready to
8) Ticket is promoted to production; we change the Ticket Status to
’resolved’ and automatically set the CF “Work-Status” value to “Closed”.
Now, all of this entails some work to add some new status value for
Ticket Status. This, of course, means changing some default queries and
setting up some scrips & templates to handle the automatic changes to
the CF values as well as sending out the kind of notificatione we want.
But it is all doable.
I suppose that if you did NOT want to have another Custom Field, then
just add all the new steps as new values to the Ticket Status. This is
very doable, will keep the CF number down and you can even create some
"quick links" on the right of the ticket tab (like “Review”, “Approve”,
“QA Ready”, etc. to act just like “Open” and “Resolve” that you
Either way, you’re gonna have to make some changes. I have all these
kind of changes document for our installation, but I learned it all from
the RT wiki for extensions and here on the list. I got a lot of help
with the scrips and templates from Gene, Stephan, Mike, Ruslan and a few
If what I have said here sounds like a way you want to proceed, let me
know and I’ll try to set up a set of steps & instructions for you to
follow and would be more than willing to work with you on it. Let me know.
LBNLOn 8/25/2008 8:19 AM, Jerrad Pierce wrote:
On Mon, Aug 25, 2008 at 10:59, Roedel, Mark <MarkRoedel@letu.edu mailto:MarkRoedel@letu.edu> wrote:
Have you looked at creating a list of "Reminders" in the ticket? We
use them as a way of creating a checklist to track multi-task
processes (for example, all the things that need to be done to
activate a new employee ï¿½ various system accounts, long distance
calling PIN, etc.) within a single ticket.
But the phases are of indeterminate length and also, consequently, have
This would also probably clash with RTx::Calendar if I, or anyone else
is ever able to get it
(or similar functionality) working in 3.8?
Cambridge Energy Alliance: Save money & the planet
Community help: http://wiki.bestpractical.com
Commercial support: firstname.lastname@example.org
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com