[rt-users] Design/usage question

Kenneth Crocker KFCrocker at lbl.gov
Mon Aug 25 13:42:41 EDT 2008


Jerrad,


	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 
like this:

	1) New ticket created; automatically set CF "Work-Status" value to 
"Requested".
	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 
Specs".
	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 
Promote/Migrate".
	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 
currently see).
	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 
others.
	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.


Kenn
LBNL

On 8/25/2008 8:19 AM, Jerrad Pierce wrote:
> On Mon, Aug 25, 2008 at 10:59, Roedel, Mark <MarkRoedel at letu.edu 
> <mailto:MarkRoedel at 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 
> no date.
> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
> 
> 
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
> Buy a copy at http://rtbook.bestpractical.com




More information about the rt-users mailing list