Like all technologies, RT has its own lingo, and understanding RT begins with understanding this lingo. RT began life as a help desk application, and much of the terminology reflects this fact. Over time, as RT developed unique features, it accumulated new terms. This appendix gives detailed explanations of a few common terms and their relationships to each other.
RT addons such as RTFM (RT FAQ Manager) and RTIR (RT for Incident Response) have their own lingo, which is not covered here. These products include their own documentation.
The ticket is RT’s primary object, and everything that is managed by RT is contained in a ticket. A ticket represents a request, bug report, incident, work order, project, lunch order, or whatever you’re tracking with RT. As a user, most of your activity is ultimately about manipulating tickets. A ticket is identified by number and has a set of attributes, such as the subject or summary, who opened it, when it was opened, the priority of the request, and the current status. Some of these values will change over the lifespan of the ticket, such as the status, while some, such as the date the ticket was originally created, can’t be altered.
The subject of a ticket is analogous to the subject of an email: a short summary of what the ticket is about, at most a few hundred characters, intended to convey the gist of the ticket at a casual glance. Since all search result displays include the subject, it is very important that the subject be concise.
A ticket’s status describes its current work state. There are several choices for classifying each ticket:
The ticket has just been created and hasn’t been touched yet.
The ticket is being worked on.
Due to circumstances beyond your control (waiting for the requestor to respond, waiting for the owner to return from Sri Lanka), the ticket isn’t getting worked on right now. It will open again when someone adds a comment or reply.
Hooray! Work on the ticket has been completed and is out of everyone’s hair.
The ticket is not the staff’s problem and is not going to be resolved, but is, for some reason, worth recording in the system. For instance, if an employee asks approval for something ridiculous, you can reject the ticket, but it will stay in the database as evidence that the employee makes silly requests.
The ticket never should have been in the system—it was spam, it was a list of passwords, it was porn, use your imagination—and is now being zapped for good.
It is not unusual for the status to change several times, from new to open to resolved, bouncing between open and stalled a few times.
The ticket’s body is the full, detailed explanation of the ticket. It is maintained as a series of discrete elements, called attachments, which are grouped together in a transaction. A ticket’s body consists of all its transactions, arranged chronologically.
A transaction represents a single modification to a ticket, from status changes to adding content to the body. A transaction that adds content to the body of a ticket consists of one or more attachments. For example, if a user attaches a spreadsheet, or a screenshot, to a ticket, these become part of the ticket as a single transaction consisting of multiple attachments. Transactions that don’t modify the body of the ticket, like attribute changes, do not have associated attachments.
An attachment is a discrete piece of content added to the ticket body. RT borrows the concept of attachments from email (actually, from MIME). Every attachment is associated with a transaction. Like a ticket, an attachment has several attributes, including subject, content type, encoding, and a unique identifier.
A watcher is someone who is interested in a ticket. Watchers are notified when something about the ticket changes. Some types of watchers are inherited from the queue in which the ticket lives, while others are attached to the ticket itself. There are several types of watchers:
The person responsible for the ticket and its resolution. Each ticket can have only one owner at any given time.
The person or people who created the ticket or have a vested interest in the outcome.
Someone who should get copies of any replies that go to the requestor. This might be the requestor’s boss, sales rep, etc. This person will see the email but doesn’t necessarily have the right to work on the ticket.
A Cc that also gets copies of private comments about the ticket and generally has permission to work on the ticket.
People often find the distinction between Cc and AdminCc confusing. Basically, Cc means the same thing in RT as it does in email (someone that simply receives copies of correspondence), while AdminCc is RT-specific and indicates someone who can work on the ticket. In practice, though, the difference is not too important, and permissions can be applied to either type of watcher so that it can fill almost any role.
A ticket’s history is what it sounds like: everything that has happened to a ticket. RT automatically tracks every change to a ticket, including when the ticket was created, how it has changed, and any comments about it or replies to it. Like real history, ticket history cannot be changed, so be aware that any comments you make about a ticket are permanent. This audit trail provides detailed information about not only what changed, but when it changed and who changed it. As of RT 3.4, RT also tracks every outgoing email about a ticket, so you can be sure that your boss really was notified that you submitted a vacation request.
Ticket updates can take one of two forms: replies and comments. A reply is a public remark that is sent to the requestor. A comment is a private note for staff that is not visible to the requestor. This is useful when you want to be tactful but still convey important information, like, “This requestor is an investor, so be nice” or “This user’s request mentioned his ‘PC’ but he really has a Mac.”
Priority represents the relative importance of a ticket. It is stored as a number from 0 to 99, with 99 generally being the highest priority. The difference between 25, 50, and 75 may vary from organization to organization, but there should be an organizational policy, or every ticket will get rated 99 by anxious users.
In addition to priority, a ticket can have an initial priority or a final priority. By setting either of these values, you can make a ticket’s priority increase or decrease as its due date draws closer. Thus, the priority of a ticket is its current priority, which may or may not be equal to the initial or final priority.
RT maintains relationships between tickets and other objects. Relationships in RT can be between multiple tickets on the same RT instance but also can link tickets to external items like URLs, FedEx shipping numbers, or even other bug tracking systems like Bugzilla. RT defines a few basic types of relationships:
The ticket can’t be resolved unless another ticket is also resolved. The converse is Depended on by.
The ticket doesn’t need the other ticket, but it would sure be useful for you to look at it. The converse is Referred to by.
A big, general ticket (“Move house”).
A subproject of a parent (“Hire movers” “Pack” “Eat pizza”).
By defining relationships between tickets, it is possible to clearly define a hierarchy of work that needs to be done in order for a ticket to be resolved. This can be helpful in figuring out dependencies; for example, if new feature X can’t be added until bug Y is fixed, then the ticket for feature X depends on the ticket for bug Y and can’t be resolved until the bug is fixed.
There are many dates associated with each ticket, everything from when the ticket was originally created, to when it was last modified, to when it was resolved. The system automatically sets some of these at the time of certain actions, while some can be modified by anyone with the appropriate rights.
The date that the ticket was initially created.
The date when work should begin on the ticket. This field is set at ticket creation time.
The date by which the ticket should be completed. This field is set at ticket creation time.
The date that work was actually started on the ticket.
This date indicates that last time notification about the ticket was sent out. This field is sometimes known as Told.
The date of the last modification to the ticket.
The date that the ticket was resolved. Obviously, this will be set only for resolved tickets.
The Created, Last Contacted, Last Updated, and Resolved dates are maintained by RT itself everytime the ticket is modified. Starts and Due can be set by anyone with permissions to modify the ticket.
Custom fields (also known as CFs) are application-specific metadata that are created specifically for the local RT installation.
Starting with RT 3.4, custom fields can be applied to tickets, transactions on tickets, users, and groups. Each custom field can apply to only one type of object. Ticket and transaction custom fields can be tied to any number of queues, but user and group custom fields apply system-wide.
Custom fields can be one of several types:
A Select field has a predetermined set of values. For example, a CF containing a list of computer operating systems supported by the Help Desk would very likely be a Select CF.
Freeform fields contain single lines of text.
Text fields hold multi-line blocks of plain text.
Text fields hold multi-line blocks of wiki text.
Binary fields are uploaded files.
Image fields are like Binary files, but they are displayed on the Web UI instead of presented as download links.
In addition to its type, a custom field also has a MaxValue setting that limits the number of its entries. As of this writing, the web configuration interface only allows 1 (Single fields) and 0 (Multiple fields).
Disorganized tickets are hard to manage, so RT provides a container for grouping tickets: the queue . The queue is the central administrative domain of RT. As the name implies, it’s a line of tickets waiting to be worked on, but it’s also the ticket’s category. Permissions are applied to queues, rather than directly to tickets, so which actions you can take on a ticket depends on the ticket’s queue. For instance, you might have the right to create, delete, and comment on tickets in the Foo queue but only the right to comment on tickets in the Bar queue.
Scrips are custom actions that are automatically triggered in response to specific conditions. The scrip machinery is very generalized and flexible, and it is able to do anything you can code in or call from Perl (i.e., just about anything at all). For example, you could have RT email the requestor when a ticket is resolved, send you an instant message when your boss submits a request, or mail ticket statistics to you when a ticket is closed. RT’s default actions, such as sending mail on the creation of a new ticket, are handled by scrips. RT can apply scrips to all tickets or to all tickets in a specific queue. See Chapter 6 for more examples on using scrips.
How does RT know whether to execute a scrip? This decision is based on the scrip’s condition, which determines whether a scrip is applicable to the current transaction.
When a scrip is activated, it executes a template. Most templates turn into email messages, using the Text::Template module, but since you can embed Perl in them, they can do just about anything.
A user represents a single entity within RT. Usually, the RT administrator creates users manually, but RT can be configured to autocreate user objects under certain conditions, such as when it receives mail from an email address that it has not seen before. Once a user exists, they can log in and modify their contact information, such as address, phone number, and preferred language.
Users are arranged into groups , which represent collections of users. Groups can be arranged in any way: following the corporate organization chart, to reflect which parts of the infrastructure they are responsible for, or even alphabetically. Users can be members of any number of groups, so groups can be used to organize users as well as configure access permissions.
There are several built in pseudo-groups, such as Everyone and Owner, which are defined under certain circumstances. These pseudo-groups are symbolic, and let the RT administrator assign special rights to users who have a specific relationship to a ticket. For example, the Owner pseudo-group might be the only one with the rights to close a ticket. Because the owner of a ticket might change over time, using this pseudo-group saves the administrator from having to write custom scrips to allow ticket resolution.
A principal is an entity capable of having access control applied to it, such as a user or group. Groups in RT must consist of principals, which means that a group can contain other groups, in addition to containing users. This allows the RT administrator fine-grained and flexible control over users.
RT has a rich authorization schema, based on Access Control Lists (ACLs). ACLs provide fine-grained control over what a user can and cannot do at the ticket, queue, group, and global levels. Rights can be granted by an administrator to specific users, groups, or roles—such as requestor, owner, or admin cc at the ticket—in which case what a user is allowed to do is a combination of user, group, and role ACLs. Access control is covered in more detail in Chapter 5, Administrative Tasks.