WebIssues Manual

John Smith is a new employee in your company and just learns to use various programs that he needs for work. One of the accounting programs, Big Finances, will not run and instead displays an incomprehensible error message. Smith logs into the WebIssues system and opens the Help folder. Then he adds a new issue and names it “Problem with Big Finances”. In the issue description he explains what he was doing when the problem occurred. He also attaches a screenshot of the error message as an image file.

Since you are trying to help new employees, you peek to the Help folder on a regular basis. All threads (issues) are by default sorted by the date of last modification. What's more, new threads, which you haven't read yet, are marked with a yellow, closed envelope and with bold font — just like in many email programs and discussion forums. You open the issue, read the description of the problem and open the attachment.

This is a fairly common problem — it's enough to delete one wrong file and the Big Finances program should work again. You add a comment to the issue, describing the solution. Shortly thereafter, Smith looks back to the Help folder and observes that his issue is marked with a green, closed envelope and bold font. This means that someone else has changed the issue since the time when he last opened it. Smith reads your comment, performs the described steps and runs the program. Then he replies that the solution you described helped him solve the problem. Looking at the Help folder again, you soon notice a green envelope; you have just helped someone again, without even leaving your seat.

Half a year later the company has grown so much that you are no longer able to help all employees without neglecting your own duties. Worse still the company started using new software, Great Finances, which you don't know so well and you can't solve all problems by yourself. Regular forums were no longer sufficient, so it was necessary to introduce a virtual service desk.

Smith has been using the new Great Finances program for some time and he's doing well, but he just encountered a problem with accounting invoices. Smith logs into the WebIssues system and opens the “Great Finances” folder — because of the large number of requests, they had to be divided into separate folders associated with various programs. When adding the new issue, in addition to the name, he now also has to fill some additional fields (attributes) — the type of problem, the name of the module and the version of the program. He also includes a detailed description of the problem.

You continue to regularly peek into the service system, but you mainly deal with assigning new requests to others and you only solve issues related to Big Finances by yourself.

Since there are a lot of requests in the system, you are now using the “New Requests” view, which displays only those issues that haven't been yet assigned to any person. In this view, there is a new request created by Smith. Without even having to read the description of the problem, you look at the type of problem and the name the module and then you start editing the issue. In the “Assigned To” field you browse through the list of members and pick Adam Green, who specializes in accounting invoices. After saving the issue it disappears from the New Requests view, since it has already been assigned.

Adam Green uses the “Active Requests” view, in which he sees only issues assigned to him, and which have the Active status (which is the default for newly created requests). Because he doesn't always have time to keep looking into it, he turned on an additional notification, which informs him by email about new issues in this view. Green needs more information from Smith, so he adds a comment asking for it. Smith sees the issue in the “My Requests” view, containing all active issues which were created by him — a green icon, just like before, informs him about all changes to the attributes and new comments.

In many situations, the life cycle of issues can be even more complex, and many people may be involved in the process. A common example is the life cycle of a bug in the software. It's created by the tester, then it's verified and assigned by the project manager to the appropriate programmer. The programmer fixes the bug, and the tester can either accept the solution and close the bug or reject it and assign it back to the programmer.

Such processes in which individual steps involve different people are often called workflows. In some systems, the workflow is defined in a rigid way and either can't be changed at all or can only be slightly modified. Other systems have sophisticated tools for designing a workflow.

In the WebIssues system the workflow isn't enforced in any way, but it can be very easily modeled by appropriate use of attributes (for specifying the current state of the issue and the assigned person), views (for restricting the set of issues to those in a particular state and assigned to the appropriate person) and tracking the status of issues (for indicating new and modified issues).

Persons involved in various stages of the workflow can use different views to focus only on those issues that require their intervention. For example, a programmer is generally only interested in active bugs assigned to him, but if necessary, he can access all bugs, regardless of their status, for example to find other bugs that could potentially be related to the currently processed one.

Also the supervisors of the whole process can use views to check the number of active issues or to take appropriate steps when a bug remains unresolved for a long time. In addition, they can use tools for creating reports or export data to another program (such as a spreadsheet) for further analysis.