Best practices: Queues vs. Custom fields

RT Users
1

Howdy.

We’re beginning our test implementation of RT, and we currently plan to
have several queues for different types of requests: development,
repairs (one-time), maintenance (recurring, but not regularly), supplies
(printer toner, etc.). Additionally, the powers that be want the
ability to generate reports based on departments (e.g., average time to
resolve tickets coming from Accounting). For this, I propose adding a
Custom Field to tickets designating the requestor’s department.

Would it make more sense to have Queues by department and handle request
type differently?

Is there a recommended “best practice”?

On a related note, when a requestor creates a ticket via e-mail, could
the proposed department field be auto-populated based on the requestor’s
address, or should the department field instead be part of the User
object?

TIA,
Mike

2

I’ll let someone else answer the more general question :slight_smile:

As for your last question - sure. Only problem is, with “From”, you
have a large number of people to check. Better to have several
different email aliases that all point at the same queue, and then check
the “To” header. Eg:

printers@tickets.yourcompany.com
pcrepair@tickets.yourcompany.com
software@tickets.yourcompany.com

Then, make a custom scrip for the queue that takes the first part (like
printers) and sets that as the CF value, but only if the new ticket is
created by email.

Description: Change CF based on who this was sent to
Condition: On Create
Action: User Defined
Template: Global template: Blank
Stage: TransactionCreate

Custom condition:

Custom action preparation code:

Get the message attachment

my $msgatt = $self->TransactionObj->Attachments->First;
return 0 if (!$msgatt); # if no message attachment - assume web UI
return 0 if (!$msgatt->GetHeader(‘Received’)); # exit if not email
message

Custom action cleanup code:
my $msgatt = $self->TransactionObj->Attachments->First;
my $reqtype = $msgatt->GetHeader(‘To’);
($reqtype) = ($team =~ /<(\w+)@.+$/);

my $cf = RT::CustomField->new( $RT::SystemUser );
$self->TicketObj->AddCustomFieldValue( Field => 19, Value => $reqtype,
RecordTransaction => 0 ) if
($self->TicketObj->CustomFieldValues($cf->Id)->Count < 1);

3

My advice would be to have a queue per department. Whether or not there is
a best practice, I’m not sure, but since your tickets are going to be
coming in via email, a custom field means that someone has to look at the
ticket and then enter the correct data in the custom field. If you sort
them as queues by department, then you can have an individual email
address for each queue and the tickets would auto-sort by department since
the queue is dedicated to that department.
I’m sure someone clever will find a way to do an LDAP lookup and get the
department field auto populated, but if you cannot do that, then each
department having a queue would be much easier.

“Michael Finn” mfinn@nbutexas.com
Sent by: rt-users-bounces@lists.bestpractical.com
02/01/2006 09:11 AM

To
rt-users@lists.bestpractical.com
cc

Subject
[rt-users] Best practices: Queues vs. Custom fields

Howdy.

We’re beginning our test implementation of RT, and we currently plan to
have several queues for different types of requests: development,
repairs (one-time), maintenance (recurring, but not regularly), supplies
(printer toner, etc.). Additionally, the powers that be want the
ability to generate reports based on departments (e.g., average time to
resolve tickets coming from Accounting). For this, I propose adding a
Custom Field to tickets designating the requestor’s department.

Would it make more sense to have Queues by department and handle request
type differently?

Is there a recommended “best practice”?

On a related note, when a requestor creates a ticket via e-mail, could
the proposed department field be auto-populated based on the requestor’s
address, or should the department field instead be part of the User
object?

TIA,
Mike
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at
http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at
http://bestpractical.com/services/training.html

4

I was able to add Dept information to a ticket custom field from LDAP
based on the example in the RT Essentials book (pg 81).

Note you need to add this at top of the code:
“use Net::LDAP;”
Also for my older build I had to use LoadByNameAndQueue instead of
LoadByName
Queue ‘0’ is for custom fields that apply to all queues.
#$cf->LoadByName( Name => ‘Department’ );
$cf->LoadByNameAndQueue( Name => ‘Department’, Queue => ‘0’);

If you want to use the existing statistics add-on for reporting
(Request Tracker Wiki) you
should pick the most important attribute: either Department or Tasktype
to base your queues on, since those stats are based on queues.

Currently I’m trying to figure out a better way to do custom reporting
by department using the API. I’d like to write a CustomAction that
writes some stats to a file and launch it using rtcrontool. Any hints
would be appreciated.

Working outside of the API to write reports on departments (PHP + MySQL)
I’ve learned a few things:

  1. The Ticket.Creator and the Requestor don’t always stay the same (e.g.
    someone sends a email to me, I forward it to RT, then afterwards change
    the “people” so that requestors email address used instead of mine.
    When this happens creator and requestor are different.

  2. A query to match the requestor to a ticket is a complicated join
    (Request Tracker Wiki). It
    is a simpler query to join a ticket custom field to the ticket. I used
    to put Dept information in the existing Users.Organization field, but
    now I use a Ticket customfield for Dept instead.

  3. Merged tickets can do funny things to statistics. If I do a simple
    query counting all tickets created, then do another query grouping by
    department, the sum of the grouped-by-department won’t equal all tickets
    unless I exclude tickets where (id != EffectiveId).

MikeHamilton@clovisusd.k12.ca.us wrote:

My advice would be to have a queue per department. Whether or not
there is a best practice, I’m not sure, but since your tickets are
going to be coming in via email, a custom field means that someone has
to look at the ticket and then enter the correct data in the custom
field. If you sort them as queues by department, then you can have an
individual email address for each queue and the tickets would
auto-sort by department since the queue is dedicated to that department.
I’m sure someone clever will find a way to do an LDAP lookup and get
the department field auto populated, but if you cannot do that, then
each department having a queue would be much easier.

Mike Patterson
Systems Manager
UC Berkeley Extension

5

Howdy.

We’re beginning our test implementation of RT, and we currently plan
to
have several queues for different types of requests: development,
repairs (one-time), maintenance (recurring, but not regularly),
supplies
(printer toner, etc.). Additionally, the powers that be want the
ability to generate reports based on departments (e.g., average time
to
resolve tickets coming from Accounting). For this, I propose adding a
Custom Field to tickets designating the requestor’s department.

Would it make more sense to have Queues by department and handle
request
type differently?

I choose to use queue’s by department, and then issues on to that.

So Development::QA::Deployment
Or Development::Research::X

Or Services::Client::$client
Or Services::Internal::AccountManagers

Works well for me, ymmv.

Is there a recommended “best practice”?

On a related note, when a requestor creates a ticket via e-mail, could
the proposed department field be auto-populated based on the
requestor’s
address, or should the department field instead be part of the User
object?

If you are using LDAP, you should already have the department as a part
of their id in active directory. That can be filled in automatically to
the users object.

That being said, you could still auto-populate a ticket’s custom field
based on the requestor address. What do you do with CC’s? Add those as
well?

A Multiple select department list?

In my mind, having them separated by queues is easier. I find that
things like, specific custom fields are easily to deploy like that. I
can set permissions very easily by locking off views between
departments, and units.

Give managers an amount of control, view over their units tickets.

Do individual group reports based on each member of a group, which has
permissions to the queue. So Manager X in Development has a queue for
his team. Each member is in a group for permissions to that queue (and
subsequently any shared queues)

Can generate reports based on tickets open, for each member of group.
Which ends up being their team.

You may be able to do all of this without doing departmental queues.
Just what works for me.

6

Would it make more sense to have Queues by department and handle request
type differently?

Is there a recommended “best practice”?

I always thought it make sense to match the queues to the people
who are watching them and handling the requests. If the same
people handle obviously different request types or you anticipate
splitting the work later you might want additional queues.

Les Mikesell
les@futuresource.com