This doc was last updated: $Date: 2019/07/12 14:11:22 $ GMT.

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.

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:

1. Active requests: all the requests/problems from your department waiting to be resolved.
2. Resolved requests: all the resolved requests of your department or supported group.
3. 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.
4. 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.
5. System Log: A place to log major systems/network changes for users to view.
6. 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.

Installation

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

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

Handle requests

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:

• ---

• Corrected the whitespacing problem in POST to latest httpd server, and updated crypt salt selection. Thanks to Norbert E. Gruener of Max-Planck-Institut. 07/28/2017.
• 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.
• The 'reopen' status/action shouldn't do anything for active requests. Fixed by Daniel Holdren <dholdren@csc.albany.edu>. 1/13/2000.
• Happy new millennium! Y2K date display fix in FAQ by Einar Hillbom <ehillbom@algonet.se>. 1/13/2000.
• 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.
• Make sorting case insensitive in listing. Idea from R P Herrold <herrold@owlriver.com>, 8/20/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.
• Fix a possible problem of file globbing in perl calling tcsh shell. 3/25/99. Idea and code from Darrell Fuhriman <darrell@grumblesmurf.net>.
• 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  => resolve
To 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.
• Limit access to req?create configure info to permitted hosts and powerusers with secure web connection only. 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:

           joe@foobar.com : joebar
That's all you need to do. Hint from Andrew Smith <ccasmith@its.uq.edu.au>, 2/16/99.
• Cookies to a secure web server are transmitted securely now, to make you feel more comfortable in accessing the wreq server remotely. 2/16/99.
• Change exit code of req-mail in case the wreq web server is down, so sendmail will retry when the server is up. Idea from kbruner@wbfa.com. 2/1/99.
• Fix quoted subject line. Idea from Matthew Stier <Matthew.Stier@fnc.fujitsu.com>. 2/1/99.
• Block email from postmaster. Idea from Mike.Andrews@amexchange.ameritech.com. 2/1/99.
• Make poweruser's email address case-insenstive and fix some email address parsing problems. Idea from Mike Andrews <Mike.Andrews@amexchange.ameritech.com>. 2/1/99.
• Annotating 'gives' in Wreq. Idea from Alex Future Bokov <alexboko@umich.edu>. 2/1/99.
• 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:

AuthName WREQ
AuthDBMUserFile /your_wreq_data_dir/req/passwd
require valid-user

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.
• Proper handling of messages from vacation program. And perl syntax fixes, idea from Kees Cook <ccook@urbana.css.mot.com>, 7/8/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.
• Fix a regex problem with list matching. Ideas from Kees Cook <ccook@urbana.css.mot.com>, 6/24/98.
• Fix a problem with faq condense procedure, and limit faq posting and updating to powerusers only. reported by Matthew Stier <Matthew.Stier@tddny.fujitsu.com> and "Jose A. Rodriguez" <Jose.Rodriguez@ac.upc.es>, 6/7/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>.
• Clean up mail header parsing. 11/29/97, by Andrew Smith <ccasmith@cc.uq.edu.au>.
• Add $do_auto_reply flag to 'req-config' for new req acknowledgment. 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.