Subject: wreq is available for downloading

A request queue for wreq was added on our server, which you can access to discuss wreq-related problems and enhancements. You can *subscribe* to the queue by email with the subject line: [subscribe]  or [unsubscribe]  (note those brackets [ and ] are not optional) .

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

Note to wreq 1.x users: Version 2.x uses a slightly different database format in order to ensure future expansibility. 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.

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:

• 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 deliever 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.
• 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 miniture 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 Staturday 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 ploted 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 timespan 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 strucutre. 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', 'merge', 'unmerge' and 'commnets', 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 acknowledgement. 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.