University of Washington Computer Science & Engineering

WREQ, a Request/Problem Tracking System - November 1999, revised February 2005 - Warren Jessop (whj@cs.washington.edu)

CSE Support

Printer Friendly Version (PDF)

CSE Home

About Us

Contact Info

Quickie Guide

What a Request Contains

Initial Request

Information Added After the Initial Request

Viewing Requests and FAQs

Adding to Requests

Local UW CSE Additions and Modifications to WREQ

Quickie Guide

Submitting an Urgent Request

If you have an urgent problem and need help right now:

technical support requests: Go to www/lab/support and hit the "entry form" link.
CSE maintenance requests: Go to www/maintenance and hit the "entry form" link.

Be sure to set the priority to "urgent, immediate action needed".

Be aware that this will page a number of people and that immediate attention to urgent requests can only be given during regular office hours.

Checking on a Request

If you want to check on a request you have submitted, go to one of the above links and hit the "Request Tracking" link. See Navigating WREQ for more info.

Viewing System Alerts

A system alert is a request with a special priority (numeric value 90). System alerts have to do with widespread service outages affecting a significant number of people. Only staff members can create system alerts.

A system alert viewer can be brought up by clicking the "System Alert" link on the departmental main page, the www/info/facstaff page, or the www/lab/support page. The viewer is only for viewing system alerts. If you want to respond to a system alert via WREQ, use the normal "Request Tracking" link for CSE technical support, which will display alerts (and all other requests) with an input window to allow comments.

Navigating WREQ

If you've gotten to this page via the `help' button of the WREQ tool here are some essential pointers for navigating the WREQ Request and FAQ tables:

If you are looking at the System Alerts page, click on the Subject text to see an alert.
To look at an individual request or FAQ, click on the Subject text in the rightmost column of the table. See Viewing Requests and FAQs for details.
To switch the list being viewed among Active/Resolved/Deleted/FAQ click on the button with one of these words displayed and choose a different list. Lists are described in WREQ Lists.
To search a list using a variety of criteria (matching strings in full text or subjects, etc.) click on "Search...". See Search... (Search a list or FAQ for text or categories).
If you know a request number and want to view the request, click "Show..." and enter the number. See Show... (Access a request by its number).

What is WREQ?

WREQ was originally written by Yunliang Yu of Duke University, www.math.duke.edu/~yu/wreq/.

As used in the CSE department, WREQ is a request/problem tracking system with a web-accessible database. It is currently used to submit either technical support requests or CSE (Allen center) maintenance requests; these two types of requests are recorded in two separate databases.

You can submit requests as follows:

technical support requests: Use the "entry form" link of www/lab/support, or send email to support@cs.washington.edu.
CSE maintenance requests: Use the "entry form" link of www/maintenance, or send email to cse-maintenance@cs.washington.edu.

Accessing the web page requires a kerberos username and password, as described in www/lab/sw/ISPAccess/cookiedoc.html. There are no restrictions on who can send mail to support@cs or cse-maintenace; however, all messages are examined by WREQ and undergo a gauntlet of spam and other filtering, as described in Email Filtering.

Whether submitted via the web page or email, each request is assigned a ticket number when it is first received; all subsequent communication regarding a request will be appended to that request. In the case of email, the ticket number will be formatted in a special way on the Subject: line, as follows:

fwre[wreg-database ticket-number] original-subject-line

where fwre is any number of spaces or `RE:' or `FW:' strings and wreq-database is the name of the WREQ database, e.g. `wreq', `csem', or `sin'. E.g.:

RE: [wreq #99999] Tachyon beams emanating from room 017

You may manually prefix a bracketed ticket number to any Subject: line, but it must be formatted exactly as described above.

WREQ Lists

Each WREQ database(1) consists of three lists of requests: active, resolved, and deleted. In addition there may be a list of frequently asked questions.(2)

Active Requests

Requests on the active list are waiting to be resolved. There are two states an active request can take:

open: The request is waiting for action by CSE staff.
stalled: The request is waiting for action by someone other than CSE staff; in most cases a request is put into the stalled state while waiting for additional information from the originator of the request.

Resolved Requests

The resolved list holds requests for which no further action is necessary by CSE staff. In other words, a staff member has answered the request or has at least provided information that would allow the originator of the request to find the answer.

But, alas, staff are neither infallible nor omniscient. Hence, any email or web interaction by a requester regarding a resolved request will move that request back to the active list and set its status back to open. CSE staff then have an opportunity to provide a solution better suited to the requester's needs.

Deleted Requests

Deleted requests are those that, in addition to having been resolved, do not need to be kept or archived for future reference.

FAQs

In addition to requests there may be a list of frequently asked questions derived from requests that have been received.

What a Request Contains

This section describes what information fields are kept in a request and when they are changed.

Initial Request

Via the Web Page

When you use the web page you must supply the following information:

your identity: Your identity is your kerberos username, which is also your email address within the cs.washington.edu domain. Using your username, WREQ will attempt to look up your real name and location in an identity record and will fill in the name and location fields of the request automatically. If no identity record exists, one will be created the first time you submit a request, so you only need to enter your name and location once.
subject: A one-liner that describes the problem
description: A full description of the problem.

In addition you may categorize each request as follows:

priority

A numerical priority number may be assigned to a request. Currently we use the following priority table; default is "30: *normal priority*":

100: urgent, immediate action needed: Submitting an urgent request also causes messages to be sent to staff pagers. Immediate attention to urgent requests can only be given during regular office hours.
50: high, action needed in a few hours
30: *normal priority*
10: low, action needed in a few days
5: lowest, action when time permits
1: information only, no action needed

Note that a special priority is assigned to System Alerts; also, certain mail aliases such as webmaster are routed to support@cs, and these are assigned individual (high) priorities that cannot be set by users when submitting requests:

90: [System Alert!]: Special value set only for system alerts; only system staff may initiate a system alert.
62: (from ms-sw-admin@cs)
60: (from webmaster@cs)

area

Values for area depend on the WREQ database; default is "none chosen":

technical support requests:

Animation: Anything having to do with the instructional animation classes or labs.
Authentication: Anything having to do with activating, expiring, or changing accounts, groups, and laboratory/building access; also software licensing problems.
Backup/recovery: When do backups occur; how can information be retrieved from backup tapes.
Cycle server: Questions/problems involving UNIX cycle servers (remote machines you can log into).
Dept info/policy: General information; policies regarding account expiration, etc.
Email: Mailing lists, mail problems, etc.
Equipment records: Anything having to do with the CSE Computer Asset tool or updating equipment records, e.g. moving equipment from one place to another, surplusing equipment.
External network: Network performance or services (e.g. DNS) outside of CSE's control.
File service: File systems and servers, e.g local UNIX or Windows disks or remote UNIX (NFS, Samba) or Windows (SMB, aka CIFS).
Hardware install/config: Physical install/deinstall/configuration of PCs or peripherals.
Hardware questions: Hardware questions/bugs/problems regarding PCs or peripherals.
Instructional computing: Anything to do with instructional labs and classes, including requests for class project areas.
Local network: Network performance, services (e.g. DNS, DHCP, wireless access), or room wiring controlled or provided by CSE.
Printing: Problems/questions having to do with printers and printing within the department.
Remote access: Accessing Windows or UNIX over a network, e.g. from home PCs.
Reservation system: Issues involving reserving equipment (laptops, projectors, etc. borrowed from the support office), rooms, or visitor appointments.
Security: Reports of viruses or breakin attempts; questions regarding security of CSE systems and networks.
Server Room: Reports of incidents in CSE or Sieg machine rooms
Software donations: Questions/problems about obtaining personal copies of free software from various sources.
Software install/config: Installing/deinstalling/configuring apps or OS's.
Software questions: Questions/problems/bugs regarding supported applications or OS's.
Terminal server: Questions/problems concerning the Windows terminal servers or Remote Desktop tools.
Web: Issues involving the departmental or other WWW servers.
X Window System: Issues involving X servers (including Reflection X) and X client programs.
Other computing: Computing issues not covered above.
Non-computing: Anything not covered above.
none chosen

CSE maintenance requests

Bldg maintenance
Bldg alterations
CAAMS
Custodial
Electrical
Furniture
Heating
Locks/keys
Phones
Plumbing
Security
Voice/data ports

OS type (applies only to technical support requests)

Currently one of the following; default is "none chosen":

Win NT
Win 2000
Win 2003
Win XP
Win(any)
UNIX<->Win: Issues involving UNIX/Windows integration or communication.
UNIX(any)
Linux
FreeBSD
Solaris
SGI IRIX
Dec UNIX
MacOS
Other
Several
Any
none chosen

Severity (applies only to CSE maintenance requests)

Currently one of the following; default is "none chosen":

High
Medium
Low
none chosen

visibility

This is a button that allows your request to be viewed by users other than just CSE staff. Default: request is not visible to others.

Via Email

In the case of email submission your identity is provided by your email address, and the subject and description are taken from the appropriate parts of the message. Values of OS type, area, and visibility are set to the defaults described above.

The priority is set according to the following rules:

If one of the acceptable To: addresses specified in Email Filtering is not present in the To: field (i.e. only present in the CC: field), set priority to "1: information only, no action needed."
Otherwise, if there are other addresses in the To: field in addition to the acceptable To: addresses specified in Email Filtering, set priority to "10: low, action needed in a few days."
Otherwise, i.e. the only address(es) present in the To: field are the acceptable ones specified in Email Filtering, set priority to "30: *normal priority*."

Information Added After the Initial Request

The following information is added or changed by CSE staff:

status: Initially the status is open, which means staff need to act on it. For active requests staff can change the status to stalled, which keeps the request on the active list, resolved, which moves it to the resolved list, or deleted, which moves it to the deleted list. Stalled generally means that someone other than staff needs to act on the request: it usually means that more information is needed from the originator of the request. Any email or web interaction by a user regarding a stalled or resolved request will cause the request to be reopened and will move it to the active list if necessary.
owner: Certain staff members may "own" a request; there are independent lists of such "powerusers" for each WREQ database (technical support or CSE maintenance). A member of staff can take a request (become its owner) or designate another staff member as the owner. The owner then becomes responsible for either resolving the request or giving it to some other staff member. Furthermore, the staff member who resolves a request becomes its owner.
date: As soon as a request is received a timestamp is assigned to it.
action log: All activity is recorded here, whether generated via the WREQ web forms or via email. Information logged includes a timestamp, type of activity, and perhaps the contents of an email message or web text field. The initial description and action log are strung together when viewing requests.
last action: The last activity recorded in the action log.
last activity date: Whenever there is new activity, this timestamp is updated.
merged indicator: One or more requests may be merged with another request. This is done by staff if the requests require the same work to resolve them. After merging only the "merged into" request will be displayed in the request table, and in the request itself there will be cross-references to merged requests.
Additions to the action log of any of the merged requests are added to all of them, hence the "merged into" request will contain the original text of all requests at the time of the merge plus subsequent additions made to any of them. Any other changes to a merged request will be applied to the "merged into" request, so, for example, if any of a set of merged requests is resolved, all will be resolved.

Viewing Requests and FAQs

Clicking the "Request Tracking" link from the "CSE Support" page will get you to a page that lists requests viewable by you, which generally include

your own requests,
requests that list you in the CC field of a subsequent reply, and
those with the "viewable by others" box checked.

This page has two frames, an upper one that displays a request (or FAQ) table, and a lower one that displays individual requests (or FAQs) in detail, as well as other forms or information.

If you do not already have a WREQ identity record, i.e. you haven't already submitted a request via the web form, you will be asked to initialize one with your name, location, and phone number before you can view requests.

Navigating the Request Table

The request table in the upper frame contains a number of columns. Clicking a column header generally results in sorting by that column, but

the details differ for each column or a value yields the actions shown, and
sorting resolved and deleted lists "works" in the following way: Internally, WREQ stores resolved and deleted requests grouped by month, and when sorting it sorts within each month (starting with the current month and working backwards in time) rather than doing an overall sort.

Clicking on a value generally narrows down the displayed list in some way, or displays the one request that corresponds to the value.

Details are described in the following table:

Req

The ticket number. Click on header: sort table by ticket number (newest first); click on value: view the request having that number (also see Subject, below).

Note that clicking on the Subject text is not exactly the same as clicking on the request number. In the former case, the browser will make an attempt to execute any html code (e.g. <html> ... </html> and <a> ... </a> sequences) that are embedded in the text; in the latter case no attempt will be made, and just the unmodified text will be displayed.

Owner

The kerberos username of the staff member who has taken or been given an active request, or who has resolved a request. For an active request this field is blank until it has been assigned to a staff member. Click on header: sort table by owner; click on value: restrict table to requests having that owner.

Pri

The numerical priority of the request. Click on header: sort table by priority (highest first); click on value: restrict table to requests having that priority or higher.

Status

(Active requests only.) Open or stalled. Click on header: sort table by status; click on value: restrict table to requests with that status.

Area

(Resolved and deleted requests only.) A categorization (Initial Request) applied to the request by sender or technical staff. Click on header: sort by Area; click on value: restrict table to requests with that value.

Age

Elapsed time since request was made. Click on header: sort table by age (oldest first); click on value: restrict table to requests as old or older than that value.

ActOn

Elapsed time since last activity associated with this request. Click on header: sort table by last activity date (this is oldest first, except for resolved and deleted requests, where the most-recent activity is listed first); click on value: restrict table to requests with last activity as old or older than that value.

Sender

Identity (kerberos username or email address) of the originator(s) of the request(s), separated by commas. There may be more than one originator if several requests have been merged into one. Click on header: sort by sender; click on value: restrict table to requests having that sender.

Subject

Subject field of the request. Click on header: sort table by subject; click on value: view the corresponding request (also see Req, above).

Navigating the FAQ Table

The table of FAQs has a different set of column headers, but the principles are the same:

Msg: Each FAQ has a unique message number. Click on header: sort by msg number (newest first); click on value: view that FAQ.
Date: Date of last change. Click on header: sort by date (most recently changed first); click on value: restrict table to that date or more recent dates.
OS Type: OS Type associated with the FAQ. Click on header: sort by OS Type; click on value: restrict table to FAQs having that OS Type.
Area: A category (Initial Request) associated with the FAQ. Click on header: sort by Area; click on value: restrict table to FAQs having that Area.
Subject: Title of the FAQ. Click on header: sort by subject; click on value: view the corresponding FAQ.

Additional Viewing Options

The upper frame (showing a list of requests or FAQs) also provides the following options:

[list selection] (Select the `WREQ` list to display)

Select from active, resolved, deleted, or FAQ lists.

Search... (Search a list or FAQ for text or categories)

Bring up a form in the lower frame that prompts for search criteria.

For both requests and FAQs you can specify the following search fields: Keywords (for searching the entire text of a message, including subject, description, and action log), Subject, OS Type, and Area.
You can also specify a "shown" quantity, which indicates the maximum number of matching messages you want displayed.
For requests,
- searches are done on each list---active, resolved, deleted---separately, with one exception: checking "Include active requests" in the search form for resolved requests will include all of the active requests in the search as well, and
- you may specify these additional search fields: Originator, Location/Phone of Originator, Owner, Priority, and Date Submitted.

In the Keywords and Subject fields you may enter a string of words separated by one or more spaces. The search is conducted as follows:

The text must match any of the words, which can be Perl regular expressions.
Exceptions:
- If ` AND ' appears in the string, the text must match all of the AND-separated components.
- If `NOT ' prefixes a component, the search is successful if none of the search-words appear.

Examples:

"you and me": text must contain any of the strings "you", "and", or "me".
"you AND me and him": text must contain "you" and, in addition, either "me", "and", or "him".
"you AND NOT me and him": text must contain "you" and must not contain "me", "and", or "him".
"NOT me and him AND you": same as above.
"\byou\b AND \bme\b": text must contain the words "you" and "me", each surrounded by a "word boundary" character, such as space or comma. (`\b' is an example of a Perl "character class".)
"you\sand\sme": text must contain the phrase `you and me'. (`\s' matches any "whitespace" character.)

Notes:

To speed up searches of the resolved and deleted lists, adhere to as many of the following conditions as you can:
- Sort by `Req' number, i.e. newest requests first. This is done by default.
- Choose the smallest "Shown" value.
- Choose the tightest "Submitted in" time range.
The top line of the search form tells you exactly how the search is to be conducted. There are two possibilities:
1. If the top line reads "Search listname list, sorted by field", you have sorted the request or FAQ table by the column header identified by field and have not restricted it by clicking on a value. The sorting will be preserved when the search is completed.
  See Navigating the Request Table for an exact description of how sorting "works" in WREQ.
2. If the top line reads "Search listname list, with field same as number", you have clicked on a field (column) value of request or FAQ number, thus restricting the list to entries with that value, as described in Viewing Requests and FAQs. That restriction will be applied in addition to whatever search criteria you specify in the search form.

List all.., List 25... (Set number of rows to list)

By default 10 requests at a time are listed in the upper frame; these options allow you to change that.

Show... (Access a request by its number)

Bring up a form to be filled in with a single ticket number, in order to display the corresponding request. Note: This works only for active and resolved requests, not for deleted requests.

Reload... (Refresh the list)

This causes the upper frame to be reloaded.

faqWin... (View FAQs)

An alternate way to select the FAQ list; not shown when displaying the FAQ list.

noFrame... (View list and request in separate windows)

For those who don't like frames, WREQ can display the upper and lower frames in separate windows; not shown when displaying the FAQ list.

Help... (Display this document)

Show the CSE WREQ doc.

Support... (Link to the support web page)

Show the CSE Support web page.

Ident (Change your name/location)

Bring up a form that allows you to change your name or location.

NewReq (Create a new request)

Bring up the request submittal form.

Adding to Requests

When viewing a request record, you will note at the end of the action log a form inviting further information. The form includes:

Your comments or additional info

A text window that allows you to add text to the action log. Usually this is appended to the action log. There is one case, however, where this rule is not followed: if the first line of the comments window is `Summary:', the text is put at the beginning, replacing any Summary text that is already there. For a request that has many entries in its action log such an overview can be helpful.

viewable req?

A button that allows you to make the request viewable by others, or to restrict viewing.

Comments

Allows you to update the action log without sending mail to anyone; request will also be moved to the active list if it is not already active.

Mail

Allows you both to update the action log and to send mail to the recipients you choose by setting buttons and entering text as described here:

requesters: The originators of this request and any requests that have been merged with it.
owner: The staff member who owns the request.
me: You like extra email and want a copy in your mailbox!
CC/To: A text window for additional email addresses.

Reset

Reset the form.

Email Filtering

Mail directed to support@cs and cse-maintenance@cs is aggressively filtered for spam and other bad content. Users should be particularly aware that certain text in the "Subject:" field of a message may cause it to be rejected. There are two points at which an email message can be rejected:

Before WREQ even sees it; in this case a message is considered SPAM and is simply dropped.
After WREQ receives the message; in this case a copy is sent to the WREQ administrator, who may or may not do something about it.

Note that in neither case is a message sent to the sender saying that the message was dropped.

The complete set of rules is shown below:

"X-Uwcse-Spam-Status:" field filtering

Any message with a spamassasin score of 3 or more is rejected.
Any message marked `MIME_HTML_ONLY' (i.e. no text, just html) is rejected.

"Subject:" field filtering

The following subjects will cause a message to be rejected; note that case is not significant and "*" is a wildcard meaning any text:

Away *
Out of office *
I am not in the office *
*Autoreply*
Blocked message for WREQ group
Error in Sending * request
Warning*
Postmaster Notify*
=?*
Any non-ascii character in the subject text.

"From:" field filtering

These senders (from any host) are rejected:

mailer-daemon,
postmaster, mailer, uucp, mailmanager, lp

. In addition, any "From:" field containing `the vacation program' is rejected. Other than that, the "From:" and "Reply-to:" fields must contain correctly formulated email addresses.

"To:" field filtering

Any message not containing at least one of these aliases in either "To:" or "CC:" fields is rejected:

support, webmaster,
ms-sw-admin, csem, cse-maintenance, sin, security

"Precedence:" field filtering

Any message with precedence set to bulk or junk is rejected.

Character set filtering

If a character set is specified, it must be one of the following: default_charset, us-ascii, iso-8859-1*, windows-125*, utf-8, where "*" is a wildcard meaning any text.

"Content-Type:" filtering

Any message marked `MIME_HTML_ONLY' (i.e. no text, just html) is rejected.

Duplicate messages

Identical messages from the same sender within 60 minutes are rejected.

Additional Information for PowerUsers

Staff members who can "own" requests are called "powerusers" in the parlance of WREQ. Here is some additional lore powerusers should be aware of:

Viewing stalled and low priority requests

When viewing the active request table, requests in the "stalled" state are normally not shown, nor are low priority requests of powerusers other than you. To list these requests, click on the "Pri", "Status", "Age", or "ActOn" column headers. To list all active requests, open and stalled, belonging to one poweruser, click on the owner's name under the "Owner" column header.

Stalling requests for a set amount of time

Sometimes a set amount of time must elapse before work can continue on a request. Repair parts are scheduled to arrive at a certain day, for example, or some key person is on vacation and will return next Thursday. In such a case you can stall the request and have it automatically open at a time you specify. The "Due Date" window is used to set a reopen time, by setting it to `open at time', where time is specified as in the UNIX at command, for example:

   open at 9am next Thursday

Once you've set the Due Date, change the action to "stall" and update the request. WREQ will respond either with an error message in the Due Date field (if you entered a nonsense time) or with Due Date set to `open atjob number, at time', where number is the at command job number assigned, for example:

   open atjob 10, at 9am next Thursday

If you want to remove the at job before it fires, you can use the UNIX atrm command on the WREQ server, or you can replace the `open atjob ...' in Due Date with the single word `remove', then update the request.

When the at job fires, it just mails a null message that opens the request. For example, for the support request database a message is sent to support@cs with the Subject line set to `[wreq #n] Reopening ticket at scheduled time', where n is the support database request number.

Assigning new requests to a poweruser

When submitting a new request, a "Todo for" field is found in the web request form that can contain the name of another poweruser; in this way one poweruser can assign a new request to another poweruser.

Additional capabilities when responding

When responding to a request, powerusers can supply/change additional items of information.

Basic actions in addition to commenting

A non-poweruser may only "comment"; this causes a stalled or resolved request to be reopened. You as a poweruser have several choices, each of which is done in addition to appending comments and possibly sending email; they are presented as radio buttons just above the "Your comments" text window.

For active requests:

update: Just update the action log. (Note that this choice, or indeed any activity except "stall", will reopen a stalled request.)
stall: Stalls the request; this is described in Active Requests.
resolve: Resolves the request, described in Resolved Requests.

For resolved/deleted requests:

update: Similar to active requests, but, unlike stalled requests, it will not reopen the request.
reopen: Reopens the resolved or deleted request.

Attaching FAQ entries to your response

You can attach FAQ entries to a response by selecting from the titles displayed by the "Attach FAQ" select button. You can narrow down the list of FAQ titles displayed in the "Attach FAQ" selection by doing either of the following, then clicking on "SeeFAQ":

Make selections from the "OS Type" and "Area" select buttons.
Enter a perl regular expression in the "SrchFAQ" window; this will search the FAQ titles for matches and overrides any current "OS Type" or "Area" settings.

If you want to see more than the title of the selected FAQ before responding, you can hit the "SeeFAQ" button, which will display the entire title and text. You can also attach more than one FAQ to a request: After hitting "SeeFAQ" for the first time an editable "Attach FAQ List" window will appear showing the list of FAQs chosen so far. Each time you hit "SeeFAQ"

the FAQ number in "Attach FAQ" is added to the Attach FAQ List, and
the complete title and text of all the FAQs shown in both "Attach FAQ" and "Attach FAQ List" are shown.

When you mail the response, all FAQs listed in both "Attach FAQ" and "Attach FAQ List" are attached.

Including original message and action log

You can include the original message text and action log in a response by checking the Attach request button. This button will only be available if the request is from an "outside" user, i.e. requester's email address does not correspond to a local CSE mail drop.(3)

Hiding responses from non-powerusers

Additions you make to the action log of a request may be designated "hidden" from "ordinary" users (i.e. visible only to powerusers), as described here:

delimiting text to be hidden from non-powerusers

This can be done in one of two ways:

Surround the text you type in the "Your comment, action description" window, or in any text you add to a request via email, with `begin hidden' and `end hidden' lines, e.g.

This text will be visible to everyone who
can view the request.
begin hidden
This text will be visible only to
powerusers.
end hidden
This text will also be visible to everyone who
can view the request.

If the Hide comment from non-powerusers check box is checked, then when you click the "update" or "mail" button `begin hidden' and `end hidden' lines will be inserted for you automatically before your comments are added to the request's action log.

how the delimited text is displayed in WREQ

For powerusers, delimited text is displayed in a contrasting color (usually gray instead of black); the `begin hidden' and `end hidden' lines are not shown.

For non-powerusers, delimited text, including `begin hidden' and `end hidden' lines, is replace with elipses (...).

conditions under which delimited text will be emailed

This is relevant only if the Attach request box is checked. If so, the contents of the action log in the message that is emailed will depend on whether To requesters is checked:

If To requesters is checked, delimited lines in the current action log of the request, including `begin hidden' and `end hidden', will be removed before the message is emailed to all recipients.
If To requesters is not checked, lines in the current action log will be sent unmodified; in particular the `begin hidden' and `end hidden' lines, and all lines in between will be included in the sent message.

Blind CC

You can send a BCC in addition to a CC in a response.

Additional functions in a request window

When viewing a request, a row of buttons across the top provides additional functions:

Resolve, Delete: Resolve or delete the request; do not send any mail or post updates made to the form. If you want to both resolve and post form changes (e.g. OS Type or Area selections), you can do this by setting the Status selection to `resolved*' and clicking the "Update" button to the far right of the "Priority/Status:" row, as described below.
Move: Move the request to a different WREQ database.
Merge: Pops up a page that allows you to merge another request (or multiple requests) into this one. Or, if requests have been merged, to "unmerge" them.
Take or Untake: Take (become the owner of) a request. Or, if you already own a request, cancel your ownership, giving it back to the "anonymous" pool.
CantDo: Mark request as "undoable" by you. Bug: this works only if no one currently owns the request.
Give: Pops up a page that allows you to make another poweruser the owner and send a message to that poweruser (along with the original message and action logs). Also allows sending a different message to the requester.
Edit: Allows powerusers who can do config changes to edit both original message and action log fields of requests. Works on active requests only. This is somewhat dangerous, but it is handy especially when you need to delete long inappropriate attachments to messages. In addition to text editing, you can also delete ranges of lines by delimiting them with "#begin delete" and "#end delete" lines (currently buggy).
Download: Download a copy of the request.
More...: Displays additional information, in this case all the mail headers that are not normally seen.
2Faq, 2Tech: Create an FAQ or TechNote with the subject and text of the current request.

Additional request fields that can be edited

When viewing a request, you can change any of the following fields:

User Name

Email

Location/Phone

OS Type

Area

Priority

Status

In some cases changing the current status will move the request to a different list. Status names ending in `*' imply an action:

open*: Request is open; change to open is possible only for stalled requests.
reopen*: Change to open is possible only for stalled, resolved or deleted requests.
stalled*: Request is stalled; change to stalled is possible only for open requests.
resolved*: Request is resolved; change to resolved is possible only for open or stalled requests.
deleted: Request is deleted; changing active or resolved requests to deleted is not possible here.

Subject

To effect the change, an "Update" button is provided.

Manipulating requests via email

It is possible to manipulate active and resolved requests via email; deleted requests cannot be so manipulated since, once deleted, a request number is no longer indexed.

Thus, for active and resolved requests a poweruser need not use the web interface to look at and dispatch requests. To do this via email a command must be embedded in the Subject line:

Re: [database #nnnnn command] rest of subject
Note: `Re:' or `FW:' may or may not be present at the beginning of the Subject line. For example:

Re: [wreq #88888 resolve] problem with printer psZZZ
on the Subject line of a message to support@cs will resolve request 88888.

The following commands may be specified

fetch: Cause the entire text of the request to be emailed to the sender of the command.
resolve: Cause the (active) request to be resolved. In this case the Area field of the request is set to `resolved by email'.
reopen: Cause the (resolved) request to be reactivated
stall: Cause the (open) request to be stalled.
open: Cause the (stalled) request to be opened.

Notes:

Presently the body of such a command message must be non-null, else the message will be ignored.
In order for such requests to be considered valid, a suitable entry must exist in WREQ's "passwd" file that is keyed not by the poweruser's username, but by the return email address. For example, for such a poweruser, say jouser, there would usually be two entries in the passwd file, one keyed by `jouser' and another by `joeuser@cs.washington.edu'.

Additional functions in a list window

The following are available:

database: A drop-down list allows you to change WREQ databases. Choices are `wreq' (the support request database) or `csem' (the CSE maintenance request database).
Config: Shows some of the current WREQ configuration parameters; a master password is needed to make changes.
Statistics: Displays request statistics; can also display graphically.
DelUsers: Displays current WREQ users; a master password is needed to delete or update.
Add: Similar to "NewReq" for non-powerusers.

Creating and editing FAQs and TechNotes

FAQs are viewable by everyone.

TechNotes are viewable only by powerusers. They contain technical and procedural information that a poweruser needs to be aware of when answering requests and carrying out other support and operations tasks.

FAQs and TechNotes may be created from requests by the "2Faq" and "2Tech" links mentioned in Additional functions in a request window.

They also can be created by the "add" link in the FAQ or TechNote table window, and changed by the "Change" link in the text window of a FAQ or TechNote.

When a table of FAQs is displayed, an additional column appears for powerusers, labeled "N". This is the "notify" indicator, and it identifies recently created or edited FAQs. There is a corresponding Notify button on the individual FAQ displays. When Notify is clicked, the corresponding FAQ will be emailed to a list of users who want to be notified when FAQs change; the "notify" indicator will then be turned off until further edits are made to the FAQ. A Clear button is also available if you just want to clear the "notify" indicator.

Creating System Alerts

System alerts are viewable by everyone.

To create a system alert, go to the input form (e.g. via the Add button from a list screen). Fill in the request and submit it like a regular request, but make sure to set the Priority to [System Alert!].

Also, make sure to enter the time and date you expect things to be resolved in the "Due Date" field; this just an ordinary text string. It will be labeled on a System Alert display as "Resolution expected by".

In addition to submitting from scratch, any request can be made a system alert by changing its priority to [System Alert!].

If there are no active system alerts (i.e. all have been resolved or deleted), the "System Alert" link on the main CSE web page will disappear. It only appears when there are active system alert requests.

Local UW CSE Additions and Modifications to WREQ

Bug Fixes Just to Get It to Work

allow for sendmail's smrsh in req-mail.
localisms needed to import old data, in req-convert.
bad typo at "current boundary string" in req-show.
GIF is no longer supported by GD, in req-status.

Other Bug Fixes

correct a few typos in output text (req-common, req-create).
Y2K correction in req-list.
allow cc: and Cc: in addition to CC: in req-newreq.
FW: treated like RE: on subject line in req-newreq
fixed this: reopening an active (e.g. stalled) request caused it to be deleted (as in nuked, not moved to the deleted list), in req-update.
when resolving, mail "to owner" should mean the current owner, not the current resolver.
after creating a group, "Click here to start..." should take you to the new group, not group 1 (req-create)
change setting of $needwriteconfig (in req-common) to 1, because there are other, unfixed bugs that cause the count of active requests to get out of whack.
remove "Received" and "Message-ID" lines before showMIME or escHTMLChars calls.
fix bug that prevented displaying some attachments (lines beginning with "---").
when using the web form on a merged request, apply updates and comments to the "mergee" in addition to the request itself (this was already being done for comments added via email).

Config

turn OldMailRules on permanently.
add $nopower variable (for debugging): takes away poweruser rights.
add a %pgrpri hash ref, keyed by group, with pager email addresses as subkeys in each group, along with values consisting of comma-separated lists that include a priority threshold and an RE to be used in matching against a request owner; pages are sent on new requests, or when priority is changed, only if priority threshold is exceeded AND there is an RE match (note: in most cases the RE is ".*", which always matches).
add %notifyfaqchanges, array indexed by group; each group has a list of email addresses to use when a FAQ is changed and the "Notify" button is clicked.
add %supportpage, array indexed by group; each group has a URL to display when the Support... button is hit.
add $sysalertfile, name of html include file in which to put a link to the system alert page (req3?list, see Authentication) if there are active system alerts; contents of this file consist of a concatenation of $sysalertprefix, Subjects of the system alert(s), and a closing "</p>".
add $sysalertprefix, used to create contents of $sysalertfile.
change the "delete users" screen:
- allow copying passwd entries in addition to deleting them, so that admins can create entries with keys that allow poweruser validation by email, e.g. 'jouser@cs.washington.edu' in addition to 'jouser'.
- also require master password when deleting/copying such entries.
add $embedhtml and set it to 1; see comments under List Screens and Show/Update.

General

remove "noise" from the initial WREQ screen; make it more helpful.
make the gray background lighter.
increase width of all text windows from 60 to 75.
hide Syslog and S.O.S from everybody; they are not used.
hide TechNotes from non-powerusers.
fine-tune the acceptable chars in a displayed URL (e.g. disallow parens).
improved wording in certain places:
- slightly better error messages for invalid URLs; also specify the associated action.
- clearer button and switch labels on some pages.
add debugging code here and there.

Email

comment out all code that sends gratuitous mail to a user or to a request distribution list like "req-dist"; e.g. nix all messages such as "your request has been taken by/given to ".
adjust priority and area of requests forwarded from other email lists:
- webmaster requests are assigned priority 60, area WWW.
- ms-sw-admin requests are assigned priority 62, area Software donations.
adjust priority depending on To: and CC: lists as specified in Via Email.
add "fetch" email command for powerusers.
never automatically relay a copy to requester when receiving mail with "[database #nnn]" on the subject line.
always automatically relay a copy to owner when receiving mail with "[database #nnn]" on the subject line.
when mailing action logs, change the "=====" separation lines to have ">" instead of "="; this prevents them from being interpreted as separation lines if the message is returned to WREQ by the requester.

Authentication

require an authenticated REMOTE_USER when doing normal request tracking.
create a copy of req called req2: req2 is used in URLs that call for actions that do not require REMOTE_USER, such as handling of the email interface and browsing FAQs.
create a copy of req called req3: req3 is used in URLs that display system alerts; currently these do require REMOTE_USER, but req3 allows ONLY the system alert requests to be viewed.
on login screen:
- WREQ password is never necessary because REMOTE_USER is known.
- make userid immutable; only name and location fields can be changed.
add a "getpower" sub, which tests if a given username is a poweruser

List Screens

make "announcement" text bolder and larger.
adjust what is listed:
- for powerusers: don't list stalled requests or low priority requests (other than owned by the current poweruser) when sorted by "Owner" or "Req": list everything only when sorting by the "Pri", "Status", "Age", or "ActOn" column headers, or when restricting the list to a specific owner.
- for others: others can only see their own, globally visible requests, or those that they have been CCd on. requests.
in the "Sender" column, list all senders if the request is a "mergee", not just the mergee's sender followed by a comma.
hide the group selection button from non-powerusers, since at the present time we don't want them switching groups.
change behavior of clicking on subject text so it now causes the request/FAQ to be viewed; however, there is a slight difference between clicking on a req number and on the subject: in the former case $embedhtml is forced off (so that problem pages containing rogue html code can always be displayed), while the latter case allows html code to be executed if $embedhtml is on.
for symmetry, add non-link "previous..." and "next..." for first and last pages of a list display.
do not display "next..." when showing the result of a search, since hitting "next..." will display a screen that does not honor the search.
display "(no entries)" if a list is empty.
change defaults for displaying active and resolved lists:
- active: list all, sort by Owner.
- resolved: list 10 (25 for powerusers), sort by Req.
remove smallcap L from list display.
high priority numbers (>=50) are displayed in red; special priority numbers (60-69) are displayed in a darker shade of red.
change column headings to allow more room, e.g. Priority -> Pri
replace "Status" column of resolved and deleted lists by "Area[faq]" (status is redundant and Area provides more info); also append attached FAQ numbers, if any.
change Age and ActOn values to allow finer grain, e.g. 6wks instead of 1mo, and 60hrs instead of 2days.
change sort order of ActOn in resolved and deleted lists: list most-recently acted-on first.
display older Age and ActOn values of active requests in blue; the older they are the bluer they get.
if URL is entered as "req3?list":
- restrict listing to "system alerts" (priority==90).
- change "announcement" text to identify it as a system alert listing.
- display only "Reload...", "Help...", and "Support..." buttons across the top of the upper frame.
add Help... link.
add Support... link.
display a "fake" priority for certain kinds of requests, e.g. those owned by "helpdesk" that have not been acted on for 2 days are displayed as priority "99".
for FAQ lists:
- disallow condensing FAQ numbers; they need to be immutable.
- remove "Author" column from FAQ and TechNote lists.
- change format of "Date" to mm/dd/yy; change date sort to newest first.
- add a new column, "N" (for Notify required - see FAQ changes).

New Requests

add out-of-hours autoreply, based on time ranges. (no longer used - autoreply is always issued now).
cancel autoreply if sender is one of a number of system accounts, e.g. "root", or if message is not from a "*.washington.edu" address, or if subject identifies the message as automatically generated.
force default status and priority to be non-null, i.e. "open" and "30" respectively.
hide group selection from non-powerusers.
add window for "DueDate" input (powerusers only).
customize with UW CSE logo.
add link to "Help..." screen (links to "what a request contains" section of this document).
put "Priority" window ahead of "Area" and "OSType".
introduce a few syntactic rules for priority descriptions:
- priority descriptions beginning with '(' are not displayed in a selection list, so neither users nor powerusers can set "(webmaster)" or "(ms-sw-admin)" priority.
- priority descriptions beginning with '[' are displayed in a selection list only for powerusers, thus ordinary users cannot set "[System alert!]".
require non-null Subject and Description for web requests; non-null Subject or Body for email requests.
add spam filtering as described in the text.

Show/Update

ANY activity will open a stalled request.
when giving to another poweruser:
- sort popup selection display of powerusers.
- include URL of this request.
- optionally send a different, perhaps less technical, message to the requester, along with the description and action log.
add a "nogive" list (set in req-config); powerusers listed here cannot be given requests, but they can look at everything and take requests.
record mail header info, e.g. "Date:" and "CC:" lines, of emailed requests and responses in the action log.
add a BCC window.
many changes to "Attach FAQs":
- replace the "Attach FAQs" window with a selection button that shows the number and subject of all FAQs sorted by Area, similar to other "Select One" options.
- add a "SeeFAQ" button that redisplays a request along with full text of the selected FAQ.
- add a "SrchFAQ" text window that will restrict the selection of FAQs on redisplay (via "SeeFAQ") to those whose subject lines contain the input text.
- if "SrchFAQ" is blank, then the selection of FAQs is restricted to those having the "OS Type" and "Area", if any are selected.
- to allow attaching multiple FAQs to one request, list the FAQs selected so far in an "Attach FAQ List" window (appears after the first FAQ is selected) that also can be edited like the old "Attach FAQs" window.
add "OS Type" and "Area" selections near the bottom of the window; makes it easier for powerusers to categorize requests when answering them.
require a non-null "Area" when resolving; if resolving by mail set the "Area" to "resolved by email".
remove "Add TechNotes" and "Add Syslog" windows - not used.
reduce fiddling with text of messages and allow preformatted text, in particular several improvements to escHTMLChars. Includes:
- change only left margin tabs to 8 spaces, not any old tab.
- change spaces to " ", not " ".
- handle <pre> ... </pre> correctly.
- handle <html> ... </html>.
- variable, $embedhtml, to control whether <html> ... </html> and <a> ... </a> are honored (this needs to be turned off to prevent buggy pages from writing over the "delete" button in some cases).
remove "Received:" lines from action log display.
print out full text of merged requests in the "mergee's" action log, along with the Req# of the merged request; thus you don't have to view another request to see the whole enchilada; when unmerging, make sure the previously merged text is removed from the mergee's action log.
add a "Summary:" feature: if first line of description is "Summary:" the description is listed first (before original message), replacing an existing summary, if any; display the summary in a contrasting color; useful for long and complicated requests.
when resolving or deleting, use the submittal date of the request, not the current date, to determine which GDBM database file to use (this allows for faster searching of resolved/deleted lists when sorted by "Req" and when a "Submitted in" time range is specified).
when reopening, keep the current owner (don't null it out) if last activity date is less than a week old.
add ability to edit original text and active log; slightly dangerous but nevertheless useful, e.g., if you need to delete inappropriate long attachments to requests and comments; requires master passwd; make the edit screens horizontally scrollable (if browser allows); only valid for active requests (this is still buggy).
remove "todo" from the selection of statuses that is displayed.
increased max size of email attachments to 20M.
add a DueDate window (just plain text for now).
for system alert (priority==90) requests, display Subject in red; also label "Due Date" as "Resolution expected by".
add ability to stall a request and allow it to be reopened at a given time; uses "Due Date" field to initiate or remove UNIX at jobs on the WREQ server, as described in Stalling requests for a set amount of time; add two new subs to req-common: atstart and atrm.
add check: only active requests can be stalled.
remove unneeded radio buttons labeled "comments" and "open".
provide a method for hiding text in the action log from non-powerusers, as described in Additional capabilities when responding. This allows private conversations among powerusers.
remove the "Include Orig Mesg" and "Action Log" buttons and replace by "Attach request". Display this button only if the email field indicates a non-cs.washington.edu address; see footnote under Including original message and action log for more info.
cosmetic changes:
- display description with lighter gray background.
- display alternate action log entries in contrasting colors: "ivory" and "seashell".
- hide redundant included messages, e.g. those starting with "----Original Message" or " wrote:"; replace with a link that when clicked displays all the included messages as before; note that this hides from the last (not the first) such line to the start of the next action log.

FAQ

provide FAQ "intro" screen that makes going directly to the FAQ more "natural"; include link to a "single-page" FAQ on this screen.
individual FAQs can be viewed by cs.washington.edu hosts (via URLs containing req2) without authentication.
change "Message #" to "FAQ #" in FAQ text display; also "TN #" in TechNote text display.
special case for mailto addresses in FAQ text: display only email when http://www.cs.washington.edu/htbin-post/unrestricted/mailto.pl?to=email is seen
change layout of FAQ/TechNote display:
- display # and subject at top, subject in large bold font.
- display date and author at bottom.
do not allow FAQs to be deleted.
add a new field to FAQs: "Notify required"; this is described in Creating and editing FAQs and TechNotes.
make FAQ text entry screen horizontally scrollable (if browser allows).

Searching

add a header line that reads either "Search listname list, sorted by field" or "Search listname list, with field same as nnn", where listname is a list name, e.g. "Resolved", field is a field name, e.g. "Req", and nnn is a request or FAQ number; the latter format is for when a value for some entry has been clicked on before "Search..." is hit.
add AND conjunction and NOT predicate for subject and keyword searches.
put "Keywords" window above "Subject".
change "Sender" to "Originator".
change "OS Type" and "Area" to MULTIPLE selections; allow search for null area, i.e. "none chosen".
change "Owner" from a selection to just a text field so that searching for former powerusers is possible.
changes to "Submitted in" list:
- change time range descriptions, e.g. "Last 60 days" instead of "2 months" and "Previous month" instead of "Last month".
- add a "Range specified->" selection that allows choosing a specified date range.
- set default to "Last 90 days".
- remove "Req # from" and "to" windows; replace with "Date from" and "to" windows to retrieve requests sent in a given date range.
add "1" to "Shown:" selections, i.e. only show the first match.
add a "search fine print" paragraph that provides minimal help
add a button, "Include active requests", to the search of Resolved requests that includes the active requests as well; does this by putting a symlink, "Active", in the current resolved year directory, that points to active requests, and defining a fake 13th "month" called "Active"; also mark the matching active requests listed with a little "A" by the request number.

all mail sent by WREQ already includes the URL of the request, and so all such users will have permission to view the request in a browser, and
WREQ is buggy when it comes to properly handling mime attachments to such messages, viz. it does not add Context-type headers that specify proper boundary strings.

This document was generated on June, 27 2008 using texi2html