Hi all,
I’ve been using RT in production for about a month now (big
thanks to whoever did the FreeBSD port). I’ve made some
modifications to suit our environment and I thought I’d ask
to see if they’d been done before (and perhaps better) or
if someone else would be interested in using the code I’d
written. Here’s a brief list (most of these are trivial):
-
Added a line in the search page to display number of results
-
Created a scrip action that automatically assigns a keyword
to a ticket on creation (we use it to parse the customer’s
email address and assign the ticket as belonging to that
customer).
-
Added a few more statuses, the most significant being
‘accepted’. This is when our customer has accepted that
a problem has been solved - it comes after we’ve resolved
it. Sometimes we disagree that something has been fixed 
I’ve also added a button in the SelfService page which
allows users to ‘Accept’ a resolved ticket.
(The other statuses were ‘coded’ to show we’ve written the
code but not finished testing, ‘tested’, to show we’ve
finished testing, ‘reopened’ when customer doesn’t
accept that a bug has been fixed.)
-
We use subversion (subversion.tigris.org) as our source
control tool, so I have a post-commit hook which talks to
rt through the CLI to update a ticket - it will add the
commit comment and the time taken and change the ticket
to ‘coded’ status. (The ticket number and time must be
specified in the checkin comment).
I think the rest of the changes I’ve made have been cosmetic,
in making the interface work the way that suits our company
the best. Here’s what’s currently on my todo list (if anyone
has done any of these already, please let me know):
a) Make a quicksearch textbox, which brings up any issue
that has whatever was entered in the textbox in either
the subject or any of the comments or correspondence.
(This is to make searching for duplicates easier).
b) Create rollovers in the SelfService page to explain the
status of each issue, so that if the customer rolls their
mouse over any particular issue, a little box pops up to
explain what the status means (along with a preference to
turn this off - we allow customers at the preferences page)
c) Statistical analysis; specifically who has worked on which
tickets, how long they spent doing it, when they did it,
averages over time, against a keyword, etc. This is to
help us track how much time we spend on any particular
customer, including working out who spent the time so we
can track how much it then cost us.
Hope some of this is useful to people out there. Let me
know if you want any of the code I’ve done. I’m using version
2.0.15 which is the one in the FreeBSD port, and
we’re using it in production (we get 5-10 tickets a day, via
email and web, and customers frequently check their issue status).
Thanks to Jesse and the gang for putting RT together, it’s
a big help.
Aidan
Sounds like a lot of good stuff. I could probably use some of those
changes. The one big thing that I need, and haven’t looked at yet is adding
a new ‘action’ (like Comment or Reply) called Downtime, where I can use the
Worked Minutes field as a ‘System Downtime’ entry, and also an action
called ‘Paged’ to signify when a Tier II/Tier III person has been paged. Of
course, there may be a way of doing this as is that I haven’t figured out
yet, so any suggestions would be greatly appreciated.
The statistical stuff would be great. I am using the Cozens stats package,
but it’s not quite what we are looking for.
And yes, thanks to Jesse for a great system!
Tom–On Wednesday, March 05, 2003 9:02 AM +1100 aidan@yoyo.org wrote:
Hi all,
I’ve been using RT in production for about a month now (big
thanks to whoever did the FreeBSD port). I’ve made some
modifications to suit our environment and I thought I’d ask
to see if they’d been done before (and perhaps better) or
if someone else would be interested in using the code I’d
written. Here’s a brief list (most of these are trivial):
-
Added a line in the search page to display number of results
-
Created a scrip action that automatically assigns a keyword
to a ticket on creation (we use it to parse the customer’s
email address and assign the ticket as belonging to that
customer).
-
Added a few more statuses, the most significant being
‘accepted’. This is when our customer has accepted that
a problem has been solved - it comes after we’ve resolved
it. Sometimes we disagree that something has been fixed
I’ve also added a button in the SelfService page which
allows users to ‘Accept’ a resolved ticket.
(The other statuses were ‘coded’ to show we’ve written the
code but not finished testing, ‘tested’, to show we’ve
finished testing, ‘reopened’ when customer doesn’t
accept that a bug has been fixed.)
-
We use subversion (subversion.tigris.org) as our source
control tool, so I have a post-commit hook which talks to
rt through the CLI to update a ticket - it will add the
commit comment and the time taken and change the ticket
to ‘coded’ status. (The ticket number and time must be
specified in the checkin comment).
I think the rest of the changes I’ve made have been cosmetic,
in making the interface work the way that suits our company
the best. Here’s what’s currently on my todo list (if anyone
has done any of these already, please let me know):
a) Make a quicksearch textbox, which brings up any issue
that has whatever was entered in the textbox in either
the subject or any of the comments or correspondence.
(This is to make searching for duplicates easier).
b) Create rollovers in the SelfService page to explain the
status of each issue, so that if the customer rolls their
mouse over any particular issue, a little box pops up to
explain what the status means (along with a preference to
turn this off - we allow customers at the preferences page)
c) Statistical analysis; specifically who has worked on which
tickets, how long they spent doing it, when they did it,
averages over time, against a keyword, etc. This is to
help us track how much time we spend on any particular
customer, including working out who spent the time so we
can track how much it then cost us.
Hope some of this is useful to people out there. Let me
know if you want any of the code I’ve done. I’m using version
2.0.15 which is the one in the FreeBSD port, and
we’re using it in production (we get 5-10 tickets a day, via
email and web, and customers frequently check their issue status).
Thanks to Jesse and the gang for putting RT together, it’s
a big help.
Aidan
rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users
Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm
a) Make a quicksearch textbox, which brings up any issue
that has whatever was entered in the textbox in either
the subject or any of the comments or correspondence.
(This is to make searching for duplicates easier).
This one’s actually already in 3.0. it might be worth having a look.
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
a) Make a quicksearch textbox, which brings up any issue
that has whatever was entered in the textbox in either
the subject or any of the comments or correspondence.
(This is to make searching for duplicates easier).
This one’s actually already in 3.0. it might be worth having a look.
Will do - how easy is the upgrade path? My main concern is that this
is a live system and I want to minimise downtime.
Aidan