I put this together in the past day or so. Meri took an editing pass at it
tonight.
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:
Name
Email Address
Password
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:
"ShowTicket"
"ShowTicketComments"
"Watch"
"WatchAsAdminCc"
"OwnTicket"
"ModifyTicket"
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
(“Configuration”/“Keywords”).
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.org – jesse@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
years.