ManualIntroduction - Revision history

Maureen at 20:33, 28 March 2019

2019-03-28T20:33:43Z

← Older revision		Revision as of 16:33, 28 March 2019
Line 70:		Line 70:
	Up: [[UserManual]] --- Next: [[ManualRequirements]]		Up: [[UserManual]] --- Next: [[ManualRequirements]]
	[[Category:RT User Manual]]		[[Category:RT User Manual]]
			[[Category:RT44]]

Jbrandt at 15:35, 20 March 2019

2019-03-20T15:35:34Z

← Older revision		Revision as of 11:35, 20 March 2019
Line 13:		Line 13:
	= About RT =		= About RT =

	RT is a ticketing system for all sizes of organizations. It is available under the terms of the GNU General Public License (GPL), so it doesn't cost anything to set up and use. We'll get into the technical features later, but for now, let's look at how RT might work:		RT is a ticketing system for all sizes of organizations. It is available under the terms of the GNU General Public License (GPL), so it doesn't cost anything to set up and use. Managed hosting plans and commercial support are also available from [https://bestpractical.com Best Practical Solutions]. We'll get into the technical features later, but for now, let's look at how RT might work:

	* Billy has a problem with his Bananamaster 3000, so he sends email to help@example.com		* Billy has a problem with his Bananamaster 3000, so he sends email to help@example.com

Maureen at 15:57, 19 March 2019

2019-03-19T15:57:10Z

← Older revision		Revision as of 11:57, 19 March 2019
Line 9:		Line 9:
	Ticketing can make life easier for many people and departments in an organization -- basically anyone who needs to keep track of a list of tasks. And it can be used with a variety of tasks, like fixing software bugs, answering customer service requests, or tracking security issues.		Ticketing can make life easier for many people and departments in an organization -- basically anyone who needs to keep track of a list of tasks. And it can be used with a variety of tasks, like fixing software bugs, answering customer service requests, or tracking security issues.

	Tickets can be a simple record of work done, like "Applied software patches on server," or detailed records with many custom fields and a long history. How you use tickets in RT will depend on your use case and can differ from queue to queue. Whatever your approach, it's good to communicate with users so everyone ~~understand~~ why and how they should interact with the system.		Tickets can be a simple record of work done, like "Applied software patches on server," or detailed records with many custom fields and a long history. How you use tickets in RT will depend on your use case and can differ from queue to queue. Whatever your approach, it's good to communicate with users so everyone understands why and how they should interact with the system.

	= About RT =		= About RT =

Jbrandt at 14:47, 19 March 2019

2019-03-19T14:47:15Z

Admin: 5 revisions imported

2016-04-06T20:14:29Z

5 revisions imported

New page

Up: [[UserManual]] --- Next: [[ManualRequirements]]

Welcome to Request Tracker(RT), your new favorite ticketing system. This introductory chapter will explain what ticketing is and what RT is. If you're already familiar with RT, you can skip ahead to another chapter.

= About Ticketing =

When people say "ticketing," they're talking about buying a stub of paper that gets them into an event. Our type of ticketing is a way for organizations to keep track of their to-do lists, who is working on which tasks, what's already been done, and when tasks were completed. You will also hear the phrase "trouble ticketing" bandied about, though there does not have to be a problem for ticketing to be useful. The current common phrase seems to be "issue tracking".

Ticketing can make life easier for many people and departments in an organization -- basically anyone who needs to keep track of a list of tasks. And it can be used with a variety of tasks, like fixing software bugs and answering customer service requests.

Since tickets are detailed records, you might not want to bother using it for one-off events ("Buy Bob in HR a going-away present.") You also shouldn't use it for tasks that are too broad ("Save world") or too granular ("Go to phone." "Pick up phone" "Lift finger." "Dial '9.'")

= About RT =

RT is a ticketing system for all sizes of organizations. It is available under the terms of the GNU General Public License (GPL), so it doesn't cost anything to set up and use. We'll get into the technical features later, but for now, let's look at how RT might work:

* Billy has a problem with his Bananamaster 3000, so he sends email to help@example.com
* RT records the new issue in its database and sends Billy an electronic "ticket stub" containing the new ticket's ID number and, ideally, some helpful information. He can refer to the ticket stub if he needs to send another email later.
* RT forwards Billy's email to a set of staff members.
* One of the staff members, Jane, is the company's Bananamaster expert. So Jane takes over Billy's issue and drafts a reply to Billy, which RT automatically records and forwards to him.
* Billy is a happy customer; Jane resolves the issue and heads down to the pub for a pint.

This workflow is flexible, can be customized for your organization, and need not involve bananas.

= RT concepts =

There are some words and phrases you should understand in the context of RT before you begin. See [[RTGlossary]] for more definitions.

A [[Ticket]] is the central object in RT, the thing that needs to get done. Tickets have metadata attached to them such as an owner, status, and queue - we'll get to all that in a minute.

A [[Queue]] is the central administrative domain of RT; it keeps things organized. As the name implies, it's a line of tickets waiting to be worked on, but it's also, to some extent, the ticket's category. 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.

A ticket's history is what it sounds like: everything that's happened to a ticket. Facets of ticket history could include 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 (at least not without messing up the space-time continuum), so be aware that any comments you make about a ticket are permanent.

Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff 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, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. By setting a final priority, you can make a ticket's priority increase or decrease as its due date draws closer. The difference between 20, 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. [[ManualAdministration]] contains a useful model for setting organizational policy for priority.

The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:

* NEW: the ticket has just been created and hasn't been touched yet.
* OPEN: the ticket is getting worked on
* STALLED: 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.
* RESOLVED: hooray! Work on the ticket has been completed and is out of everyone's hair.
* REJECTED: 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.
* DELETED: the ticket never should have been in the system (maybe it was spam, a list of passwords, etc) -- and is now being zapped for good.

A watcher is someone who is interested in a ticket. You'll find these filed under "People" when you're looking at a ticket. A watcher of a ticket normally gets email-copies of all the replies to the ticket. The watchers who are staff-members get copies of the comments too. There are several types, or roles, of watchers:

* OWNER: the person responsible for the ticket and its resolution. Each ticket can have only one owner. As a ticket is worked on, it may be passed from one owner to another.
* REQUESTOR: the person or people who asked for something to get done; the ticket's reason for being. The Requestor normally gets copies of all replies to the ticket, but no comments.
* CC: someone (or someones) 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 emails but doesn't necessarily have the right to work on the ticket.
* ADMINCC: a Cc or Ccs that also gets copies of '''comments''' and generally are allowed to work on the ticket.

We're hedging with words like "generally" and "necessarily" because any role can be assigned any right.

You can also, as you work on a ticket, define its relationship to something. Relationships in RT can be ticket-to-ticket, but can also link tickets to external items like URLs or FedEx shipping numbers. For the sake of simplicity, we'll refer only to tickets in the following explanation of relationship types:

* DEPENDS ON: the ticket can't be resolved unless another ticket is also resolved. The converse is depended on by.
* REFERS TO: 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.
* PARENT: a big, general ticket ("Move house.")
* CHILD: a subproject of a parent ("Hire movers." "Pack." "Eat pizza.")

[[CustomField]]s are, yes, database fields that your organization can make up according to its needs. For details, see the Custom Fields section in [[ManualAdministration]]. An example custom field might be '''Resolution''': FIXED, WORKSFORME, WONTFIX, UPSTREAM, etc, etc... (If you think that example was stolen from Bugzilla, you have much to go on :-)

[[Scrip]]s are custom notifications that will automatically take Action X in response to Condition Y. You could have RT notify the Requestor when a ticket is resolved, for instance, or have RT page you when your boss submits a request. RT comes with many standard scrips, and you can define your own. For details, see the Scrips section in [[ManualAdministration]]. And no, we didn't misspell "scripts." We made up a new word. Try it, it's fun.

Now that you are (we hope) clear on the concepts, you're ready to start using RT.

Up: [[UserManual]] --- Next: [[ManualRequirements]]
[[Category:RT User Manual]]

216.52.119.99 at 13:47, 5 December 2011

2011-12-05T13:47:51Z

← Older revision		Revision as of 09:47, 5 December 2011
Line 35:		Line 35:
	Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff 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."		Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff 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, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. By setting a final priority, you can make a ticket's priority increase or decrease as its due date draws closer. The difference between 20. 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. [[ManualAdministration]] contains a useful model for setting organizational policy for priority.		Priority, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. By setting a final priority, you can make a ticket's priority increase or decrease as its due date draws closer. The difference between 20, 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. [[ManualAdministration]] contains a useful model for setting organizational policy for priority.

	The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:		The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:
Line 48:		Line 48:
	A watcher is someone who is interested in a ticket. You'll find these filed under "People" when you're looking at a ticket. A watcher of a ticket normally gets email-copies of all the replies to the ticket. The watchers who are staff-members get copies of the comments too. There are several types, or roles, of watchers:		A watcher is someone who is interested in a ticket. You'll find these filed under "People" when you're looking at a ticket. A watcher of a ticket normally gets email-copies of all the replies to the ticket. The watchers who are staff-members get copies of the comments too. There are several types, or roles, of watchers:

	* OWNER: the person responsible for the ticket and its resolution. Each ticket can have only one owner. As a ticket it worked on, it may be passed from one owner to another.		* OWNER: the person responsible for the ticket and its resolution. Each ticket can have only one owner. As a ticket is worked on, it may be passed from one owner to another.
	* REQUESTOR: the person or people who asked for something to get done; the ticket's reason for being. The Requestor normally gets copies of all replies to the ticket, but no comments.		* REQUESTOR: the person or people who asked for something to get done; the ticket's reason for being. The Requestor normally gets copies of all replies to the ticket, but no comments.
	* CC: someone (or someones) 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 emails but doesn't necessarily have the right to work on the ticket.		* CC: someone (or someones) 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 emails but doesn't necessarily have the right to work on the ticket.

BillCole: Adding categories

2010-12-22T23:33:08Z

Adding categories

New page

Up: [[UserManual]] --- Next: [[ManualRequirements]]

Welcome to Request Tracker(RT), your new favorite ticketing system. This introductory chapter will explain what ticketing is and what RT is. If you're already familiar with RT, you can skip ahead to another chapter.

= About Ticketing =

When people say "ticketing," they're talking about buying a stub of paper that gets them into an event. Our type of ticketing is a way for organizations to keep track of their to-do lists, who is working on which tasks, what's already been done, and when tasks were completed. You will also hear the phrase "trouble ticketing" bandied about, though there does not have to be a problem for ticketing to be useful. The current common phrase seems to be "issue tracking".

Ticketing can make life easier for many people and departments in an organization -- basically anyone who needs to keep track of a list of tasks. And it can be used with a variety of tasks, like fixing software bugs and answering customer service requests.

Since tickets are detailed records, you might not want to bother using it for one-off events ("Buy Bob in HR a going-away present.") You also shouldn't use it for tasks that are too broad ("Save world") or too granular ("Go to phone." "Pick up phone" "Lift finger." "Dial '9.'")

= About RT =

RT is a ticketing system for small- to medium-sized organizations. It is available under the terms of the GNU General Public License (GPL), so it doesn't cost anything to set up and use. We'll get into the technical features later, but for now, let's look at how RT might work:

* Billy has a problem with his Bananamaster 3000, so he sends email to help@example.com
* RT records the new issue in its database and sends Billy an electronic "ticket stub" containing the new ticket's ID number and, ideally, some helpful information. He can refer to the ticket stub if he needs to send another email later.
* RT forwards Billy's email to a set of staff members.
* One of the staff members, Jane, is the company's Bananamaster expert. So Jane takes over Billy's issue and drafts a reply to Billy, which RT automatically records and forwards to him.
* Billy is a happy customer; Jane resolves the issue and heads down to the pub for a pint.

This workflow is flexible, can be customized for your organization, and need not involve bananas.

= RT concepts =

There are some words and phrases you should understand in the context of RT before you begin. See [[RTGlossary]] for more definitions.

A [[Ticket]] is the central object in RT, the thing that needs to get done. Tickets have metadata attached to them such as an owner, status, and queue - we'll get to all that in a minute.

A [[Queue]] is the central administrative domain of RT; it keeps things organized. As the name implies, it's a line of tickets waiting to be worked on, but it's also, to some extent, the ticket's category. 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.

A ticket's history is what it sounds like: everything that's happened to a ticket. Facets of ticket history could include 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 (at least not without messing up the space-time continuum), so be aware that any comments you make about a ticket are permanent.

Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff 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, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. By setting a final priority, you can make a ticket's priority increase or decrease as its due date draws closer. The difference between 20. 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. [[ManualAdministration]] contains a useful model for setting organizational policy for priority.

The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:

* NEW: the ticket has just been created and hasn't been touched yet.
* OPEN: the ticket is getting worked on
* STALLED: 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.
* RESOLVED: hooray! Work on the ticket has been completed and is out of everyone's hair.
* REJECTED: 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.
* DELETED: the ticket never should have been in the system (maybe it was spam, a list of passwords, etc) -- and is now being zapped for good.

A watcher is someone who is interested in a ticket. You'll find these filed under "People" when you're looking at a ticket. A watcher of a ticket normally gets email-copies of all the replies to the ticket. The watchers who are staff-members get copies of the comments too. There are several types, or roles, of watchers:

* OWNER: the person responsible for the ticket and its resolution. Each ticket can have only one owner. As a ticket it worked on, it may be passed from one owner to another.
* REQUESTOR: the person or people who asked for something to get done; the ticket's reason for being. The Requestor normally gets copies of all replies to the ticket, but no comments.
* CC: someone (or someones) 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 emails but doesn't necessarily have the right to work on the ticket.
* ADMINCC: a Cc or Ccs that also gets copies of '''comments''' and generally are allowed to work on the ticket.

We're hedging with words like "generally" and "necessarily" because any role can be assigned any right.

You can also, as you work on a ticket, define its relationship to something. Relationships in RT can be ticket-to-ticket, but can also link tickets to external items like URLs or FedEx shipping numbers. For the sake of simplicity, we'll refer only to tickets in the following explanation of relationship types:

* DEPENDS ON: the ticket can't be resolved unless another ticket is also resolved. The converse is depended on by.
* REFERS TO: 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.
* PARENT: a big, general ticket ("Move house.")
* CHILD: a subproject of a parent ("Hire movers." "Pack." "Eat pizza.")

[[CustomField]]s are, yes, database fields that your organization can make up according to its needs. For details, see the Custom Fields section in [[ManualAdministration]]. An example custom field might be '''Resolution''': FIXED, WORKSFORME, WONTFIX, UPSTREAM, etc, etc... (If you think that example was stolen from Bugzilla, you have much to go on :-)

[[Scrip]]s are custom notifications that will automatically take Action X in response to Condition Y. You could have RT notify the Requestor when a ticket is resolved, for instance, or have RT page you when your boss submits a request. RT comes with many standard scrips, and you can define your own. For details, see the Scrips section in [[ManualAdministration]]. And no, we didn't misspell "scripts." We made up a new word. Try it, it's fun.

Now that you are (we hope) clear on the concepts, you're ready to start using RT.

Up: [[UserManual]] --- Next: [[ManualRequirements]]
[[Category:RT User Manual]]

← Older revision		Revision as of 10:47, 19 March 2019
Line 1:		Line 1:
	Up: [[UserManual]] --- Next: [[ManualRequirements]]		Up: [[UserManual]] --- Next: [[ManualRequirements]]

	Welcome to Request Tracker(RT), your new favorite ticketing system. This ~~introductory chapter will explain~~ what ticketing is and what RT is. If you're already familiar with RT, you can skip ahead ~~to another chapter~~.		Welcome to Request Tracker (RT), your new favorite ticketing system. This introduction explains what ticketing is and what RT is. If you're already familiar with RT, you can skip ahead.

	= About Ticketing =		= About Ticketing =

	~~When~~ people ~~say~~ "~~ticketing~~," they're talking about ~~buying~~ a ~~stub~~ of paper that gets them into an event. ~~Our~~ type of ticketing is a way for organizations to keep track of their to-do lists, who is working on which tasks, what's already been done, and when tasks were completed. You will also hear the phrase "trouble ticketing" bandied about, though there does not have to be a problem for ticketing to be useful. ~~The current common phrase seems to be~~ "~~issue~~ tracking".		In some contexts, when people think about a "ticket," they're talking about a code on their phone or a physical piece of paper that gets them into an event or on an airplane for a flight. The RT type of ticketing is a way for organizations to keep track of their to-do lists, who is working on which tasks, what's already been done, and when tasks were completed. You will also hear the phrase "trouble ticketing" bandied about, though there does not have to be a problem for ticketing to be useful. "Issue tracking" is another common phrase used for general ticketing.

	Ticketing can make life easier for many people and departments in an organization -- basically anyone who needs to keep track of a list of tasks. And it can be used with a variety of tasks, like fixing software bugs ~~and~~ answering customer service requests.		Ticketing can make life easier for many people and departments in an organization -- basically anyone who needs to keep track of a list of tasks. And it can be used with a variety of tasks, like fixing software bugs, answering customer service requests, or tracking security issues.

	~~Since tickets are~~ detailed records, you ~~might not want to bother using it for one-off events ("Buy Bob~~ in ~~HR a going-away present.") You also shouldn't~~ use ~~it for tasks that are too broad ("Save world") or too granular ("Go~~ to ~~phone~~.~~" "Pick up phone" "Lift finger." "Dial~~ '9.~~'")~~		Tickets can be a simple record of work done, like "Applied software patches on server," or detailed records with many custom fields and a long history. How you use tickets in RT will depend on your use case and can differ from queue to queue. Whatever your approach, it's good to communicate with users so everyone understand why and how they should interact with the system.

	= About RT =		= About RT =
Line 31:		Line 31:
	A [[Queue]] is the central administrative domain of RT; it keeps things organized. As the name implies, it's a line of tickets waiting to be worked on, but it's also, to some extent, the ticket's category. 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.		A [[Queue]] is the central administrative domain of RT; it keeps things organized. As the name implies, it's a line of tickets waiting to be worked on, but it's also, to some extent, the ticket's category. 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.

	A ticket's history is what it sounds like: everything that's happened to a ticket. Facets of ticket history could include 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 ~~(at least not without messing up~~ the ~~space-time continuum), so~~ be ~~aware that any comments you make about a ticket are permanent~~.		A ticket's history is what it sounds like: everything that's happened to a ticket. Facets of ticket history could include when the ticket was created, how it has changed, and any comments about it or replies to it. Like real history, ticket history typically is not changed. However, new laws related to user privacy like [https://docs.bestpractical.com/rt/latest/GDPR.html GDPR] in the EU require some organizations to evaluate their auditing policies and decide how to handle requests to remove personal user data. This can require ticket data to be modified or removed completely.

	Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff 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."		Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff 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, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. By setting a final priority, you can make a ticket's priority increase or decrease as its due date draws closer. The difference between 20, 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. [[ManualAdministration]] contains a useful model for setting organizational policy for priority.		Priority, how important a ticket is, is represented as numerical scale from 0-99, with 99 being the highest priority. By setting a final priority, you can make a ticket's priority increase or decrease as its due date draws closer. The difference between 20, 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. [[ManualAdministration]] contains a useful model for setting organizational policy for priority. You can also install the [https://metacpan.org/pod/RT::Extension::PriorityAsString PriorityAsString] extension to manage priority with terms like "high" and "low".

	The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:		The status drop-down menu offers several choices for classifying each ticket. Here's what they mean:

	* ~~NEW~~: the ticket has just been created and hasn't been touched yet.		* new: the ticket has just been created and hasn't been touched yet.
	* ~~OPEN~~: the ticket is getting worked on		* open: the ticket is getting worked on
	* ~~STALLED~~: 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.		* stalled: 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.
	* ~~RESOLVED~~: hooray! Work on the ticket has been completed and is out of everyone's hair.		* resolved: hooray! Work on the ticket has been completed and is out of everyone's hair.
	* ~~REJECTED~~: 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.		* rejected: 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.
	* ~~DELETED~~: the ticket never should have been in the system (maybe it was spam, a list of passwords, etc) -- and is now being zapped for good.		* deleted: the ticket never should have been in the system (maybe it was spam, a list of passwords, etc) -- and is now being zapped for good.

	A watcher is someone who is interested in a ticket. You'll find these filed under "People" when you're looking at a ticket. A watcher of a ticket normally gets email-copies of all the replies to the ticket. The watchers who are staff-members get copies of the comments too. There are several types, or roles, of watchers:		A watcher is someone who is interested in a ticket. You'll find these filed under "People" when you're looking at a ticket. A watcher of a ticket normally gets email-copies of all the replies to the ticket. The watchers who are staff-members get copies of the comments too. There are several types, or roles, of watchers:

	* ~~OWNER~~: the person responsible for the ticket and its resolution. Each ticket can have only one owner. As a ticket is worked on, it may be passed from one owner to another.		* Owner: the person responsible for the ticket and its resolution. Each ticket can have only one owner. As a ticket is worked on, it may be passed from one owner to another.
	* ~~REQUESTOR~~: the person or people who asked for something to get done; the ticket's reason for being. The Requestor normally gets copies of all replies to the ticket, but no comments.		* Requestor: the person or people who asked for something to get done; the ticket's reason for being. The Requestor normally gets copies of all replies to the ticket, but no comments.
	* CC: someone (or someones) 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 emails but doesn't necessarily have the right to work on the ticket.		* Cc: someone (or someones) 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 emails but doesn't necessarily have the right to work on the ticket.
	* ~~ADMINCC~~: a Cc or Ccs that also gets copies of '''comments''' and generally are allowed to work on the ticket.		* AdminCc: a Cc or Ccs that also gets copies of '''comments''' and generally are allowed to work on the ticket.

	We're hedging with words like "generally" and "necessarily" because any role can be assigned any right.		We're hedging with words like "generally" and "necessarily" because any role can be assigned any right.
Line 62:		Line 62:
	* CHILD: a subproject of a parent ("Hire movers." "Pack." "Eat pizza.")		* CHILD: a subproject of a parent ("Hire movers." "Pack." "Eat pizza.")

	[[CustomField]]s are, yes, database fields that your organization can make up according to its needs. For details, see the Custom Fields section in [[ManualAdministration]]. An example custom field might be '''Resolution''': FIXED, WORKSFORME, WONTFIX, UPSTREAM~~, etc~~, etc.~~.. (If you think that example was stolen from Bugzilla, you have much to go on :-)~~		[[CustomField]]s are, yes, database fields that your organization can make up according to its needs. For details, see the Custom Fields section in [[ManualAdministration]]. An example custom field might be '''Resolution''': FIXED, WORKSFORME, WONTFIX, UPSTREAM, etc.

	[[Scrip]]s are custom ~~notifications~~ that will automatically take Action X in response to Condition Y. You could have RT notify the Requestor when a ticket is resolved, for instance, or have RT page you when your boss submits a request. RT comes with many standard scrips, and you can define your own. For details, see the Scrips section in [[ManualAdministration]]. And no, we didn't misspell "scripts." We made up a new word. Try it, it's fun.		[[Scrip]]s are custom events that will automatically take Action X in response to Condition Y. You could have RT notify the Requestor when a ticket is resolved, for instance, or have RT page you when your boss submits a request. RT comes with many standard scrips, and you can define your own. For details, see the Scrips section in [[ManualAdministration]]. And no, we didn't misspell "scripts." We made up a new word. Try it, it's fun.

	Now that you are (we hope) clear on the concepts, you're ready to start using RT.		Now that you are (we hope) clear on the concepts, you're ready to start using RT.