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