Design/usage question

I have users who want to use RT to track an elaborate multi-step process,
namely to
determine how far-along individual projects are. Does anyone have any
experience with this,
or recommendations for doing so?

The original idea was for the creation of a ticket in the queue to spawn the
creation of child
tickets for every step in the process. I fear this will be rather
cumbersome, and may result
in correspondence being spread across far too may tickets.

I’ve since been considering a (multi)select CF, but it seems like it’d be
rather easy to ignore,
and we already have over two dozen CF on these tickets.

Custom states are another possiblity, but there are 12 steps, and that seems
extremely unweildy.

Thanks in advance,

Jerrad
Cambridge Energy Alliance: Save money & the planet

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.

Mark Roedel

Senior Programmer/Analyst - Web Services

LeTourneau UniversityFrom: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Jerrad
Pierce
Sent: Sunday, August 24, 2008 9:48 PM
To: RT Users
Subject: [rt-users] Design/usage question

I have users who want to use RT to track an elaborate multi-step
process, namely to
determine how far-along individual projects are. Does anyone have any
experience with this,
or recommendations for doing so?

The original idea was for the creation of a ticket in the queue to spawn
the creation of child
tickets for every step in the process. I fear this will be rather
cumbersome, and may result
in correspondence being spread across far too may tickets.

I’ve since been considering a (multi)select CF, but it seems like it’d
be rather easy to ignore,
and we already have over two dozen CF on these tickets.

Custom states are another possiblity, but there are 12 steps, and that
seems extremely unweildy.

Thanks in advance,

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

Hi Jerrad,

I used a custom field to emulate custom states for a process that required
a ticket to change queues several times. A certain request comes in to the
security office and they create a ticket in their queue. A scrip
immediately moves the ticket into the network queue where it prompts the
techs to kill the user’s network connection. They do so and record their
action, which causes the ticket to return to the security queue and stall
itself. User notices that he is no longer on the network so he starts
calling around and eventually ends up talking to security. Security sends
him a letter and updates the ticket, the ticket stays stalled. When user
signs and returns the letter, security notes it and the ticket goes back to
the network queue where the techs are prompted to restore the
connection. They do so and record the action, which causes the ticket to
return to the security queue where it sits until security reviews it and
marks it resolved. At each step the custom field gets changed by a person,
a scrip, or a template, and this change triggers the next action. It’s
clunky, but it works well for us.

It may not be the best answer for your situation, but it is something to
consider. We are using 3.6.3, so there might be better ways to do this in
3.8 that I don’t know about.

Regards,
Gene

At 07:47 PM 8/24/2008, Jerrad Pierce wrote:

I have users who want to use RT to track an elaborate multi-step process,
namely to
determine how far-along individual projects are. Does anyone have any
experience with this,
or recommendations for doing so?

The original idea was for the creation of a ticket in the queue to spawn
the creation of child
tickets for every step in the process. I fear this will be rather
cumbersome, and may result
in correspondence being spread across far too may tickets.

I’ve since been considering a (multi)select CF, but it seems like it’d be
rather easy to ignore,
and we already have over two dozen CF on these tickets.

Custom states are another possiblity, but there are 12 steps, and that
seems extremely unweildy.

Thanks in advance,

Jerrad

Gene LeDuc, GSEC
Security Analyst
San Diego State University

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
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
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



The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Actually adding another CF might not be much of an issue, as I realized that
many of our
CFs are actually for information tied to the user and not the job per se.
Plus, these fields
(like phone and address) already exist for user objects. Alas, this also
means my web
client has to have ModifyUsers :-/

But, it does create a nice clean separation. The other thing I’m working on
to clean things
up, is figuring out how to change display the user’s real name in the
Requestors field of
the People box, instead of their email. I also intend to make this a link to
ModifyPeople.html,
to save a few clicks in getting to the user information.
Cambridge Energy Alliance: Save money & the planet