Workflow

BUGtrack is fully customizable and has very flexible workflow with a set of business rules:

• Each record is uniquely identified by a system-generated numeric ID;

• Audit-trail - each action performed with a bug is recorded in its history;

• Record’s discussion thread cannot be edited or deleted once submitted;

• A bug can have only one assignee at a given moment of time;

• A record cannot be closed until it is resolved;

• To change a closed record, you need to reopen it;

• The following statuses are automatically assigned to the record when it progresses through a workflow: open, resolved, and closed.

For example, the tester opens a new bug, and assigns it to a developer to fix.

When a developer fixes the bug, the bug acquires the "Resolved" status.

The system automatically reassigns the resolved bug back to the person who initially opened it (typically a tester). At this stage the bug is resolved, but not closed yet. The status is "Open", but not "Active" It gives the bug initiator (the tester, for example) a chance to test it and make sure that the bug was really fixed the way it supposed to be. If the tester doesn't agree with the fix, the bug may be reactivated, so it will be automatically reassigned to the person who resolved it (a developer, for example).

When a resolved bug passes the test by it's initiator (a tester, for example), it may be finally closed, so the status will be changed to "Closed". The bug may be closed either by it’s initiator or by a manager.

If it is discovered later that the bug fix wasn't complete, the bug may be reopened.

BUGtrack allows setting up an alternative type of workflow when all the bugs may be assigned to the manager only, so the manager will reassign them to appropriate persons.

To set up workflow when all the bugs go through the Project Manager, you would need to select "Assign new records to this role" for the manager only, so the system will always select the manager to assign bugs. The manager will be able to reassign bugs to anybody with the "Permission to resolve records" authority.
Make sure that only managers are able to "Reassign".

The person who creates new records should NOT have "Permission to reassign records to another person" authority in "Roles" settings in order to setup this type of workflow due to the following reason:

If the bug creator would be allowed to reassign, the system would bring him all the people who have rights to resolve to let him choose from them. If he is not authorized to reassign, the system selects only people who have "Assign priority" checked in "Roles".

BUGtrack workflow process is illustrated in the following diagram.

Example

• User Jill finds a problem in a project A, so she creates a new bug and assigns it to user John. John receives an e-mail notification.

• John finds that the details that Jill has provided are insufficient for fixing the problem, so he reassigns the bug back to Jill asking her to provide more details. Jill receives an e-mail notification.

• Jill adds the required details and reassigns the bug back to John. John receives an e-mail notification.

• John fixes the problem and resolves the bug; the bug is automatically reassigned back to Jill. Jill receives an e-mail notification.

• Jill finds that the bug has been resolved and verifies that the problem has been really fixed the way it is expected to be. She finds that the problem still persists in certain circumstances, so she reactivates the bug, and it becomes automatically assigned to John. John receives an e-mail notification.

• John has an idea on how to completely eliminate the problem, but he has no time, so he edits the bug to put down his idea. In addition, John decides that the problem in fact belongs to another project B, so he moves the bug to project B and reassigns it to user Jack. In addition, he unsubscribes from the notifications on the bug’s updates. Jill and Jack receive two e-mail notifications each: one for the Move event, and the other one for the Reassign event.

• Later, Jack gets to the problem and finally resolves the bug. It is automatically reassigned to Jill. Jill is notified by e-mail.

• Jill performs final testing and finds the solution satisfactory, so she closes the bug. Jack receives an e-mail notification.

• At any other time, if anyone finds that the problem still has not been fixed completely, they will be able to reopen the bug, and it will be automatically assigned to Jack as to the last person who resolved the bug, and he will be notified by e-mail.

In addition to the basic principles described above, records maintenance is governed by user role permissions and project settings.

The project navigation picklist is an important navigation tool. It is a field located above the upper tab line of the BUGtrack interface. The drop-down list contains the names of all active projects to which the current user has access and plays the role of an instant filter, which allows you to instantly refine your lists according to the selected project.

Next: Creating Records