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.)