[rt-users] Draft RT quickstart guide

[Jesse]

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 at 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"/ <queuename>
   / 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/<queuename>/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 at eruditorum.org -- jesse at 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.