diff options
| author | Jesse Vincent <jesse@bestpractical.com> | 1999-04-03 03:57:00 +0400 |
|---|---|---|
| committer | Jesse Vincent <jesse@bestpractical.com> | 1999-04-03 03:57:00 +0400 |
| commit | 4a816ef9ec981c6371673c9666a00135c6005851 (patch) | |
| tree | 21069a5ce674bd1c0a242a63529ec6afa99955a7 | |
| parent | 95d2d98fbdabf9ebebfe5f2a45f02950e7521852 (diff) | |
major update of the docs from adam.rt-0.99.5
| -rwxr-xr-x | NEWS | 9 | ||||
| -rwxr-xr-x | docs/FAQ | 30 | ||||
| -rwxr-xr-x | docs/FAQ.html | 40 | ||||
| -rwxr-xr-x | docs/README.docs | 2 | ||||
| -rwxr-xr-x | docs/actions.html | 171 | ||||
| -rwxr-xr-x | docs/actions.txt | 235 | ||||
| -rwxr-xr-x | docs/admin.html | 108 | ||||
| -rwxr-xr-x | docs/admin.txt | 178 | ||||
| -rwxr-xr-x | docs/attributes.html | 171 | ||||
| -rwxr-xr-x | docs/attributes.txt | 218 | ||||
| -rwxr-xr-x | docs/outline.html | 200 | ||||
| -rwxr-xr-x | docs/outline.txt | 240 |
12 files changed, 1158 insertions, 444 deletions
@@ -1,3 +1,12 @@ +2 apr 99 +-------- +Updated makefile. +you must now specify the mysql root password in the makefile if one exists. + +Added new docs from adam@baz.org + +released .99.5 + 21 mar 99 --------- Updated readme: diff --git a/docs/FAQ b/docs/FAQ new file mode 100755 index 0000000000..e997d76374 --- /dev/null +++ b/docs/FAQ @@ -0,0 +1,30 @@ + + FAQ + + what should RT_MAIL_TAG be, and why? + + RT_MAIL_TAG should be a unique site/install identifier. Every + piece of mail which that RT sends out, regardless of Queue or + Area, will have that token put onto the subject line, i.e. + "Subject: [circus #8799] Too Many Monkeys!" (in this case, the + RT_MAIL_TAG is "circus." + + Sends OUT? What about receives? the makefile implies that it's needed + on + + incoming mail, as well. + + every piece of mail that it's supposed to parse correctly and + add to an existing ticket will need that token as well. + + Where? Anyplace, in the body of the request, or some other special + place? + + On the subject line. + + If they are going to have 2 seperate queues, one for internal IT and + one for servers accessed from outside sources, will everyone + use the same MAIL_TAG? + yes. the same tag and the same ordinal system across both + queues. (i.e. req's 4, 5, and 6 are in queue Foo. The next + person to open a req in queue Bar will get given number 7.) diff --git a/docs/FAQ.html b/docs/FAQ.html new file mode 100755 index 0000000000..63a537c371 --- /dev/null +++ b/docs/FAQ.html @@ -0,0 +1,40 @@ +<html> +<head> +<title> +FAQ +</title> +</head> +<body bgcolor="#ffffff"> +<img WIDTH="169" HEIGHT="121" src="rt.gif" alt=""> +<h3>FAQ </h3> + +<dl> + +<dt><strong>what should RT_MAIL_TAG be, and why?</strong> +<p> + +<dd> RT_MAIL_TAG should be a unique site/install identifier. + Every piece of mail which that RT sends out, regardless of Queue or Area, + will have that token put onto the subject line, i.e. + "Subject: [circus #8799] Too Many Monkeys!" + (in this case, the RT_MAIL_TAG is "circus." + +<dt><strong>Sends OUT? What about receives? the makefile implies that it's needed on</strong> +<p> +incoming mail, as well. + +<dd> every piece of mail that it's supposed to parse correctly and add to + an existing ticket will need that token as well. + +<dt><strong>Where? Anyplace, in the body of the request, or some other special place?</strong> +<p> + +<dd> On the subject line. + +<dt><strong>If they are going to have 2 seperate queues, one for internal IT and one for servers accessed from outside sources, will everyone use the same MAIL_TAG?</strong> + +<dd> yes. the same tag and the same ordinal system across both queues. (i.e. + req's 4, 5, and 6 are in queue Foo. The next person to open a req in queue + Bar will get given number 7.) + + </dl> diff --git a/docs/README.docs b/docs/README.docs index 434022a64b..d02196ecd6 100755 --- a/docs/README.docs +++ b/docs/README.docs @@ -1,4 +1,4 @@ -Documentation for RT is being written by Adam Hirsch <adam@apocalypse.org> +Documentation for RT is being written by Adam Hirsch <adam@baz.org> It is in the very early stages, but it's more functional than nothing. There may be some errors. please send mail to rt-devel@lists.fsck.com with anything you find to be in error. diff --git a/docs/actions.html b/docs/actions.html new file mode 100755 index 0000000000..40891d6bd1 --- /dev/null +++ b/docs/actions.html @@ -0,0 +1,171 @@ +<html> +<head> +<title> +Actions +</title> +</head> +<body bgcolor="#ffffff"> +<img WIDTH="169" HEIGHT="121" src="rt.gif" alt=""> +<h3>Actions </h3> + +<h3>Actions on a Request</h3> + +All of the following actions are only available to you if you have +Manipulate privileges or higher on a given Queue. + +<dt><strong> Comment </strong> +<p> + +<dd>For a given Queue, anyone with Manipulate privileges or higher may Comment +on a Request. Commenting is the most common way to update a Request. It +adds a Transaction and may or may not (depending on how the Queue is +configured) automatically send mail to the Requestor or the Queue members. +It is intended to be used for "internal" correspondence that is not sent to +the user. Comments would only be sent to the requestor at installations which +have enabled "Notify User on Action" which is not recommended, because of the +sheer volume of mail involved. + +<p> + +<dt><strong> Reply</strong> +<p> + +<dd>Replying to a Request does much the same thing as Commenting on it does, but +it also explicitly sends email to the Requestor, regardless of how the Queue +is configured. &RT& will note the time of this communication in the "Last +User Contact" field. + +<p> + +<dt><strong> Take </strong> +<p> + +<dd>Taking a Request assigns it to the Taker. Their ID goes into the Owner +field. You may only Take a Request if it is unowned -- if someone else +already Owns the Request, you have to Steal it from them to gain Ownership. + +<p> + +<dt><strong> Untake </strong> +<p> + +<dd>Untaking a Request removes your name from the Assigned field, making the +Request un-Owned again. Useful in cases where you've Taken the wrong +Request, or you've become overburdened, underinformed, fired, reassigned, +amnesiac, promoted, or something else. + +<p> + +<dt><strong> Steal</strong> +<p> + +<dd>Stealing a Request re-assigns an already Owned request to you, instead of to +its current Owner. Useful in cases where the original Owner (as compared to +you) has become overburdened, underinformed, fired, reassigned, amnesiac, +promoted, or something else. + +<p> + +<dt><strong> Give</strong> +<p> + +<dd>Assign a Request to someone else, and remove yourself from the Assigned +field. + +<p> + +<dt><strong> Notify Requestor</strong> +<p> + +<dd>Tells &RT& that somehow, the person who made the original Request has been +contacted. Automatically tagged when someone uses the Reply function, +rather than simply Commenting. Useful when trying to measure the +reponse-time back to users. <tt>(##JRV## accurate? AH: yep)</tt> + +<blockquote> + EX: While standing at the buffet, Charlie notices he's standing elbow to + elbow with Biff, who sent in a Request that morning. Charlie tells Biff + that he may wish to untoggle his caps lock key if he wants man pages to + work for him. Biff walks away pleased, and after lunch, Charlie notes the + interaction in the Request, including the fact that the Requestor was + notified. Charlie's boss notices the fast turnaround time and rewards + Charlie with a large nerf weapon and permission to use it. +</blockquote> + +<p> + +<dt><strong> Change Subject</strong> +<p> + +<dd>You may edit the Subject line of a Request. Different than the +conversational tactic of the same name. + +<p> + +<dt><strong> Change Queue</strong> +<p> + +<dd>Move a Request from one Queue to another. You may move a request from any +queue you can manipulate into any queue you can create requests in. + +<p> + +<dt><strong> Change Area</strong> +<p> + +<dd>Assign a Request to a particular Area within a Queue. + +<p> + +<dt><strong> Change Status </strong> +<p> + +<dd>You may change the Status of a Request to one of the four possible States: +Open, Stalled, Resolved, or Dead. + +<blockquote> + + EX: The Sphinx asked this riddle of a traveller: What is Open in the + morning, Stalled in midday, Resolved by evening, and Dead by night? The + traveller responded, "Either metaphorically, Man, or literally, a + hyperactive Request." She was right, but the Sphinx ate her anyhow. +</blockquote> + +<p> + +<dt><strong> Change Requestor</strong> +<p> + +<dd>You may change the Requestor field if the Requestor or their email address +changes. + +<p> + +<dt><strong> Change Due Date</strong> +<p> + +<dd>You may change the Due Date to make it look like all of your requests are +getting done right on time. + +<p> + +<dt><strong> Change Priority</strong> +<p> + +<dd>You may change the current and/or Final Priority to reflect changes in the +Request's importance in the grand scheme of things. + +<p> + +<dt><strong> Merge Request</strong> +<p> + +<dd>If a user opens a Request that turns out to be redundant, or which contains +information more appropriate to continue an already open Request than to +start one anew, you may merge all the entirety of one Request into another. + +<tt>(##JRV## --> "Merge" may be something of a misnomer here, as the actual +action being performed is appending -- the Request being merged becomes the +newest transactions in the Request being merged into. +AH: no, the transactions are interleaved ##JRV## really? interleaved by +date, then? Cool.)</tt> diff --git a/docs/actions.txt b/docs/actions.txt index 64a8c78843..58c5458e17 100755 --- a/docs/actions.txt +++ b/docs/actions.txt @@ -1,117 +1,120 @@ -Actions on a Request -All of the following actions are only available to you if you have -Manipulate privileges or higher on a given Queue. - - - Comment - -For a given Queue, anyone with Manipulate privileges or higher may Comment -on a Request. Commenting is the most common way to update a Request. It -adds a Transaction and may or may not (depending on how the Queue is -configured) automatically send mail to the Requestor or the Queue members. -It is intended to be used for "internal" correspondence that is not sent to -the user. Comments would only be sent to the requestor at installations which -have enabled "Notify User on Action" which is not recommended, because of the -sheer volume of mail involved. - - - Reply - -Replying to a Request does much the same thing as Commenting on it does, but -it also explicitly sends email to the Requestor, regardless of how the Queue -is configured. &RT& will note the time of this -communication in the "Last User Contact" field. - - - Take - -Taking a Request assigns it to the Taker. Their ID goes into the Owner -field. You may only Take a Request if it is unowned -- if someone else -already Owns the Request, you have to Steal it from them to gain Ownership. - - - Untake - -Untaking a Request removes your name from the Assigned field, making the -Request un-Owned again. Useful in cases where you've Taken the wrong -Request, or you've become overburdened, underinformed, fired, reassigned, -amnesiac, promoted, or something else. - - - Steal - -Stealing a Request re-assigns an already Owned request to you, instead of to -its current Owner. Useful in cases where the original Owner (as compared to -you) has become overburdened, underinformed, fired, reassigned, amnesiac, -promoted, or something else. - - - Give - -Assign a Request to someone else, and remove yourself from the Assigned -field. - - - Notify Requestor - -Tells &RT& that somehow, the person who made the original Request has been -contacted. Automatically tagged when someone uses the Reply function, -rather than simply Commenting. Useful when trying to measure the -reponse-time back to users. (##JRV## accurate? AH: yep) - - EX: While standing at the buffet, Charlie notices he's standing elbow to - elbow with Biff, who sent in a Request that morning. Charlie tells Biff - that he may wish to untoggle his caps lock key if he wants man pages to - work for him. Biff walks away pleased, and after lunch, Charlie notes the - interaction in the Request, including the fact that the Requestor was - notified. Charlie's boss notices the fast turnaround time and rewards - Charlie with a nerf weapon and permission to use it. - - - Change Subject - -You may edit the Subject line of a Request. - - - Change Queue - -Move a Request from one Queue to another. (##JRV## Exact privileges -required in each Queue to do this? Manipulate? AH: You can move a request -from any queue you can manipulate to any queue you can create requests in. - -or do you have to be an RT -admin...? Will it ever be possible to have Requests belong to multiple -Queues, such that something could sit in a public queue and someone's -private queue at the same time? AH: no it won't be) - - - Change Area - -Assign a Request to a particular Area within a Queue. - - - Change Status - -You may change the Status of a Request to one of the four possible States: -Open, Stalled, Resolved, or Dead. - - EX: The Sphinx asked this riddle of a traveller: What is Open in the - morning, Stalled in midday, Resolved by evening, and Dead by night? The - traveller responded, "Either metaphorically, Man, or literally, a - hyperactive Request." She was right, but the Sphinx ate her anyhow. - - - Change Requestor - -You may change the Requestor field if the Requestor or their email address -changes. - - - Change Due Date - -You may change the Due Date, which may or may not be set automatically, -depending on Queue settings. (##JRV## correct? Due date is NOT SET -automatically.) - - - Change Priority - -You may change the current and/or Final Priority to reflect changes in the -Request's importance in the grand scheme of things. - - - Merge Request - -If a user opens a Request that turns out to be redundant, or which contains -information more appropriate to continue an already open Request than to -start one anew, you may merge all the entirety of one Request into another. -(##JRV## --> )"Merge" may be something of a misnomer here, as the actual -action being performed is appending -- the Request being merged becomes the -newest transactions in the Request being merged into. AH: no, the transactions -are interleaved) + Actions + + Actions on a Request + + All of the following actions are only available to you if you have + Manipulate privileges or higher on a given Queue. + + Comment + + For a given Queue, anyone with Manipulate privileges or higher may + Comment on a Request. Commenting is the most common way to update a + Request. It adds a Transaction and may or may not (depending on how + the Queue is configured) automatically send mail to the Requestor or + the Queue members. It is intended to be used for "internal" + correspondence that is not sent to the user. Comments would only be + sent to the requestor at installations which have enabled "Notify User + on Action" which is not recommended, because of the sheer volume of + mail involved. + + Reply + + Replying to a Request does much the same thing as Commenting on it + does, but it also explicitly sends email to the Requestor, regardless + of how the Queue is configured. &RT& will note the time of this + communication in the "Last User Contact" field. + + Take + + Taking a Request assigns it to the Taker. Their ID goes into the Owner + field. You may only Take a Request if it is unowned -- if someone else + already Owns the Request, you have to Steal it from them to gain + Ownership. + + Untake + + Untaking a Request removes your name from the Assigned field, making + the Request un-Owned again. Useful in cases where you've Taken the + wrong Request, or you've become overburdened, underinformed, fired, + reassigned, amnesiac, promoted, or something else. + + Steal + + Stealing a Request re-assigns an already Owned request to you, instead + of to its current Owner. Useful in cases where the original Owner (as + compared to you) has become overburdened, underinformed, fired, + reassigned, amnesiac, promoted, or something else. + + Give + + Assign a Request to someone else, and remove yourself from the + Assigned field. + + Notify Requestor + + Tells &RT& that somehow, the person who made the original Request has + been contacted. Automatically tagged when someone uses the Reply + function, rather than simply Commenting. Useful when trying to measure + the reponse-time back to users. (##JRV## accurate? AH: yep) + + EX: While standing at the buffet, Charlie notices he's standing + elbow to elbow with Biff, who sent in a Request that morning. + Charlie tells Biff that he may wish to untoggle his caps lock key + if he wants man pages to work for him. Biff walks away pleased, and + after lunch, Charlie notes the interaction in the Request, + including the fact that the Requestor was notified. Charlie's boss + notices the fast turnaround time and rewards Charlie with a large + nerf weapon and permission to use it. + + Change Subject + + You may edit the Subject line of a Request. Different than the + conversational tactic of the same name. + + Change Queue + + Move a Request from one Queue to another. You may move a request from + any queue you can manipulate into any queue you can create requests + in. + + Change Area + + Assign a Request to a particular Area within a Queue. + + Change Status + + You may change the Status of a Request to one of the four possible + States: Open, Stalled, Resolved, or Dead. + + EX: The Sphinx asked this riddle of a traveller: What is Open in + the morning, Stalled in midday, Resolved by evening, and Dead by + night? The traveller responded, "Either metaphorically, Man, or + literally, a hyperactive Request." She was right, but the Sphinx + ate her anyhow. + + Change Requestor + + You may change the Requestor field if the Requestor or their email + address changes. + + Change Due Date + + You may change the Due Date to make it look like all of your requests + are getting done right on time. + + Change Priority + + You may change the current and/or Final Priority to reflect changes in + the Request's importance in the grand scheme of things. + + Merge Request + + If a user opens a Request that turns out to be redundant, or which + contains information more appropriate to continue an already open + Request than to start one anew, you may merge all the entirety of one + Request into another. (##JRV## --> "Merge" may be something of a + misnomer here, as the actual action being performed is appending -- + the Request being merged becomes the newest transactions in the + Request being merged into. AH: no, the transactions are interleaved + ##JRV## really? interleaved by date, then? Cool.) diff --git a/docs/admin.html b/docs/admin.html new file mode 100755 index 0000000000..8c18ae521d --- /dev/null +++ b/docs/admin.html @@ -0,0 +1,108 @@ +<html> +<head> +<title> +Administrative Duties +</title> +</head> +<body bgcolor="#ffffff"> +<img WIDTH="169" HEIGHT="121" src="rt.gif" alt=""> +<h3>Administrative Duties</h3> + +<dl> +<dt><strong> What can I do as an RT administrator?</strong> +<p> +<dd> You can add, delete, or modify users, queues, areas, and access levels. + +<p> + +<dt><strong>What can I change about a User?</strong> +<p> + +<dd> If you are an &RT& Admin, you are allowed to directly change other + Users' setups. If you are not, you're only allowed to change your own. + <p> + + Usernames are unchangeable. If you've got to change it, you'll need + to create a new user with the new name and give them the same + permissions as you. + +<p> + You may change the email address associated with a User, their + password, phone number, office designation, and "misc" field which can + contain any information you'd like (full name, astrological sign, food + allergies, etc.). + +<p> + You may also give them "RT Admin" privileges, which will let them do + everything you can. + +<p> + +<dt><strong> What can I change about a Queue?</strong> +<p> + +<dd> the Mail Alias for a Queue, which is used in putting return addresses on + mail sent out regarding a particular queue. +<p> + the default Initial Priority for any Request started in the Queue. +<p> + the defaul Final Priority for such Requests. +<p> + Whether or not the Request Owner receives copies of every transactions + associated with that Request. +<p> + + <blockquote> + EX: Benny has taken charge of a large and thorny problem. + While she is the official Owner, she has delegated some of the research + necessary to solve the problem to other people. As they report their + findings into the Request, Benny would like to see them. She checks the + box marked "Mail request owner on transaction." + </blockquote> + + Whether or not Queue Members receive copies of every transaction that + happens in the Queue. +<p> + +<blockquote> +EX: Kee, Brian, and Moira all have Manipulate access to the +Queue "general," and all of them want to be kept appraised of what's going on +with other Requests therein, even those owned by one of the other two people. +</blockquote> + + Whether or not the Requestor will automatically receive any Transaction + having to do with their Request. +<p> + Whether or not &RT& will autoreply to someone who's just created a + Request, acknoledging their Request and letting them know the Request + Number. +<p> + Whether or not Queue Correspondence (that is, Transactions specifically + sent to the Requestor as well as added to the Request) gets mailed to + every Queue Member. +<p> + Whether or not Queue Comments (that is, Transactions meant to be added + to a Request and not explicitly sent to the Requestor) get mailed to + every Queue Member. +<p> + Whether or not non-Queue Members are allowed to create Requests. + Remember, someone with Display access is not considered a Queue Member. +<p> + +<blockquote> +EX: Marc wants all of his users to be able to mail in +Requests, but doesn't want to give them all Manipulate access to the Queue. +By checking the "Allow Non-Queue Members to create Requests" checkbox, he +allows them to create Requests, but leaves them all with only Display +privileges in the Queue, so that they can look at the Requests without being +able to screw them up. +</blockquote> + + Area Control -- If you have Administrative access to the Queue, you may + delete or create Areas within it. +<p> + Access Control -- If you have Administrative access to the Queue, you + may change other users' access levels within that Queue. + +</body> +</html> diff --git a/docs/admin.txt b/docs/admin.txt index 5a1a37fb08..593e51897e 100755 --- a/docs/admin.txt +++ b/docs/admin.txt @@ -1,95 +1,85 @@ - -What can I do as an RT administrator? -You can add, delete, or modify users, queues, areas, and access levels. - - -What can I change about a User? - - If you are an &RT& Admin, you are allowed to directly change other - Users' setups. If you are not, you're only allowed to change your own. - - Usernames are unchangeable. If you've got to change it, you'll need - to create a new user with the new name and give them the same - permissions as you. - - You may change the email address associated with a User, their - password, phone number, office designation - -User Configuration - - Username: adam - email: ______________________________ - password: _______________(leave blank unless you want to change) - phone: ______________________________ - office: ______________________________ - misc: ______________________________ - -Access Control - - RT Admin: [_] - _________________________________________________________________ - - DnA-Devel: [Display...] - Update User Delete this User Return to Admin Menu - - You are currently authenticated as adam. - Be careful not to leave yourself logged in from a public terminal - Please report all bugs to Jesse Vincent - - - -What can I change about a Queue? - - the Mail Alias for a Queue, which is used in putting return addresses on - mail sent out regarding a particular queue. - - the default Initial Priority for any Request started in the Queue. - - the defaul Final Priority for such Requests. - - Whether or not the Request Owner receives copies of every transactions - associated with that Request. - - EX: Benny has taken charge of a large and thorny problem. While she - is the official Owner, she has delegated some of the research - necessary to solve the problem to other people. As they report - their findings into the Request, Benny would like to see them. She - checks the box marked "Mail request owner on transaction." - - Whether or not Queue Members receive copies of every transaction that - happens in the Queue. - - EX: Kee, Brian, and Moira all have Manipulate access to the Queue - "general," and all of them want to be kept appraised of what's going - on with other Requests therein, even those owned by one of the other - two people. - - Whether or not the Requestor will automatically receive any Transaction - having to do with their Request. - - Whether or not &RT& will autoreply to someone who's just created a - Request, acknoledging their Request and letting them know the Request - Number. - - Whether or not Queue Correspondence (that is, Transactions specifically - sent to the Requestor as well as added to the Request) gets mailed to - every Queue Member. - - Whether or not Queue Comments (that is, Transactions meant to be added - to a Request and not explicitly sent to the Requestor) get mailed to - every Queue Member. - - Whether or not non-Queue Members are allowed to create Requests. - Remember, someone with Display access is not considered a Queue Member. - - EX: Marc wants all of his users to be able to mail in Requests, but - doesn't want to give them all Manipulate access to the Queue. By - checking the "Allow Non-Queue Members to create Requests" checkbox, he - allows them to create Requests, but leaves them all with only Display - privileges in the Queue, so that they can look at the Requests without - being able to screw them up. - - Area Control -- If you have Administrative access to the Queue, you may - delete or create Areas within it. - - Access Control -- If you have Administrative access to the Queue, you - may change other users' access levels within that Queue. (##JRV## - Nuances I'm missing here? AH: nope.) + Administrative Duties + + What can I do as an RT administrator? + + You can add, delete, or modify users, queues, areas, and access + levels. + + What can I change about a User? + + If you are an &RT& Admin, you are allowed to directly change + other Users' setups. If you are not, you're only allowed to + change your own. + + Usernames are unchangeable. If you've got to change it, you'll + need to create a new user with the new name and give them the + same permissions as you. + + You may change the email address associated with a User, their + password, phone number, office designation, and "misc" field + which can contain any information you'd like (full name, + astrological sign, food allergies, etc.). + + You may also give them "RT Admin" privileges, which will let + them do everything you can. + + What can I change about a Queue? + + the Mail Alias for a Queue, which is used in putting return + addresses on mail sent out regarding a particular queue. + + the default Initial Priority for any Request started in the + Queue. + + the defaul Final Priority for such Requests. + + Whether or not the Request Owner receives copies of every + transactions associated with that Request. + + EX: Benny has taken charge of a large and thorny problem. While she + is the official Owner, she has delegated some of the research + necessary to solve the problem to other people. As they report + their findings into the Request, Benny would like to see them. She + checks the box marked "Mail request owner on transaction." + + Whether or not Queue Members receive copies of every + transaction that happens in the Queue. + + EX: Kee, Brian, and Moira all have Manipulate access to the Queue + "general," and all of them want to be kept appraised of what's + going on with other Requests therein, even those owned by one of + the other two people. + + Whether or not the Requestor will automatically receive any + Transaction having to do with their Request. + + Whether or not &RT& will autoreply to someone who's just + created a Request, acknoledging their Request and letting them + know the Request Number. + + Whether or not Queue Correspondence (that is, Transactions + specifically sent to the Requestor as well as added to the + Request) gets mailed to every Queue Member. + + Whether or not Queue Comments (that is, Transactions meant to + be added to a Request and not explicitly sent to the Requestor) + get mailed to every Queue Member. + + Whether or not non-Queue Members are allowed to create + Requests. Remember, someone with Display access is not + considered a Queue Member. + + EX: Marc wants all of his users to be able to mail in Requests, but + doesn't want to give them all Manipulate access to the Queue. By + checking the "Allow Non-Queue Members to create Requests" checkbox, + he allows them to create Requests, but leaves them all with only + Display privileges in the Queue, so that they can look at the + Requests without being able to screw them up. + + Area Control -- If you have Administrative access to the Queue, + you may delete or create Areas within it. + + Access Control -- If you have Administrative access to the + Queue, you may change other users' access levels within that + Queue. diff --git a/docs/attributes.html b/docs/attributes.html new file mode 100755 index 0000000000..bcbc76c2a0 --- /dev/null +++ b/docs/attributes.html @@ -0,0 +1,171 @@ +<html> +<head> +<title> +Attributes +</title> +</head> +<body bgcolor="#ffffff"> + +<img WIDTH="169" HEIGHT="121" src="rt.gif" alt=""> +<h3>Attributes: a vocabulary</h3> + +<dl> +A Request has a number of attributes: + +<dd> +Serial Number, Queue, Area, Requestors, Owner, Subject, Final Priority, +Current Priority, Status, Created, Last User Contact, Last Contact, DueDate, +and Age. +<p> + +<dt><strong> What is the Serial Number?</strong> +<p> + +<dd> The Serial Number is a unique number within a given instance of RT used to +refer to that Request. They are not recycled. + +<p> + +<dt><strong> What is a Queue?</strong> +<p> + +<dd> A Queue is a grouping of Requests designated for a particular group of people +to access a/o address. Queues can have distinct access mechanisms, +permissions, responsible persons, and names. + +<blockquote> + EX: Sam E's Circus sets up &RT& to track issues. Issues regarding + setup and takedown go to the "roustabouts" queue, while issues + regarding food and drink sales go to the "concessions" queue. +</blockquote> + +<p> + +<dt><strong> What is an Area?</strong> +<p> + +<dd> An Area is used for further grouping Requests in a single Queue. The same +people will be responsible for the Requests, but will categorize them for the +sake of convenience. Areas can also have distinct access mechanisms (e.g. different mail aliases). Areas do not have ACLs seperate from those of the queue +they are a part of. + + <blockquote> + EX: The "concessions" area will have several Areas, including "cotton + candy," "popcorn," and "watered-down-soda." The same vendors will + be reading and addressing issues in all three of these areas, but will + be able to sort the incoming Requests on them. +</blockquote> + +<p> + +<dt><strong><strong> What is a Requestor?</strong></strong> +<p> + +<dd> A Requestor is the person who opens a Request by sending in the first +Transaction on the subject. &RT& has configurable options for keeping this +person automatically informed as to the progress of their request. + +<p> + +<dt><strong> What is an Owner?</strong> +<p> + +<dd> The Owner of a Request is the person who is taking responsibility for the +issue or question raised therein. They will very likely be the primary +person to make updates to the Request and change its state as it matures. + +<p> + +<dt><strong> What is the Subject?</strong> +<p> + +<dd> Much like the "Subject:" line in email, the Subject of a Request is a quick +summary of the question or issue raised in the first Transaction of the +Request. This may change as the Request matures. + +<p> + +<dt><strong> What is the Due Date?</strong> +<p> + +<dd> Setting a Due Date for a Request indicates the date by which point the owner of the Request expects (or wants, at any rate) the Request to be resolved. + +<p> + +<dt><strong> What is the Priority?</strong> +<p> + +<dd> A Request may optionally have a Priority set for it, which indicates its +urgency. Higher numbers indicate higher Priority. A Request may have no set +priority, may simply have its Priority set to a static number, or it may have +its Final Priority set. Final Priority requires a Due Date to operate +- as the Request gets closer to its Due Date, its current priority gets +higher. On <tt>(##JRV## day before? day of? AH: NO. final priority isn't +for real, yet. ##JRV## Oh? how d'you mean "not real"? )</tt> the final +day, its priority becomes the preset Final Priority. + +<blockquote> +EX: James Earl Jones creates a Request in July which will come due on + December 20th, to remind himself to get Solstice presents for his friends. + He sets the Final Priority of the Request to 95, knowing that as he gets + close to the time when he'll actually need to go shopping, the priority will + rise and bring this Request to his attention again. +</blockquote> + +<p> + +<dt><strong> What is a Request's Status?</strong> +<p> + +<dd> A Request will always be in one of the following four states: + +<p> +<blockquote> + Open -- the Request is expecting imminent action a/o updates +<br> + Stalled -- the Request needs a specific action or piece of + information before it can proceed +<br> +Resolved -- the Request has either been answered or successfully + taken care of, and no longer needs action +<br> + Dead -- the request should not have been in the ticketing system to begin + with and has been completely purged. +</blockquote> + +<p> + +<dt><strong> What is the Creation Date?</strong> +<p> + +<dd> The date the first Transaction of the Request was logged. (Duh.) + +<p> + +<dt><strong> What is the "Last User Contact"?</strong> +<p> + +<dd> &RT& can automatically inform the Requestor of any updates to the Request, +or someone updating the Request can optionally tag an update to be sent to +the Requestor. Either way, &RT& keeps track of when the most recent contact +with the Requestor <strong>through &RT&</strong> was. + +<p> + +<dt><strong> What is the "Last Contact"?</strong> +<p> + +<dd> The last logged update to the Request. <tt>(##JRV## this isn't quite +correct, I know. Clarification? AH: you're thinking of "Last modification" +it's the last time the req was touched)</tt> + +<p> + +<dt><strong> What is the "Age" of a Request?</strong> +<p> + +<dd> The amount of time elapsed since the first Transaction for this Request. +<tt>(AH: since the request was created..)</tt> + +</body> +</html> diff --git a/docs/attributes.txt b/docs/attributes.txt index 6e4de0adff..69379aa327 100755 --- a/docs/attributes.txt +++ b/docs/attributes.txt @@ -1,101 +1,119 @@ -A Request has a number of attributes: -Serial Number, Queue, Area, Requestors, Owner, Subject, Final Priority, -Current Priority, Status, Created, Last User Contact, Last Contact, DueDate, -and Age. - - - What is the Serial Number? - -The Serial Number is a unique number within a given instance of RT used to -refer to that Request. They are not recycled. - - - What is a Queue? - -A Queue is a grouping of Requests designated for a particular group of people -to access a/o address. Queues can have distinct access mechanisms, -permissions, responsible persons, and names. - - EX: Sam E's Circus sets up &RT& to track issues. Issues regarding - setup and takedown go to the "roustabouts" area, while issues - regarding food and drink sales go to the "concessions" area. - - - What is an Area? - -An Area is used for further grouping Requests in a single Queue. The same -people will be responsible for the Requests, but will categorize them for the -sake of convenience. Areas can also have distinct access mechanisms (e.g. different mail aliases). Areas do not have ACLs seperate from those of the queue -they are a part of. - - EX: The "concessions" area will have several areas, including "cotton - candy," "popcorn," and "watered-down-soda." The same vendors will - be reading and addressing issues in all three of these areas, but will - be able to sort the incoming Requests on them. - - - What is a Requestor? - -A Requestor is the person who opens a Request by sending in the first -Transaction on the subject. &RT& has configurable options for keeping this -person automatically informed as to the progress of their request. - - - What is an Owner? - -The Owner of a Request is the person who is taking responsibility for the -issue or question raised therein. They will very likely be the primary person to make updates to the Request and change its state as it matures. - - - What is the Subject? - -Much like the "Subject:" line in email, the Subject of a Request is a quick -summary of the question or issue raised in the first Transaction of the -Request. This may change as the Request matures. - - - What is the Due Date? - -Setting a Due Date for a Request indicates the date by which point the owner of the Request expects (or wants, at any rate) the Request to be resolved. - - - What is the Priority? - -A Request may optionally have a Priority set for it, which indicates its -urgency. Higher numbers indicate higher Priority. A Request may have no -set priority, may simply have its Priority set to a static number, or it may -have its Final Priority set. Final Priority requires a Due Date to operate --- as the Request gets closer to its Due Date, its current priority gets -higher. On (##JRV## day before? day of? AH: NO. final priority isn't for real, -yet. ) the final day, its priority becomes the preset Final Priority. - - EX: James Earl Jones creates a Request in July which will come due on - December 20th, to remind himself to get Solstice presents for his friends. - He sets the Final Priority of the Request to 95, knowing that as he gets - close to the time when he'll actually need to go shopping, the priority will - rise and bring this Request to his attention again. - - - What is a Request's Status? - -A Request will always be in one of the following four states: - - Open -- the Request is expecting imminent action a/o updates - Stalled -- the Request needs a specific action or piece of - information before it can proceed -Resolved -- the Request has either been answered or successfully - taken care of, and no longer needs action - Dead -- the request should not have been in the ticketing system to begin - with and has been completely purged. - - - What is the Creation Date? - -The date the first Transaction of the Request was logged. (Duh.) - - - What is the "Last User Contact"? - -&RT& can automatically inform the Requestor of any updates to the Request, -or someone updating the Request can optionally tag an update to be sent to -the Requestor. Either way, &RT& keeps track of when the most recent contact -with the Requestor *through*&RT&* was. - - - What is the "Last Contact"? - -The last logged update to the Request. (##JRV## this isn't quite correct, I know. Clarification? AH: you're thinking of "Last modification" it's the last time the req was touched) - - - What is the "Age" of a Request? - -The amount of time elapsed since the first Transaction for this Request. (AH: -since the request was created..) + Attributes: a vocabulary + + A Request has a number of attributes: + Serial Number, Queue, Area, Requestors, Owner, Subject, Final + Priority, Current Priority, Status, Created, Last User Contact, + Last Contact, DueDate, and Age. + + What is the Serial Number? + + The Serial Number is a unique number within a given instance of + RT used to refer to that Request. They are not recycled. + + What is a Queue? + + A Queue is a grouping of Requests designated for a particular + group of people to access a/o address. Queues can have distinct + access mechanisms, permissions, responsible persons, and names. + + EX: Sam E's Circus sets up &RT& to track issues. Issues regarding + setup and takedown go to the "roustabouts" queue, while issues + regarding food and drink sales go to the "concessions" queue. + + What is an Area? + + An Area is used for further grouping Requests in a single + Queue. The same people will be responsible for the Requests, + but will categorize them for the sake of convenience. Areas can + also have distinct access mechanisms (e.g. different mail + aliases). Areas do not have ACLs seperate from those of the + queue they are a part of. + + EX: The "concessions" area will have several Areas, including + "cotton candy," "popcorn," and "watered-down-soda." The same + vendors will be reading and addressing issues in all three of these + areas, but will be able to sort the incoming Requests on them. + + What is a Requestor? + + A Requestor is the person who opens a Request by sending in the + first Transaction on the subject. &RT& has configurable options + for keeping this person automatically informed as to the + progress of their request. + + What is an Owner? + + The Owner of a Request is the person who is taking + responsibility for the issue or question raised therein. They + will very likely be the primary person to make updates to the + Request and change its state as it matures. + + What is the Subject? + + Much like the "Subject:" line in email, the Subject of a + Request is a quick summary of the question or issue raised in + the first Transaction of the Request. This may change as the + Request matures. + + What is the Due Date? + + Setting a Due Date for a Request indicates the date by which + point the owner of the Request expects (or wants, at any rate) + the Request to be resolved. + + What is the Priority? + + A Request may optionally have a Priority set for it, which + indicates its urgency. Higher numbers indicate higher Priority. + A Request may have no set priority, may simply have its + Priority set to a static number, or it may have its Final + Priority set. Final Priority requires a Due Date to operate - + as the Request gets closer to its Due Date, its current + priority gets higher. On (##JRV## day before? day of? AH: NO. + final priority isn't for real, yet. ##JRV## Oh? how d'you mean + "not real"? ) the final day, its priority becomes the preset + Final Priority. + + EX: James Earl Jones creates a Request in July which will come due + on December 20th, to remind himself to get Solstice presents for + his friends. He sets the Final Priority of the Request to 95, + knowing that as he gets close to the time when he'll actually need + to go shopping, the priority will rise and bring this Request to + his attention again. + + What is a Request's Status? + + A Request will always be in one of the following four states: + + Open -- the Request is expecting imminent action a/o updates + Stalled -- the Request needs a specific action or piece of + information before it can proceed + Resolved -- the Request has either been answered or successfully + taken care of, and no longer needs action + Dead -- the request should not have been in the ticketing system to + begin with and has been completely purged. + + What is the Creation Date? + + The date the first Transaction of the Request was logged. + (Duh.) + + What is the "Last User Contact"? + + &RT& can automatically inform the Requestor of any updates to + the Request, or someone updating the Request can optionally tag + an update to be sent to the Requestor. Either way, &RT& keeps + track of when the most recent contact with the Requestor + through &RT& was. + + What is the "Last Contact"? + + The last logged update to the Request. (##JRV## this isn't + quite correct, I know. Clarification? AH: you're thinking of + "Last modification" it's the last time the req was touched) + + What is the "Age" of a Request? + + The amount of time elapsed since the first Transaction for this + Request. (AH: since the request was created..) diff --git a/docs/outline.html b/docs/outline.html new file mode 100755 index 0000000000..75111d748d --- /dev/null +++ b/docs/outline.html @@ -0,0 +1,200 @@ +<html> +<head> +<title> +outline +</title> +</head> +<body bgcolor="#ffffff"> + +<img WIDTH="169" HEIGHT="121" src="rt.gif" alt=""> + +<dl> +<dt><strong>What is RT for?</strong> +<p> + +<dd>&RT& is an automated system for monitoring, answering, and documenting +requests. It was designed as a system to aid helpdesks, but could conceivably +work just as well for development teams, construction groups, political +insurgencies, or circus performers -- in short, any situation in which a +particular group of people needs to request information or action from another +group of people, while monitoring the status of these requests. + +<p> + +<dt><strong>Why did Jesse write it?</strong> +<p> + +<dd>Jesse began &RT& at the urgings of a coworker while working for the summer for +Utopia, Inc, and continued work while attending Wesleyan University and +working for Cohesive Network Systems' New England Division (at the time, the +LeftBank Operation). All three groups have benefitted from it, and hoped to +share these benefits with the user community at large by keeping Jesse fed and +amused while working. + +THE VOCABULARY + +<p> + +<dt><strong>What is a Transaction?</strong> +<p> + +<dd>A Transaction is the most fundamental unit of matter under &RT&. It may +consist of a single emailed communication or a single submission from the web +interface or CLUI. It is from one person, and may begin, continue, or mark +the end of a Request. + +<p> + +<dt><strong>What is a Request?</strong> +<p> + +<dd>A Request is a collection of Transactions addressing a single topic through +its lifetime. + +<p> + +<dt><strong>As a user, what are my personal configuration options?</strong> +<p> + - contact info, mostly + +<p> + +<dt><strong>As a queue administrator, what are they?</strong> +<p> + + Notification options: + <ul> +<li> Mail request owner on transaction +<li> Mail request queue members on transaction (anyone with View) +<li> Mail requestors on transaction +<li> Autoreply to requestors on creation +<li> Mail correspondence to queue members +<li> Mail comments to queue members +<li> Allow non-members to create requests + </ul> + + User access levels + <ul> + <li>admin, manipulate, display, no access + </ul> + + Priority Levels + Mail alias + Area controls + +------- +<h3><font color="#ff0000">These docs aren't done yet, clearly.</font></h3> +These are notes. Move along, citizens. +<pre> +THE MOVING PARTS + +CLUI + +RTQ: +Welcome to Request Tracker 0.9.6 + + usage: rtq <queue> <options> + Where <options> are almost any combination of: + -r list requests in reverse order + -t list most recently modified requests first + + -prio <op> <prio> list requests which have a <prio> satisfying <op> + op may be one of = < > <= >= <> + -owner <user> prints all requests owned by <user> + -unowned prints only the un-taken requests + -user <user> prints all requests made by <user> + -open prints only the open requests + -resolved prints resolved requests + -stalled prints stalled requests + -dead prints killed requests + -orderby <crit> Sorts requests by <crit> (one of serial_num, + queue_id, requestors, owner, subject, priority, + status, date_created, date_due + -format <format> allows you to specify the output of rtq. + <format> is a string of the form %xn%xn%xn. + x is any of the commands associated below. + n is an integer which corresponds to the + number of spaces you'd like the output of x + to take up. <format>'s default value is + "%n%p%o%g%l%t%r%s". Valid values of x are: + n[6] serial number + p[2] priority + r[9] requestors + o[8] owner + s[30] subject + t[5] status + a[7] area + q[8] queue + g[5] age + l[6] time since last correspondence + wt tab + ws space + wn newline + Without options, rtq prints all open requests. + +RT-ADMIN: + +Welcome to Request Tracker 0.9.6 + +user + -create <user> create a RT account for <user> + -modify <user> modify user info for <user> + -delete <user> delete <user>'s RT account +acl <user> <queue> set user <user>'s privileges for queue <queue> + if <queue> is ommitted, list user <user>'s ACLs + +queue -create <queue> create a new queue called <queue> + -modify <queue> modify <queue>'s settings + -delete <queue> completely wipe out <queue> + -area add <area> <queue> adds <area> to <queue> + -area delete <area> <queue> remove <area> from <queue> + +RT: +Welcome to Request Tracker 0.9.6 + + + RT CLI Flags and their arguments + ----------------------------------------------- + -create Interactively create a new request + -resolve <num> Change <num>'s status to resolved + -open <num> Change <num>'s status to open + -stall <num> Change <num>'s status to stalled + -show <num> Display current status of <num> + -take <num> Become owner of <num> (if unowned) + -steal <num> Become owner of <num> (if owned by another) + -untake <num> Make <num> ownerless (if owned by you) + -give <num> <user> Make <user> owner of <num> + -user <num> <user> Change the requestor ID of <num> to <user> + -show <num> Display transaction history and status of <num> + -due <num< <date> Change <num>'s due date to <date> (MM/DD/YY) + -comment <num> Add comments about <num> from STDIN + -respond <num> Respond to <num> + -subject <num> <sub> Change <num>'s subject to <sub> + -queue <num> <queue> Change <num>'s queue to <queue> + -area <num> <area> Change <num>'s area to <area> + -prio <num> <int> Change <num>'s priority to <int> + -finalprio <num <int> Change <num>'s final priority to <int> + -notify <num> Note that <num>'s requestor was notified + -merge <num1> <num2> Merge <num1> into <num2> + -kill <num> Permanently remove <num> from the database + + +THE WEB INTERFACE: + +User: Login , View Queue (and view options therein, and Refresh), Create Requests, View History, Logout + +Manipulator: Comment, Reply, Take, Resolve + + +VIA EMAIL: + +create a request + +Reply to a Request (goes to initiator, depending on queue settings) + +Comment on Request's (doesn't go to users) + +Action: (lib/rt/ui/mail) + +(mail to any rt alias with %rt help) +</pre> diff --git a/docs/outline.txt b/docs/outline.txt index 194ffac86e..e591530ea1 100755 --- a/docs/outline.txt +++ b/docs/outline.txt @@ -1,63 +1,64 @@ -What is RT for? - - &RT& is an automated system for monitoring, answering, and documenting -requests. It was designed as a system to aid helpdesks, but could conceivably -work just as well for development teams, construction groups, political -insurgencies, or circus performers -- in short, any situation in which a -particular group of people needs to request information or action from another -group of people, while monitoring the status of these requests. - -Why did Jesse write it? - -Jesse began &RT& at the urgings of a coworker while working for the summer for -Utopia, Inc, and continued work while attending Wesleyan University and -working for Cohesive Network Systems' New England Division (at the time, the -LeftBank Operation). All three groups have benefitted from it, and hoped to -share these benefits with the user community at large by keeping Jesse fed and -amused while working. - -THE VOCABULARY - -What is a Transaction? - -A Transaction is the most fundamental unit of matter under &RT&. It may -consist of a single emailed communication or a single submission from the web -interface or CLUI. It is from one person, and may begin, continue, or mark -the end of a Request. - -What is a Request? - -A Request is a collection of Transactions addressing a single topic through -its lifetime. - - - - - - -As a user, what are my configuration options? - - contact info, mostly - -As a queue administrator, what are they? - - Notification options: - - Mail request owner on transaction - - Mail request queue members on transaction (anyone with View) - - Mail requestors on transaction - - Autoreply to requestors on creation - - Mail correspondence to queue members - - Mail comments to queue members - - Allow non-members to create requests - - User access levels - - admin, manipulate, display, no access - - Priority Levels - Mail alias - Area controls - -------- + What is RT for? + + &RT& is an automated system for monitoring, answering, and + documenting requests. It was designed as a system to aid + helpdesks, but could conceivably work just as well for + development teams, construction groups, political insurgencies, + or circus performers -- in short, any situation in which a + particular group of people needs to request information or + action from another group of people, while monitoring the + status of these requests. + + Why did Jesse write it? + + Jesse began &RT& at the urgings of a coworker while working for + the summer for Utopia, Inc, and continued work while attending + Wesleyan University and working for Cohesive Network Systems' + New England Division (at the time, the LeftBank Operation). All + three groups have benefitted from it, and hoped to share these + benefits with the user community at large by keeping Jesse fed + and amused while working. THE VOCABULARY + + What is a Transaction? + + A Transaction is the most fundamental unit of matter under + &RT&. It may consist of a single emailed communication or a + single submission from the web interface or CLUI. It is from + one person, and may begin, continue, or mark the end of a + Request. + + What is a Request? + + A Request is a collection of Transactions addressing a single + topic through its lifetime. + + As a user, what are my personal configuration options? + + - contact info, mostly + + As a queue administrator, what are they? + + Notification options: + + + Mail request owner on transaction + + Mail request queue members on transaction (anyone with View) + + Mail requestors on transaction + + Autoreply to requestors on creation + + Mail correspondence to queue members + + Mail comments to queue members + + Allow non-members to create requests + + User access levels + + + admin, manipulate, display, no access + + Priority Levels Mail alias Area controls ------- + + These docs aren't done yet, clearly. + + These are notes. Move along, citizens. + THE MOVING PARTS CLUI @@ -65,29 +66,29 @@ CLUI RTQ: Welcome to Request Tracker 0.9.6 - usage: rtq <queue> <options> - Where <options> are almost any combination of: + usage: rtq + Where are almost any combination of: -r list requests in reverse order -t list most recently modified requests first - - -prio <op> <prio> list requests which have a <prio> satisfying <op> + + -prio list requests which have a satisfying op may be one of = < > <= >= <> - -owner <user> prints all requests owned by <user> + -owner prints all requests owned by -unowned prints only the un-taken requests - -user <user> prints all requests made by <user> + -user prints all requests made by -open prints only the open requests -resolved prints resolved requests -stalled prints stalled requests -dead prints killed requests - -orderby <crit> Sorts requests by <crit> (one of serial_num, - queue_id, requestors, owner, subject, priority, + -orderby Sorts requests by (one of serial_num, + queue_id, requestors, owner, subject, priority, status, date_created, date_due - -format <format> allows you to specify the output of rtq. - <format> is a string of the form %xn%xn%xn. - x is any of the commands associated below. - n is an integer which corresponds to the - number of spaces you'd like the output of x - to take up. <format>'s default value is + -format allows you to specify the output of rtq. + is a string of the form %xn%xn%xn. + x is any of the commands associated below. + n is an integer which corresponds to the + number of spaces you'd like the output of x + to take up. 's default value is "%n%p%o%g%l%t%r%s". Valid values of x are: n[6] serial number p[2] priority @@ -109,63 +110,36 @@ RT-ADMIN: Welcome to Request Tracker 0.9.6 user - -create <user> create a RT account for <user> - -modify <user> modify user info for <user> - -delete <user> delete <user>'s RT account -acl <user> <queue> set user <user>'s privileges for queue <queue> - if <queue> is ommitted, list user <user>'s ACLs - -queue -create <queue> create a new queue called <queue> - -modify <queue> modify <queue>'s settings - -delete <queue> completely wipe out <queue> - -area add <area> <queue> adds <area> to <queue> - -area delete <area> <queue> remove <area> from <queue> - -RT: -Welcome to Request Tracker 0.9.6 - - - RT CLI Flags and their arguments - ----------------------------------------------- - -create Interactively create a new request - -resolve <num> Change <num>'s status to resolved - -open <num> Change <num>'s status to open - -stall <num> Change <num>'s status to stalled - -show <num> Display current status of <num> - -take <num> Become owner of <num> (if unowned) - -steal <num> Become owner of <num> (if owned by another) - -untake <num> Make <num> ownerless (if owned by you) - -give <num> <user> Make <user> owner of <num> - -user <num> <user> Change the requestor ID of <num> to <user> - -show <num> Display transaction history and status of <num> - -due <num< <date> Change <num>'s due date to <date> (MM/DD/YY) - -comment <num> Add comments about <num> from STDIN - -respond <num> Respond to <num> - -subject <num> <sub> Change <num>'s subject to <sub> - -queue <num> <queue> Change <num>'s queue to <queue> - -area <num> <area> Change <num>'s area to <area> - -prio <num> <int> Change <num>'s priority to <int> - -finalprio <num <int> Change <num>'s final priority to <int> - -notify <num> Note that <num>'s requestor was notified - -merge <num1> <num2> Merge <num1> into <num2> - -kill <num> Permanently remove <num> from the database - - -THE WEB INTERFACE: - -User: Login , View Queue (and view options therein, and Refresh), Create Requests, View History, Logout - -Manipulator: Comment, Reply, Take, Resolve - - -VIA EMAIL: - -create a request - -Reply to a Request (goes to initiator, depending on queue settings) - -Comment on Request's (doesn't go to users) - -Action: (lib/rt/ui/mail) - -(mail to any rt alias with %rt help) + -create create a RT account for + -modify modify user info for + -delete delete 's RT account +acl set user 's privileges for queue + if is ommitted, list user 's ACLs + +queue -create create a new queue called + -modify modify 's settings + -delete completely wipe out + -area add + + adds + + to -area delete remove from RT: Welcome to Request Tracker 0.9.6 RT + CLI Flags and their arguments + ----------------------------------------------- -create Interactively + create a new request -resolve Change 's status to resolved -open + Change 's status to open -stall Change 's status to stalled -show + Display current status of -take Become owner of (if unowned) -steal + Become owner of (if owned by another) -untake Make ownerless (if owned + by you) -give Make owner of -user Change the requestor ID of to -show + Display transaction history and status of -due Change 's due date to + (MM/DD/YY) -comment Add comments about from STDIN -respond Respond to + -subject Change 's subject to -queue Change 's queue to -area Change + 's area to -prio Change 's priority to -finalprio Change 's final + priority to -notify Note that 's requestor was notified -merge Merge + into -kill Permanently remove from the database THE WEB INTERFACE: + User: Login , View Queue (and view options therein, and Refresh), + Create Requests, View History, Logout Manipulator: Comment, Reply, + Take, Resolve VIA EMAIL: create a request Reply to a Request (goes to + initiator, depending on queue settings) Comment on Request's (doesn't + go to users) Action: (lib/rt/ui/mail) (mail to any rt alias with %rt + help) |