Ideas on best way to do this?

Here is what I would like to do, but I am not sure if the approach I am taking is one that makes sense or if I should be going about it a different way, so I thought I would ask :slight_smile:

Idea for how I would like it to work

Caller 1 calls in on Issue A (Ticket #XXXX)
–>Ticket Created
–>Ticket Gets Resolved
–>Caller 1 Calls in on Issue B (Sub/Child Ticket of Original Ticket)
–>Ticket Created
–>Ticket Gets Resolved
–>Caller 1 Calls in on Issue C (Sub/Child Ticket of Original Ticket)
–>Ticket Created
–>Ticket Gets Resolved

Caller 2 calls in on Issue A (Ticket #XXXY)
–>Ticket Created
–>Ticket Gets Resolved
–>Caller 2 Calls in on Issue B (Sub/Child Ticket of Original Ticket)
–>Ticket Created
–>Ticket Gets Resolved
–>Caller 2 Calls in on Issue C (Sub/Child Ticket of Original Ticket)
–>Ticket Created
–>Ticket Gets Resolved

The idea is that when we create a ticket for a given user, each additional ticket will refer to the original ticket. So I am thinking that Child Tickets would be the best way to do this. Am I correct, or am I barking up the wrong tree?

Thanks In Advance

Greg Evans

Greg Evans wrote:

Here is what I would like to do, but I am not sure if the approach I am taking is one that makes sense or if I should be going about it a different way, so I thought I would ask :relaxed:

The idea is that when we create a ticket for a given user, each additional ticket will refer to the original ticket. So I am thinking that Child Tickets would be the best way to do this. Am I correct, or am I barking up the wrong tree?

It certainly doesn’t seem to make sense, why use the requestor’s first
ticket as a reference point instead of the requestor account itself?

e.g. on any given ticket, one of the searches at the top of the display
is “This Requestor’s other tickets…”, and any ticket list or search
can be given the restriction “Requestor LIKE X”…

Perhaps if you explained why you were looking at doing it this way - an
idea as to what you are trying to accomplish…
Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com

Hello,

It certainly doesn’t seem to make sense, why use the requestor’s first
ticket as a reference point instead of the requestor account itself?
[…]
Perhaps if you explained why you were looking at doing it this way - an
idea as to what you are trying to accomplish…

One of the scenarios I can think about (actually one that I am
interested in myself) is when you have a number of clients (company
information with several individuals, phone numbers, etc). You create
a ticket for each each client with some custom fields to store
additional information. Then all requests from the client are created
as child tickets, so that you can have a clear picture of what’s going
on by looking at the links of the client ticket.

Leonid Mamchenkov

Leonid Mamchenkov wrote:

Hello,

It certainly doesn’t seem to make sense, why use the requestor’s first
ticket as a reference point instead of the requestor account itself?
[…]
Perhaps if you explained why you were looking at doing it this way - an
idea as to what you are trying to accomplish…

One of the scenarios I can think about (actually one that I am
interested in myself) is when you have a number of clients (company
information with several individuals, phone numbers, etc). You create
a ticket for each each client with some custom fields to store
additional information. Then all requests from the client are created
as child tickets, so that you can have a clear picture of what’s going
on by looking at the links of the client ticket.

Why wouldn’t you use User Custom Fields instead of storing the
information in a separate ticket for the user?

Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com

Hey Mike,

We don’t really use the requestors field because the tickets don’t get viewed or looked at by anyone but myself and my boss. We don’t want the replies to go out to the customer, so we don’t put their name in it or anything so everything is set up so that the only ‘requestor’ is our support account. Maybe it would be better for me to just turn off the function of emailing on reply (I think that is it) and put the customers email address in the requestors field and then do as you suggest?

Greg EvansFrom: Mike Peachey [mailto:mike.peachey@jennic.com]
Sent: Tuesday, February 05, 2008 9:12 AM
To: Greg Evans
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Ideas on best way to do this?

Greg Evans wrote:

Here is what I would like to do, but I am not sure if the approach I am taking is one that makes sense or if I should be going about it a different way, so I thought I would ask :relaxed:

The idea is that when we create a ticket for a given user, each additional ticket will refer to the original ticket. So I am thinking that Child Tickets would be the best way to do this. Am I correct, or am I barking up the wrong tree?

It certainly doesn’t seem to make sense, why use the requestor’s first
ticket as a reference point instead of the requestor account itself?

e.g. on any given ticket, one of the searches at the top of the display
is “This Requestor’s other tickets…”, and any ticket list or search
can be given the restriction “Requestor LIKE X”…

Perhaps if you explained why you were looking at doing it this way - an
idea as to what you are trying to accomplish…
Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com

Greg,

For each ticket that is created, there are links that you can create 

that will show the relationship between the two (or more) tickets. Child
tickets are designed as a dependency, but a one that belongs to the same
queue as the base request. This is in case there is an administrator
that wants to keeps tabs on just his responsibilities. There is also the
“Depends On” link, which is designed to show dependency relationships
BETWEEN queues. This would be a case where the administrator of one
queue wants to know what tasks (from other queues, different
administrator) are holding up his work in his queue. Requestor info
(i.e. name, company, etc.) can be controlled by the template you use for
notification IF you use a notification. If you have a queue where you do
not want the requestors to get notifications, just dissable those kind
of scrips, but keep the requestor info on the ticket.
Ticket relationships are there for project management type reporting.
Not every will need/use them.
Also, a dependency SHOULD mean that Ticket #1 CANNOT be resolved until
Ticket #2 is resolved first. You shouldn’t be able to resolve #1 first.
That’s the point of the “dependant” relationship.
Just a few thoughts. Hope they help.

Kenn
LBNLOn 2/5/2008 9:05 AM, Greg Evans wrote:

Here is what I would like to do, but I am not sure if the approach I am taking is one that makes sense or if I should be going about it a different way, so I thought I would ask :relaxed:

Idea for how I would like it to work

Caller 1 calls in on Issue A (Ticket #XXXX)
–>Ticket Created
–>Ticket Gets Resolved
–>Caller 1 Calls in on Issue B (Sub/Child Ticket of Original Ticket)
–>Ticket Created
–>Ticket Gets Resolved
–>Caller 1 Calls in on Issue C (Sub/Child Ticket of Original Ticket)
–>Ticket Created
–>Ticket Gets Resolved

Caller 2 calls in on Issue A (Ticket #XXXY)
–>Ticket Created
–>Ticket Gets Resolved
–>Caller 2 Calls in on Issue B (Sub/Child Ticket of Original Ticket)
–>Ticket Created
–>Ticket Gets Resolved
–>Caller 2 Calls in on Issue C (Sub/Child Ticket of Original Ticket)
–>Ticket Created
–>Ticket Gets Resolved

The idea is that when we create a ticket for a given user, each additional ticket will refer to the original ticket. So I am thinking that Child Tickets would be the best way to do this. Am I correct, or am I barking up the wrong tree?

Thanks In Advance

Greg Evans


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

Greg Evans wrote:

Hey Mike,

We don’t really use the requestors field because the tickets don’t get viewed or looked at by anyone but myself and my boss. We don’t want the replies to go out to the customer, so we don’t put their name in it or anything so everything is set up so that the only ‘requestor’ is our support account. Maybe it would be better for me to just turn off the function of emailing on reply (I think that is it) and put the customers email address in the requestors field and then do as you suggest?

In my experience of using RT on a small scale and then ramping it up,
there are two things you should take into account when starting:

  1. The system was carefully designed to function in a specific way with
    a specific logical structure. While it is possible to change the way it
    works and use it differently, you should always try to work within the
    original design, or you will be working against yourself and it will be
    ultimately self-defeating.

  2. Start like you’re starting with a very large system, otherwise you
    can create major problems for yourself when you start to grow the system
    later. Just because you only have one or two users, use it as if you had

Our internal support system started with two users, me and the boss.
Then we integrated the rest of the company via LDAP and a new tech.
support guy and now we are running at over 100 users. The only reason it
works so well is that we went back on decisions made at the start
because it was only for us, to make sure it remained scalable.

If I can now apply the two points above to what you said about what you
actually want it to do:

“We don’t want the replies to go out to the customer, so we don’t put
their name in it or anything so everything is set up so that the only
‘requestor’ is our support account.”

With regards to point 1, you don’t want replies to go out to the
customer, RT is designed to allow you to turn off this functionality at
the click of a button, so rather than change the whole nature of the
requestor object by assigning it as yourself, stay within RT’s original
design and just turn off the global scrip “On Correspond Notify
Requestors and Ccs with template Correspondence”. This will prevent the
requestor or any CCs from being notified by e-mail about the tickets,
but will allow you to correctly assign requestors and work with them as
proper user objects.

If you then find that you are not receiving e-mail yourself about
tickets that you’ve created in someone else’s name, the simple solution
is to add yourself as an AdminCC for either individual tickets, or the
whole queue and you will then get e-mails about everything someone else
does on the ticket.

With regards to point 2, having the support account be the requestor for
every ticket is fine for now - but should the time come that you need to
deal with more users, or more tickets, or expand your staff… it’s going
to become difficult to deal with it and, if at the same time, you have
change the design structure so that tickets are keeping information
about users, but ticket requestors aren’t the users etc… it’s going to
end up completely unmanageable.

The whole reason that RT is used world-wide by very large companies and
very small companies alike is that it’s design is perfect. It works for
tiny systems and it works for massive systems, all you have to do is
work with it and not against it.

So, in short:

Turn off the global scrip:
“On Correspond Notify Requestors and Ccs with template Correspondence”

Add extra information about users in USER custom fields.

Add the users as requestors and then set the OWNER to be the person
dealing with the ticket.

Anyone that should get e-mails about any action on a queue that they
themselves have not made should be an AdminCC for the queue, or they
should be set as AdminCCs for individual tickets.

Good luck.
Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com

Let’s not delude ourselves. Most of RT is very flexibly designed, but it’s
not perfect. Maybe RT4 will be perfect but I doubt it.

I agree with your other points though. Leave the requestor field alone and
turn off email to the requestor if that is what is desired.

-Todd

What we have:

  • User has Organization field
  • RT has support for searches like “Requestor.Organization = ‘X’”

What you have to do:

  • maintain users’ field
  • replace “More about X” box with “More about X’s company Y”

The latter is very easy:

find . | xargs grep ‘More about’
./html/Ticket/Elements/ShowRequestor: title_raw => loc(“More about
[_1]”, $name),
open it in your preferred editor
find line
$tickets->FromSQL( “Requestor.id = “. $requestor->id .” AND (Status =
‘open’ OR Status = ‘new’)” );
doesn’t look similar? replace it with:
if ( $requestor->Organization ) {
$tickets->FromSQL( “Requestor.Organization = '”.
$requestor->Organization .“’ AND (Status = ‘open’ OR Status = ‘new’)”
);
} else {
$tickets->FromSQL( “Requestor.id = “. $requestor->id .” AND
(Status = ‘open’ OR Status = ‘new’)” );
}
drop mason cache
reload a ticket you’ll see info about requestor’s company tickets if field is filled

it’s a beginning not ideal but easy. Homework:

  • read about Callbacks as this comp provide it and you can extend RT
    in a proper way
  • read about cleanly customizing RT
  • both available on the wiki
  • create an index on users table by organization to avoid slowing down
    your system
  • improve above change to change title of the box if search by
    organization is used
  • teach people how to search tickets by organization
  • teach people how to save searches and them to “RT at glance”

There are really many ways to improve this to a better solution.

It’s not a first time this question has been asked and sure there were
another suggestions and details, but afaik nobody who was interested
havn’t yet published info and/or implementation to the wiki or
somewhere else.On Feb 5, 2008 8:23 PM, Leonid Mamchenkov leonid@mamchenkov.net wrote:

Hello,

On Feb 5, 2008 7:11 PM, Mike Peachey mike.peachey@jennic.com wrote:

It certainly doesn’t seem to make sense, why use the requestor’s first
ticket as a reference point instead of the requestor account itself?
[…]
Perhaps if you explained why you were looking at doing it this way - an
idea as to what you are trying to accomplish…

One of the scenarios I can think about (actually one that I am
interested in myself) is when you have a number of clients (company
information with several individuals, phone numbers, etc). You create
a ticket for each each client with some custom fields to store
additional information. Then all requests from the client are created
as child tickets, so that you can have a clear picture of what’s going
on by looking at the links of the client ticket.


Leonid Mamchenkov


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

Best regards, Ruslan.

Ruslan,On Feb 7, 2008 1:31 AM, Ruslan Zakirov ruz@bestpractical.com wrote:

What we have:

  • User has Organization field
  • RT has support for searches like “Requestor.Organization = ‘X’”

What you have to do:

  • maintain users’ field
  • replace “More about X” box with “More about X’s company Y”

Thanks a lot for your reply. That gives so much to think about! I’ll
definitely dig deeper into it too.

Leonid Mamchenkov

Greg Evans wrote:

Hey Mike,

Thanks for the reply. I am attaching a screenshot of what I created for my
tickets previously with custom fields and all of that.

Maybe with my SS you can tell me if I am at least on the right track there?

Well, with regards the last four custom fields, you certainly are,
that’s pretty much what they’re designed for, but FirstName, LastName,
e-mail address and telephone number will start to cause you massive
issues due to data duplication.

Although you would be manually linking the tickets together, each time
you raise a ticket for the same user, you have to re-enter the same
information, and if any information changes, it won’t be reflected on
previous tickets, so if you look at an old ticket and want to call the
customer, you’d have to check the most recent ticket for the most recent
phone number, instead of just getting the number from the user’s (always
up to date) information.

Also, you are then creating masses of data within the database that is
unnecessary and in violation of data normalisation guidelines. You
should only need to store each piece of information about one object
once, not once per ticket… so you’re massively increasing the amount of
data to store and it will eventually have an impact on the total size
and speed of the database as a whole.

If you create a user for each customer as they advise you of an issue
(either manually, or through a myriad of automagical ways), then you can
add as much information as you need to about the user in the user
information fields, add as many user custom fields as you want for extra
information about that user and then ANY time you are looking at a
ticket belonging to that user, you are linking straight to the user’s
account and their full information, even if you change it.

Tickets should only need to hold information that changes for each
ticket raised.
Users should only need to hold information that changes for each user.

Then, turn off the e-mailing of replies to users and bingo - a scalable,
usable, logical system.

You seem to know a lot about RT and how it works

I didn’t used to, I’ve just been tweaking it for so long I’ve been past
most of the code and added a lot of my own.

, and I am admittedly not a
programmer by any means LOL!

Me either, I wish I was, then it wouldn’t take so long :stuck_out_tongue:

But do you know if it is possible for RT (I
couldn’t find it when I searched Google) to automatically enter the time
worked based on the time elapsed between when the ticket was opened and when
it was updated? I guess(?) that if an issue remained unresolved and the
customer called back it would have to add time to said ticket on each
update? I will keep searching for this on my own, but figured it couldn’t
hurt to ask.

I don’t see why not. I might be wrong about the best way to do it, but
it certainly seems you could add a custom scrip action to do it.

Pseudocode:

“On Ticket->Update, Ticket->Worked = Ticket->Updated() - Ticket->Created()”

Although, you might need to convert the times into Unix time, then do
the sums and then convert back again.

Thanks for all of your help. I am going to take those suggestions and
implement them as well to make sure that if this needs to scale up
eventually, which I am sure it will, that I don’t get caught in a nightmare
that I cannot get out of.

Good plan. Just make sure to keep an eye out for others who know less
than you, because without those who know more to help out those who know
less, RT would never be the great, widely-used system it is.

Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com

Hello Mike and everyone else,

I wanted to follow-up on our conversation below regarding users, etc.

I obviously don’t want massive data duplication so it would seem that the
best way to do this would be to import all of our internet customers into RT
as users with basically no permissions, set them up in a group and all of
that normal business.

All of my users are in our radius file, which is great and I am pretty sure
that I can figure out how to import them from that using standard mySQL
syntax and a exported .csv or similar file.

The problem that was brought to my attention is that I would need to do this
daily. Is there a way that you or someone would know of that would allow me
to import only the new data each day?

Please remember, I am not much of a programmer, but I would like to see if
this is possible and maybe an example if someone knows how to do it :slight_smile:

Regards,

Greg

Greg,On Wed, Feb 20, 2008 at 8:34 PM, Greg Evans gevans@hcc.net wrote:

All of my users are in our radius file, which is great and I am pretty sure
that I can figure out how to import them from that using standard mySQL
syntax and a exported .csv or similar file.

The problem that was brought to my attention is that I would need to do this
daily. Is there a way that you or someone would know of that would allow me
to import only the new data each day?

Please remember, I am not much of a programmer, but I would like to see if
this is possible and maybe an example if someone knows how to do it :slight_smile:

If you will find a way to import your data into RT once, there is, of
course, a way to do this daily. Assuming that your data is in some
text format (like .csv file), you could use GNU diff to find out the
differences between two text files (one for yesterday and one for
today). The output of GNU diff is very easy to parse and act upon.
(hint: when using this tool, go for unified diff output - it’s even
easier to parse).

Leonid Mamchenkov