WREQ - a distributed request/problem tracking system

Current version is 2.8, released on Mar. 5, 2005. See new features below.

A request queue/discussion group for wreq was set up, which you can
access
to discuss wreq-related problems and enhancements. You can subscribe to
the queue by email with the subject:
wreq subscribe.

A snapshot of wreq in action is here.
A list of recent changes is here. Some old
versions are also available.

New for version 2.6 and later:

New passwd format, you must load "req?create" once after upgrading
the script files from pre-2.6 versions

Integrated support for the standard HTTP authentication. (I still prefer
cookies)

Cookies are much simpler, now you can open wreq in multiple windows

New email rules.

Many other changes. Please look over the recent changes below before
upgrading.

BTW, wreq is Y2k Compliant, since it uses perl and stores
the time in seconds since 00:00:00 UTC, January 1, 1970.

Note to wreq 1.x users: Version 2.x
uses a slightly different database format in order to ensure future expandability.
You are *recommended* to upgrade to the latest version.
Here
is how to upgrade: 1. Copy all the new perl scripts into its usual
places, 2. Backup your data directory (say, by making a tar file), 3. chmod
or chown on everything in the data directory to give you the write permissions,
4. At your shell prompt, cd to the directory where the file 'req-misc'
is, and run the command "perl req-misc convert12", 5. chmod or chown on
everything in the data directory back so your web server can write in it,
6. Use netscape to access wreq URL to see if the converting is OK. 6. If
not, please let me know.

Introduction (click here
to see Joe Heiser's power user documentation)

Warning: Not all the features described below have been implemented
yet. They'll be worked on whenever I get spare time. As of this release,
only a basic stand-alone server is implemented. You can think of it currently
as an emulation of the popular req system on the web (but it doesn't depend
on req at all). The root server feature will be written soon.

Wreq is designed to be a distributed request/problem tracking system
with builtin knowledge database to help systems personnel to stay on top
of requests and to prompt knowledge sharing among all local support groups.
Most departments in a large organization normally have their own local
staff to support their computers and networks, and one common problem is
that there is no easy or automatic way for all the local support groups
to share the knowledge and expertise they each have. This system attempts
to address this problem by automating the sharing process. To facilitate
this, the organization will set up wreq on one chosen web server and configure
it to be the root req server for all the departments. Each department can
then put wreq on their local web server and configure it to handle requests
from people within the department (or any number of departments they are
supporting). People can submit requests either by accessing their local
req server's URL or by sending email to the req server's email alias. Each
req server can also be configured to handle requests from other departments
too, if another department doesn't have a web server or just don't want
to mess with it (but want the req services). The root server is there to
collect the shared database items to make the sharing possible across all
the departments using req services. Each server has 5 categories of data:

Active requests: all the requests/problems from your department waiting
to be resolved.

Resolved requests: all the resolved requests of your department or supported
group.

FAQs: Frequently asked questions derived from requests that your server
received. Your local server has your locally added faqs. The root server
has faqs from all servers. You have the option to search either local or
global faq lists.

TechNotes: A collection of ideas and how-to's entered by staff members
when they want to share something useful with everyone else. Just like
FAQs, TechNotes are shared among all servers. When you reply to a user
about a request, you can include the content of any faqs and technotes
in your message.

System Log: A place to log major systems/network changes for users to view.

SOS: Questions posted by staff members when they need everyone's help on
something. These questions are kept on the root server and visible to everyone
from any req server.

You can configure your server to only accept requests from a given set
of hosts and to only allow a given set of hosts to view the database items.
User authentication is based on hostname, email address, password and netscape
cookies. All support persons (called power users in the source code) are
required to have a password to login and other users are not. The default
password for power users is the password you used or changed to when you
configure the server (see below).

Installation

To use wreq, first you must have perl version 5 with GDBM support installed
on your web server. Install perl now if you haven't. Gnu gdbm and perl
are available from many GNU archive place. Here is how you can tell if
your perl is up to the job: At a shell prompt, run the command "perl -e
'use GDBM_File;'" (without the double quotes, of course). If it doesn't
say anything, your perl is fine. We are using perl 5.003 on Solaris, SunOS
and IRIX here. Knowing some perl will make using wreq more fun. The
GD module for perl is also needed to plot the usage info, see below.

First download the code by clicking here.
This is a gnu-zipped tar file. Now untar it to the cgi-bin directory of
your web server and you'll have a directory called 'wreq' in your cgi-bin
directory. All the files in the wreq package must reside in
this single directory.

Next you need to change the first "#!/usr/local/bin/perl" line in the
files 'req','req-mail' and 'req-convert' to whatever is proper to run your
perl . Now open the file 'req-config' in a text editor to change various
global parameters. Normally you don't need to change anything else in other
files.

One script 'req-convert' is provided to convert old req data files to
wreq format if you are currently using req. To convert, open 'req-convert'
in a text editor, change "$reqtop=" to point to the req directory where
the directories 'data' and 'faq' reside and change "$defaultemailaddress="
to the proper email address to append to any incomplete email addresses.
Be warned that you might need to make some additional changes to make it
work for your installation of req. Now run 'req-convert' from a shell to
convert all the req data.

Now you need to change the ownerships and permissions of files in 'wreq'
directory so that all the files in 'wreq' directory is readable by everyone
(or at least your web server), 'req' and 'req-mail' are executable by everyone.
The 'data' directory and everything in it are readable and writable by
the uid and gid of your web server daemon and not by others.

To route email to the req server, you need to edit the /etc/aliases
file (on the NIS server if you are running NIS, on web server itself if
not) to include the following 3 aliases:

req: wreq@your_web_server

wreq:"|path_to_your_'req-mail' _program"

req-dist: uid1,uid2....

where uid1,uid2... are email addresses you want to forward all incoming
requests too.

Finally the server is ready to be configured. Load the URL 'http://your_web_server/cgi-bin/wreq/req'
in a browser and click on the 'configure' link. You are now looking at
the server configuration page. Fill out your dept's full name. For password,
type in "numlock" (without the quotes) in the password field and type in
a new password you like to the next field. I'd recommend everyone
choosing a new password here. Fill in the email alias field the email alias
you want your users to send requests to, as in /etc/alias file above. The
req-dist list is the one you have set up in the /etc/aliases file. Leave
the root server URL blank, since I haven't done it yet. In 'Local Support
Email List' filed enter the email addresses of people who will handle all
the requests from your department, one per line. People logging in with
these email addresses are power users and can do anything to the database.
In 'Permitted Hosts' field fill in hostname or IP address patterns for
all the hosts you wish to receive requests from, one per line. For now,
leave the "Additional FAQ hosts' field blank. The "Priority List" box is
for you to enter a list of priorities you want your users to select from
when they submit requests through the web. One priority per line and each
line must have a priority number (high to low) and a name string. You can
also customize your supported "OS Types" and "Areas". Now click on the
"Create" button to create the profile or click on "Modify" to make any
changes.

Now you users are ready to submit requests by using the same URL or
the req alias....

Submit requests

Once the URL 'http://your_web_server/cgi-bin/wreq/req' has been loaded
in their web browser, your users will see a form with lots of fields to
fill out. To submit a request, fill in Name/Email/Location/Phone# first.
They are required to fill in these 3 fields only once and they will be
remembered by the web server by using netscape cookies. If you have a local
ph server, you can jsut fill in a partial email or name and click on "PhoneBook"
button to complete them. Then choose OS type, Area and Priority Category,
type in a subject and the rest. Click "Send" to send it to the server.
When a power user loads this page, there is also an extra "Todo for" field;
this can be used to assign a request to another supporting person.

Handle requests

Load in the URL above and click on the "keep track and follow up" link.
This page is where you'll spend most of your time to work in requests.
The window is divided into 4 frames. For easy referencing, I'll call upper-left
frame "A1", upper-right frame "M1", lower-left frame "A2", lower-right
frame "M2". Frame "A1" has a list of the 6 different categories of data.
Click on any of them, the entries of that database will show up in frame
"M1". Frame "A2" has a list of actions you can apply to a request or faq.
"M2" will be used to show the content of a request or faq. For testing,
go back to the URL above and submit several requests and come back here
and click on "Active" in frame "A1" when you are done. BTW, "M1" will be
updated automatically every 5 minutes, so you don't have to reload it yourself
to stay current.

The "M1" frame contains a title 'Active' and a link for searching the
database, 3 links to control how many entries to show, a link to reload
current frame and a table of a list of requests. The headings of the rows
of the table are in bold font. Click on a heading will cause the request
list to be sorted by that column. You'll notice that heading will be shown
in a red color to indicate this fact. The default sorting is by the 1st
column, which is the fastest BTW. For any request listed in "M1", click
on its request number in the 1st column to display the content of that
request in frame "M2", if you have the permission (either on req-dist list
or being the sender of the request. I'll assume you are on the dist list
for the rest of this section). Click on links in other columns will selectively
list only "similar" requests. The request number in the first column will
be shown in green when the reuqest was just submitted or when any new info
added; it'll stay green until you act on it. Note that when you click
on 'Active' or 'Resolved' in Frame 'A1' to bring the table in "M1", all
the requests with green
request numbers (in the first column) will be listed first and none
of the headings is red; this is a programmed feature to
draw your attention to the requests which are either new or have new
info from the users.

When a request is shown in "M2", you can click on "Take/Untake" in "A2"
to take/untake/steel it. Click on "Give" to give it to someone else. Click
on "ActOn" to act on the request or send email to the user. When you click
on "ActOn", you'll see a form display of the request in frame "M2". Change
anything like user's Name/Email/Location or OS type/Area/Priority, or subject
and add your input to this request, and select "update" radio box, click
"Update" to update the database with all your changes. Click on "Mail"
if you want to send a copy of your changes and inpput to the user as well.
Select "comments" to simply add/mail a comment, "info" to mail user for
more info, "stall" to stall the request, "resolve" to resolve the request,
"reopen" to mark a previously resolved request open again. There is also
a 'resolve' button in "A2" for quick resolve without any comments. To merge
a request with others, just select "merge" and type in the other request
numbers in the text field below and then click on "Update". The "Attach
FAQs" and "Attach TechNotes" boxes near the bottom are used to attach faqs
or technotes to mail messages to the user. These 2 boxes sometimes will
have a number in them already, which is the last faq or technotes you view
before clicking on "ActOn". The "2Faq" link in "A2" will let you turn the
currently shown request into a faq. Same for "2Tech". The behaviors of
the links in "A2" depend on which is the last request or last faq/tech/sos
you accessed. Play around and find out more...

Many other features (and bugs of course) are waiting for you to find....

Have fun!

-yu

List of recent changes:

A Multi-Resolve feature was added for powerusers to mark multiple
requests as resolved easily. To use it, click on 'MultiResolve' link in
the listing frame. You can resolve all requests older than a given number
of days, or all requests acted on the given days ago; or select your own
req#s by clicking on the 'Req'# listed in the top frame. 3/5/2005.

A 'auto resolve' option was added to the config, where you can specify
the number of days when all requests older than that date will be
automatically marked as resolved. This is a nice way to trim down your active
request list. 3/5/2005.

A new configure option 'quick mode' was added to make the group listing by req#
as the default. 3/5/2005.

Wreq can now be configured (set $spamc='/usr/bin/spamc' in req-config)
to use spamc of spamassassin to block spams from reaching the list. All
spams will be forwarded to the poweruser instead. A virus scanner can also be
added easily (later)3/5/2005.

A option was added to require SSL for login, if it's available.
Set $useSSL=1 in req-config. 3/5/2005.

Login now redirects to accessed URL after a successful login. 3/5/2005.

More error checking were added on accessing db files and on server config. 3/5/2005.

Some javascript is now used to make the listing/viewing requests eaiser. 3/6/2005.

The sub 'syncALL' in 'req-misc' was improved to update nextid when needed. 3/5/2005.

Mail power users when a request is moved into the group. Idea from Rob
Irvine <robi@hastdeer.com.au>. 2/23/00.

A bug was fixed in showMIME which was too liberal. Bug found by Andrei
Ivanov <Andrei.Ivanov@Realogic.lv>. 2/23/00.

Wreq now supports PNG files generated by GD with version > 1.20. 11/10/99.

The request listing routine listReqs() in req-list is optimized for faster
return; 30% faster in my tests. A new option "-q" was added to the command
line interface "wreq" to make it run as fast as possible. With the -q option,
the requests can be sorted by req# only, but it's fast. In my tests with
big listings which normally take 3 or 4 seconds, they take 1 second or
less now with the '-q' option. This option makes WREQ faster than the good
old REQ. This option could be useful for scripting. 9/10/99.

To make wreq not to autoreply to messages received at the address, say
"announce@totalsports.net", for a support group, go to the page "req?create"
and select the group, fill in announce@totalsports.net to the boxes "Email
aliases for users to send requests to" and "except for the following email
addresses". I.e., you can now configure autoreply based on To and From
addresses. Idea from wfaulk@totalsports.net. 8/22/99.

Poweruser can access any groups anywhere if he can login properly by calling
up 'req?login' first from a new place. Secure web server is not required,
but it's encouraged. 8/22/99.

A new config param $hideInaccessibleGroups was added to 'req-config'. When
it's set, a user can only see the groups he has access to listed in the
pull-down menus, based on his hostname, IP address or his login email address.
Idea from Steve Davidson davidson@verinet.com. 8/22/99.

To see how fast the CGI script runs, the number of seconds it spent to
complete your request is included at the bottom of each page. 8/21/99.

Fix a bug in sending email to the last sender. Found by Bitt Faulk <wfaulk@totalsports.net>.
8/20/99.

MIME messages should be handled properly now. It can decode base64 and
quoted-printable and let your browser handle other types. Idea from Petter
Reinholdtsen pere@td.org.uit.no and others. 8/19/99.

Add code to make all email addresses lowercase for easy comparison. 8/12/99.

Fix convert12 in req-misc to get rid of blank lines in request listing.
Reported
by Allen Weinberg <allen@ilx.com>. 8/12/99.

req-config now loads in the file 'req-config-local' if it exists. You can
use it to overwrite any params in the distributed req-config without changing
anything in req-config itself; hope this will make upgrading easier. 8/6/99.

Minor change to sendMail() in req-common and req-mail to make it work with
qmail. Idea from Bitt Faulk <wfaulk@totalsports.net>, 8/5/99.

Code was added to prevent automatic replying from vacation program for
example to open lots of new requests. Now no new requests will be opened
if the same message was previously received from the same emaill address
within 1 hour. Currently the messages are regarded as the same if the lengths
of their subject lines and bodies are the same. A new checksum might be
needed to fine tune this trick. 8/4/99.

The command line interface wreq now has a new option "-t#" to turn off
or to set line truncation width in the output. Idea from "John S. Quarterman"
<jsq@mids.org>, 8/4/99.

It now tracks users by full email addresses, rather than just the their
usernames (uids), to prevent uid collision at large sites. Uids are still
displayed in the lrequest listing, but it's no longer used to figure out
user's email. Currently in the code, I still assume that the uids are unique
among all powerusers for a given group and checks were added in the source
to make sure that. A normal user can have the same uid as a poweruser.
Idea from Joe Pruett <joey@q7.com>, 8/4/99.

Add $useHTTPauth to req-config to set if HTTP authentication can be used.
Idea
from "Bitt Faulk" <wfaulk@totalsports.net>, 8/4/99.

Fix the way the cookies are parsed. Idea from Ian Goodacre <goodaci@intraweb.gov.on.ca>,
8/4/99.

Statuses of requests are now group-wide configurable. Wreq now has some
silly default statuses to get you started. To set your own statuses, first
load wreq configure page req?create in your bowser and select a group.
In the "Status and =>Action" textfield, fill in one status per line. Each
status can have an action associated to it by using the "=>" symbol; statuses
w/o actions are just used as labels in the request database. Currently
actions can be any of "resolve, info, stall, open, reopen". For example,
to add a status called "see ya" and you want the request to be resolved
each time you change a request's status to it, just add the line:

see
ya => resolveTo set the status for a request as poweruser, you will see a status
selection menu in the same row with the Priority selection menu when you
display a request in the lower frame. On the status menu, statuses with
associated actions are marked with a "*" next to them. To change the status,
just select the status you want ans submit the form. The old action buttons
for changing status still work; so I don't have to force everyone to use
the new things. 2/17/99.

Power users can now access a wreq group from anywhere on the Net
by using a SSL capable browser like Netscape 4.x or IE 4.x, provided that
your wreq is running on a secure web server. This will make the host/IP
based access control easier to handle for mobile support people. 2/16/99.

It's easier to add new power users to a group and set their initial passwords
now. To add/remove power users, load in the config page wreq/req?create
in your web browser, choose your group list name and scroll down to the
"Local Support Email List (PowerUsers)" textfield box. To add a new power
user, just simply add his email address in the box, one per line, and then
submit the form. The email address can be any valid form like "a@b" or
"x y <a@b>". To set or change ANY poweruser's password, just append
" : pass" to his email. for example, to add joe@foobar.com to this group
and set his password to joebar, all you have to do is to add this line:

Add an email button to FAQ page for powerusers to email a FAQ to an email
address. Idea from b.campbell@thehub.com.au. 2/1/99.

Subscribers to a group now are allowed to view the content of a request
on the web. They are also allowed to comment on it. Currently you are allowed
to comment on a request if you are a poweruser, the requester, a subscriber;
or anyone with a valid login if the 'all acount must have password' option
is not set in your configuration. Idea from Thomas Ploss <thomas@delix.de>,
12/10/98.

A new button 'noFrame...' or 'Frame...' was added to the top frame to turn
on/off frames. In no frame mode, a new window will open up when you click
on a request number. Note this button won't show up if you have javascript
turned off in your browser. 12/9/98.

A new button 'faqWin...' was added to the top frame. When you click on
it, it'll bring up the FAQ list for the group in another browser window.
This way it's easier to see both your request list and faq list at the
same time when you are working on a request. 12/8/98.

The command-line wreq now requires an email address and password for the
wreq server to properly authenticate users. When you run wreq the first
time, it'll ask your email address and password. It saves them encoded
in your ~/.wreqrc file for later use. So make sure your .wreqrc file and
the cookie file are not readable by others. 12/7/98.

Integrated support for the standard HTTP authentication. Now you can choose
between the cookie or HTTP authentication methods for your wreq server.
I prefer cookies. To enable HTTP authentication, first you need to upgrade
to version 2.6 or higher. Next make sure your web server support .htaccess
basic authentication file:

Note that the passwd file for wreq is used for HTTP authentication which
assume that your web server understands GDBM files. Apache server's mod_auth_dbm
module can read it with a really simple patch.Please
let me know if your server can't read GDBM but can read some other formats
and you want HTTP authentication. Put this .htaccess file in your wreq
script directory and set the $useHTTPauth variable in the file 'wreq'.
That's all. 12/7/98.

The format of the req/passwd file has been changed to prepare for the support
for the standard HTTP authentication. To update to version 2.6, you must
update your passwd file by loading "req?create" once. 12/7/98.

The way wreq uses cookies has been changed. It used to use cookies to keep
track where you are listing and which request you are working on and it
sends a new cookie to your browser every time you load a new page. This
could lead to inconsistent cookies if you open wreq in multiple windows.
Now cookies hold only your email address and auth code; all the other state
info is embedded in the pages themselves. New cookies are sent to browser
only when you click on "Login" and "Lgout" buttons. Now you can open wreq
in multiple windows. 12/7/98.

A new configure option was added to let you restrict access to your supporting
group only to those email addresses listed under "Local Support Email
List". They can access from any hosts. 12/7/98.

A new configure option was added to allow you to require that all logins
must have a password. If a user hasn't logged in before, when he emails
the next request, a new login will be created for him and the autoreply
message will have the login name and password for him to access the web
interface. Idea from Thomas Ploss <thomas@delix.de>, 12/3/98.

A new param $TEXTAREAwrap was added to 'req-config' file to determine how
do you want all the TEXTAREAs to be wrapped. This will be one of the personalizable
options later. 12/3/98.

A new configure option was added to display any announcement or notice
just before the group listings in the top frame. Notice there is also one
for group info or instructions for subscribers. 12/3/98.

The web table/form used to present the content of a request has changes
for powerusers; it's still the same for normal users. Now the "ActOn" button
and related codes are gone. A poweruser can change everything of the request
within the standard request display in the lower frame. An extra "Update"
button was also added near the top for easy access.

Fix to fork() in mailSubs. The update pages will return quickly even when
you have lots of subscribers. 12/7/98.

Change to login: When a user relogin (i.e., with a valid cookie) his account
which has no password, any password he uses will become his password for
future logins.

Version 2.6 is here. MAJOR change on who to
send mail to: New request, either from email or from the web form, will
be sent to req-dist list and any subscribers to that supporting group.
Any followup reply from the original requester will be sent to the owner
of the request (or req-dist list if no one owns it) and subscribers. Any
update from the owner will be sent to the requester and subscribers. Any
update from others will be sent to the requester, the owner(or req-dist)
and subscribers. In the web form, user can use checkboxes to change who
to send to; and email submissions will follow about rules. To continue
using the old rules, you need to set the variable $useOldMailRules
in 'req-config'. Ideas from Greg Connor <gconnor@pa.dec.com>
& Bruce Campbell <b.campbell@thehub.com.au>, 12/2/98.

Quick view of active request numbers in each group. The group selection
button in the top frame now shows the numbers of active requests in each
group next to the group names. This gives you a quick view of how things
are going in each supporting group. The counts are automatically updated
when one adds/deletes/... requests from an active list. To initialize the
counts, just list any active lists or hit reload in the top frame. To force
it to reset the counts, set the variable $needwriteconfig in the file 'req-common'
and reload any active list. Don't forget to unset it after reloading; or
you'll do it every time! Idea from b.campbell@thehub.com.au, 12/2/98.

The "Delete" button now actually does deleting. It now sends the deleted
requests to a separate database instead of clustering up the resolved database.
Deleted requests can't get any new messages; but you can reopen it. To
claim the disk space used for those deleted requests, you can just remove
those files from data/req/group#/deleted/year/*. An automatic purger will
be implemented when it's needed. Patch from Fritz Zaucker <zaucker@ee.ethz.ch>.
11/30/98.

The autoreply message to request sender is now configurable through the
wreq server config form. Ideas from Joseph Heiser <Joe@EnterpriseIT.com>.
11/30/98.

The command-line interface, wreq, now does a lot more. You can use it to
list/view/merge/unmerge/move/take/cant/resolve active requests. Run "wreq
-h" to see help and examples. 10/19/98.

Login now uses your system password as a backup for authentication. In
the login from, you can fill in your regular system login password; wreq
will let you in and update your wreq password to be the same as your regular
password. Useful feature for not having another password to remember.
Of course, you can still choose to have a different wreq password. 10/15/98.

Now "Login" and "Merge" buttons are easier to find for new users. The "Merge"
button shows up near the top in the lower frame when you display a request
as a poweruser; it has a more intuitive form. Idea from"John
S. Quarterman" <jsq@mids.org>, in his SunExpert magazine vol 9, Oct
1998 article. A few notes about the article: 1. wreq has changed
a lot since the article was written. 2. wreq's own authentication login,
combined with netscape cookies, means that you only have to login once,
as long as you don't delete your cookie file; 3. There is a simple command-line
interface, wreq. 4. The action buttons near the beginning, when
you display a request in the lower frame, are meant to be used for quick
resolve, delete, etc, without adding anything to the action log or email
the sender. The action buttons coming after the action log are meant to
make it easy to add a note to the action log or email sender while you
perform those actions. 5. You can perform actions through email using a
special formatted subject line. 6. Interested users can subscribe to each
supporting group list, to have all email to that group sent to them as
well. 7. I feel the need to write a comprehensive documentation for wreq
to explain most hidden features. 8. Javascript is optional in current release,
but I still like frames. 8. Thanks all for your help. 10/16/98.

The html code for displaying a request in the lower frame was changed to
not use <pre>...</pre> anymore; so the browser now can wrap most
long lines within its window width. 10/14/98.

A new variable $DOLOCALFORM was added to the file 'req-newreq' for people
to customize the request submission form to better fit the style of your
other computing support pages. Just edit between the marked lines in that
file to change it. Our local page looks like this.
Use 'req?local' to access the new layout. 10/12/98.

An util procedure 'syncAll' was added to the file 'req-misc'. This can
be used to update the global index file and fix any existing strayed merged
requests for a group, by running "perl req-misc syncAll group#" at a command
prompt. 10/9/98.

syslog was added to logit() in 'req-common'. To log everything to syslogd,
just uncomment the first few lines of logit(). Ideas from Serge.Robinson@int-evry.fr.
9/12/98.

'req-convert' was updated for converting req data into wreq version 2.x
format for new wreq servers. You should only run it right after configuring
a new wreq server. 9/12/98.

A loop detection was added to deal with messages forwarded back to wreq.
Also the email address parser was much better now. Ideas from Andrew
Smith <ccasmith@prentice.uq.edu.au>, 9/11/98.

There is now a 'download' button when you display a request, which you
can use to save the request action log into a local file. Suggested
by John Pate <johnny@mids.org>. 9/11/98.

A simple command line interface to wreq was added to make accessing backlog
easier over a slow link. To install it, you need to edit the file 'wreq'
to set a few params and copy or link it over to your common bin path like
/usr/local/bin. Run 'wreq -h' for help. Ideas from "John S. Quarterman"
<jsq@mids.org>. 9/11/98.

Big GUI changes: The frames A1 and A2 are removed to save screen space.
All the links in A1/A2 are now in the frames M1 and M2. Ideas from John
S. Quarterman <jsq@mids.org> etc. 9/9/1998.

Code added to properly route mail to moved and merged requests. 7/31/98.

Add an optional parameter to req-mail as a way to guarantee requests are
delivered to the right group in case you have users whose email headers
are always messed up bad. For example, if I have 'wreq "|/foo/req-mail"'
and 'req wreq@math.duke.edu' in our /etc/aliases file; to use this new
feature, I'd change them to 'wreqx "|/foo/req-mail wreq"' and 'reqx
"|/foo/req-mail req"' and add 2 more aliases 'wreq wreqx@math.duke.edu'
and 'req reqx@math.duke.edu'. The reason that I add the extra wreqx and
reqx is to force req-mail to run on the mail server only, since we are
using NIS to distribute aliases map among clients. The 'req-mail groupname'
alias will deliver all messages to it to the group groupname, no matter
what the message has on the Subject line. Ideas from Andrew Smith <ccasmith@prentice.uq.edu.au>,
6/26/98, 7/8/98, 8/4/98.

More intelligent in handling bounced messages from Mailer-Daemon. It forwards
the message to the web server and the server looks through the message
header and body to figure out the group name and req number of the original
message; then it sends the message to the owner of the request, or the
1st poweruser for the group if the request is not owned. Ideas from
Andrew Smith <ccasmith@prentice.uq.edu.au>, 6/26/98.

Now the labels for "OS Type" and "Area" are configurable params, so you
can use wreq to create support groups for non-computer areas. Ideas
from Kees Cook <ccook@urbana.css.mot.com>, 6/25/98.

Add a filter to handle MIME-base64 attachments in all messages. Idea
from Bradley Marshall <bmarshal@plugged.net.au>. 6/1/98.

Fix for handling some wacky cookies with more than one '=' in them, from
ccook@urbana.css.mot.com, 6/1/98.

Changes to the ordering of requests in the list window: 1). Click on the
links in the frame A1, the requests with new info from the request senders
will be listed first, then the requests you own, etc; all sorted by priority.
2). Click on the 'Owner' heading in frame M1, all requests you own, then
requests owned by no one will be listed first; all sorted by priority too.
Ideas
from Joseph Heiser <Joe@EnterpriseIT.com>. 5/20/98.

New subroutine sameEmailReqs() to decide which list a req is sent to; which
makes it possible to use the same list names on different mail servers.
The "Message-Id" mail header is used to figure out the origin of a message.
5/4/98.

The links in the frames A1 and A2 are now all colored blue. CCS code
from "Brian J. Doherty" <bdoherty@mailsvr.icon.palo-alto.med.va.gov>,
5/4/98.

A possible flock locking problem on systems which don't have flock() function
such as solaris 2.x was fixed in version 2.2. Ideas from David.Seddon@cmis.CSIRO.AU,
4/30/98.

New features in version 2.1: 4/27/98

A new configure param was added to allow users to subscribe to a req list
to have all email to the list mailed to them. You can allow subscription
to your list by checking the "Allow subscriptions to this list?" box in
the server's config web interface. You can also edit your subscribers list
there. To subscribe, a user simply sends an email to the list's email address
with the subject line: subscribe or unsubscribe. You can subscribe others
to the list by changing the subject line to [subscribe uid@host] or even
[wreq subscribe uid@host], where wreq is the name of the list. This feature
turns wreq into a miniature mailing list manager. Note those brackets [
and ] are not optional in the later case.

The usage report 'Statistics' function has been improved to output the
results in a gif picture. For a sample, see the snapshot
here. The data for the plotting is collected on weekly basis and is labeled
using the date of the Saturday in that week. The red curve represents
the total open requests at the end of each week; the orange curve the total
new requests received in that week. The blue curve is the requests resolved
in that week. If a staff name is selected before plotting the graph, the
requests resolved by that person in each week will be plotted using the
blue curve; and a new dashed blue curve will show the total requests resolved
by all your staff in each week. Pretty cool, right? This is done using
the GD module in perl. GD-1.18 is available from places such as ftp://ftp.duke.edu/pub/perl/modules/by-module/GD/,
and the installation into your existing perl is really easy: perl Makefile.PL;
make; make install; and that's it. Note sometimes your web browser's cache
may prevent you from seeing the latest graph; you may need to reload the
image to force it to get directly from the server.

The usage report 'Statistics' function is more reasonable and informative.
For example, when it calculates the average time-span for a request to be
resolved, it excludes (or stop the clocking) the time period while a request
is in Stall or Info status. Hints from "Robert Van Den Huevel" <rvdh@ecs.csun.edu>.

To prevent mail looping, no mail from Mailer-Daemon will be processed by
wreq; it simply sends to $error_cc.

New features in version 2.0: 4/6/98

Support multiple supporting lists on the same web server URL and under
the same data directory structure. To create a new group/list, use the
"Config" link in frame A2, fill in the list name and the email aliases
for users to send requests to and so on, use the same version 1.x password
or version 2.x default list password, then click on "Send". You might want
to change some other options too. Do not forget to add the new email aliases
to sendmail on your mailhost. Note you won't be able to list a group if
you don't have permission to do it. You can delete a group too. There is
also a 'move' link in 'A2' for you to move a request to another group.

Option was added to make all request contents viewable by everyone having
access to the group. When submitting a request, a user can also decide
if to make his request public.

Option was added to make a comment from the sender of a already resolved
request to reopen that request.

The web submission form has a choice of which group to send the request
to. Requests from email are sorted into different groups by first looking
at the 'Subject:' line: group name can be specified in the formats "[groupname#...]..."
or "[groupname]...". Then it looks through the 'To:' and 'Cc:' lines to
find any wreq related addresses, and lastly it checks the hostname of the
message to decide where to put the requests. If it can't decide, it adds
the request to the default list.

Option not to send the auto reply message to some given email addresses.

You can now submit requests on behalf of other users: On web, click on
'Add' in the frame A2, fill in the user's email and click on 'Send'.
Using email, enter the other user's email in the 'Subject:' line in one
of the following formats: "[groupname#nnn email]...", "[groupname#email]....",
"[groupname email]..." or "[email]...".

Two subroutines are added in the file 'req-misc' for transporting GDBM
database files between different systems: First chdir to the wreq script
directory and run the command 'perl req-misc exportAll' on the old system
to write all GDBM files in text format, copy the whole data directory structure
to the new system, and run 'perl req-misc importAll' to write them out
in the new system format.

The command 'perl req-misc resetSupportPassword group#' will reset the
group group#'s password to the program default.

A text template was added to the web ticket creation form description box.
Edit the template in the file 'req-config'. 2/12/98, by Andrew Smith
<ccasmith@cc.uq.edu.au>.

GDBM_File::reorganize() is called automatically after every 100 deletions
to free up unused space in the dbm files to make these files as small as
possible. To force it to clean up for the first time, put the number 1000
in the file data/req/1/active.lock; it will shrink the active file the
next time a req gets updated.This problem with gdbm files was reported
by Scott M. Trautman <scott@gdinet.com> and others. 2/11/98.

Clean up 'req-mail' and now you can send req updating commands and submit
new faq/tech/syslog/sos via email, just by changing the subject line to
"Subject: [Cat #nn cmd]..." or "Subject: [Cat]....", where 'cmd' can be
any of 'update', 'info', 'stall', 'resolve', 'reopen', 'open', and 'comments',
where 'Cat' can be one of your supporting group name, or, 'faq','tech','syslog'
or 'sos'. 1/1/98.

All the frames are loaded using the default URL by reloading if necessary,
to fix possible problem with cookies. 11/29/97, idea from "Matthew Stier"
<Matthew.Stier@tddny.fujitsu.com>.

Fixed the 'ActOn' button to update any changes to Name/Email/Subject etc
when you click the Update/Mail buttons. 11/29/97, idea from "Matthew
Stier" <Matthew.Stier@tddny.fujitsu.com>.

The '(Current ....)' message in M1 was splitted into 2 parts to make it
stay current. 11/29/97.

Filter the input buffers according to a CERT advisory. 11/29/97, by
Andrew Smith <ccasmith@cc.uq.edu.au>.

Berkeley DB_FILE can be used for the database files. 11/29/97, by Andrew
Smith <ccasmith@cc.uq.edu.au>.

A new Syslog group was added for informing users about major system-wide
changes. Note before you can add the 1st message to it, you need to click
on the 'Syslog' link in the frame 'A1' first to make the necessary directories.
11/97.