Today, we had presention of RT to our help-desk managers.
Some of the questions we got during the presentation that I could not answer were:
Can we set mandatory fields that help desk people will have to enter ?
Transation: We need to force our help desk people to enter information.
Some manadatory fields might be phone numbers and the type of OS,
or physical origin of the problem. Could all of these ‘mandatory fields’ be
defined in a templet ?
How good does the automatic ticket email request work ?
My boss said, that “many help desk programs talk about automatic
features, but I have never seen one that worked”.
Translation: What types of problems does one get when users send email
tickets to the queues ? Do the parsing scripts that process the new
tickets need to be in a specific format ?
How are reports generated that I will need?
Translation: I want pretty reports. Are there any good
reporting tools that users from this list might recommend ?
Today, we had presention of RT to our help-desk managers.
Some of the questions we got during the presentation that I could not
answer were:
Can we set mandatory fields that help desk people will have to
enter ?
With a little massaging of the web front end, this should be possible,
I haven’t done this before, but it’s certainly possible.
Transation: We need to force our help desk people to enter information.
Some manadatory fields might be phone numbers and the type of OS,
or physical origin of the problem. Could all of these ‘mandatory
fields’ be
defined in a templet ?
os type and physical origin could be managed with key words, phone
number is one field of the user/requestor data
How good does the automatic ticket email request work ?
My boss said, that “many help desk programs talk about automatic
features, but I have never seen one that worked”.
It works without a flaw, but Your question is imprecise. Ticket
creation by incoming email works. Email notification upon action on a
ticket works, Lot’s of stuff is possible. With the enhanced mail
gateway You can even do some of the actions by email, but You’d
probably need a pgp key for every one on the help desk team. (Jesse
gives commercial support for the enhanced mail gateway, see
Translation: What types of problems does one get when users send email
tickets to the queues ? Do the parsing scripts that process the new
tickets need to be in a specific format ?
No, except if You use the enhanced mail gateway (which uses new pseudo
headers to paerse actions - those are specific).
How are reports generated that I will need?
Translation: I want pretty reports. Are there any good
reporting tools that users from this list might recommend ?
There is the stats package, originally by simon cozens. There are some
more bits and pieces in the contrib directory - one even exports parts
of data to csv, so You cann feed it into excel and create
manager-compatible graphs.
For more details, You need to be more detailed (-;
Regards,
Harald
Harald Wagener * FCB/Wilkens * An der Alster 42 * 20099 Hamburg
Today, we had presention of RT to our help-desk managers.
Heya. I’ve been in the same situation before, and here’s some possible
answers… (Having never touched the 2.0.x branch, all answers are
based on the experimental, 2.1.39 version of RT.)
Can we set mandatory fields that help desk people will have to enter ?
Transation: We need to force our help desk people to enter information.
Some manadatory fields might be phone numbers and the type of OS,
or physical origin of the problem. Could all of these ‘mandatory fields’ be
defined in a templet ?
Yes. This is well-defined with the per-Queue ‘Custom Fields’ settings,
which can let you specify single-input, single-select, multiple-input
and multiple-select data types are part of a ticket’s data that has
to be filled in.
How good does the automatic ticket email request work ?
My boss said, that “many help desk programs talk about automatic
features, but I have never seen one that worked”.
By default, all mails that are sent to the receiving account are
turned into a verbatim ticket, with all their attachment preserved.
It is possible, using Scrips, to trigger different actions, assign
owners, or log into some database using the UserDefined Scrip condition
and action fields, which let you to utilize the full Perl language to
process incoming tickets at different stage of its life.
How are reports generated that I will need?
See the Cozens stats package. Also because all transactions are
logged in a database, anything that can generate reports based on
SQL queries would be possible (and not very hard) to perform.
Can we set mandatory fields that help desk people will have to enter ?
Transation: We need to force our help desk people to enter information.
Some manadatory fields might be phone numbers and the type of OS,
or physical origin of the problem. Could all of these ‘mandatory fields’ be
defined in a templet ?
Yes. This is well-defined with the per-Queue ‘Custom Fields’ settings,
which can let you specify single-input, single-select, multiple-input
and multiple-select data types are part of a ticket’s data that has
to be filled in.
A related question: For my understanding, commenting
a “new” ticket is quite some illogical. In almost all
cases the editor will have simply forgotten do switch
the ticket’s status to “open”.
How would I configure RT to prevent editors from
commenting on tickets that are still in the “new”
status?
How would I configure RT to prevent editors from
commenting on tickets that are still in the “new”
status?
Why not force the ticket into Open state when they do so?
OnComment OpenTicket with template Blank
OpenTicket can be found in the contrib download area.
Phil Homewood, Systems Janitor, www.SnapGear.com pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances
A related question: For my understanding, commenting
a “new” ticket is quite some illogical. In almost all
cases the editor will have simply forgotten do switch
the ticket’s status to “open”.
Actually, we comment on “new” tickets all the time; usually this is done
when someone in the group wants to offer advice on the problem but won’t
be doing the actual work. We “open” a ticket when the actual work
begins.