Draft RT quickstart guide

I put this together in the past day or so. Meri took an editing pass at it

It’s the first draft of a “quickstart configuration guide.” I hope this
helps some folks out with some of the key concepts behind RT. Commentary
to rt-doc-workers@lists.fsck.com would be greatly appreciated.

RT Quickstart configuration:

Run through the installation

Create your users

In its default configuration, RT uses an internal users database to keep
track of who can access RT and who has what rights within the system.

One of your first tasks should be to create users for anyone who will
need to work with tickets within RT.

With the web interface, click on “Config” then “Users” then “Add new
user”. When creating new users, be sure to fill in:

Email Address
Be sure to click on "Let this user be granted rights"

Create your queues

RT’s primary administrative unit is the ‘queue.’ Use queues to separate
tickets either by the groups of people who should be dealing with them,
the user community or ticket attributes, or some combination therein.
Generally, you don’t want to create queues for time-limited projects. In
most situations, queues are not things you should be creating or
deleting with any frequency.

Grant the users the rights they need.

RT provides a rich access control system that allows rights to be
granted to groups, individual users and users in specific roles.

To allow arbitrary remote users to submit tickets into a given queue by
email, grant “Everyone” the rights to “SeeQueue”, “CreateTicket”,
“ReplyToTicket” and “CommentOnTicket” for that queue.

If you intend to let ticket requestors use the requestor-mode web
interface, you should grant “Requestor” the right to “ShowTicket”

To make sure that your staff can work with tickets, you should grant
them all the following additional rights:


Set up Scrips

RT’s “Scrips” system lets sites configure what email gets sent by RT in
response to ticket creation or updates. Unless you set up Scrips, RT
will not send any email. (It’s also a general extension mechanism
which allows changes to persist across updates. But if you’re reading
this quickstart guide, you probably just don’t want to go there yet.)

Scrips are composed of a Condition, an Action and a Template. A number
of Conditions and Actions come with RT. Others are available as
contributed add-ins from members of the RT community. Later on, you can
define custom templates for each queue, but for now, RT ships with a set
of predefined templates which should get you started.

A reasonable default set of scrips for a queue is something like this:

  OnCreate AutoReplyToRequestors with Global Template: AutoReply
  OnCreate NotifyAdminCcs with Global Template: Transaction
  OnCorrespond NotifyAllWatchers with Global Template: Correspondence
  OnComment NotifyAdminCcsAsComment with Global Template: AdminComment
  OnResolve NotifyRequestors with Global Template: Resolved

Set up queue watchers

RT lets you set up Cc and Administrative Cc watchers globally and for
each queue. (Note that mail isn’t sent unless you define Scrips to send
it). Generally, Cc watchers are folks who get notifications of ticket
updates and can view the queue (though this, of course, depends on how
you configure things). Administrative Ccs are usually the folks who have
rights to modify tickets. Set up folks you want to get Cc or AdminCc
mail as watchers for your queue in “Configuration”/“Queues”/
/ Watchers.

Set up keywords

RT’s keyword system is centered around a single global hierarchy of
keywords and the concept of “Keyword Selections”. Keyword Selectors
allow you to set up custom fields either for your whole RT installation
or for a single queue. Keyword Selections let you pick a node in the
Keywords tree as its “root” and to decide whether users can pick either
a single value or multiple values from that list.

For now, you probably don’t need any keyword selectors, but once you
want to start ‘tagging’ requests with keywords, come back and add a
keyword called “Queues” to the Keywords hierarchy

Once you’ve created that keyword, click on it and add a new keyword
named after your queue. Click on that. Add a keyword as the root of
your new Keyword Select. Let’s call it “operating system.” Under
Operating system, add a bunch of operating systems.

Now, click on “Configuration” / “Queues” / your queue name / “Keyword
Selections” Enter a name for your keyword selection, like “Client OS”.
Allow “multiple” values of "Queues//Operating System Up to 0
(unlimited) levels deep.

Now you’ll be able to set ‘Client OS’ for tickets in your queue.

jesse reed vincent – root@eruditorum.orgjesse@fsck.com
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

Any e-mail sent to the SLA will immediately become the intellectual property
of the SLA and the author of said message will enter into a period of
indentured servitude which will last for a period of time no less than seven

Jesse wrote:

I put this together in the past day or so. Meri took an editing pass at it

If you intend to let ticket requestors use the requestor-mode web
interface, you should grant “Requestor” the right to “ShowTicket”


What do you mean by “requestor-mode web interface”?
How can I (or the ‘external’ requestor) access it?

thanks for the support,