Hosted Bug Tracking and Project Management System

Administrator's Guide

This guide will help you configure the BugHost system for your particular needs. There are a few tasks that must be done in order for users to start using the system. Please read and follow these steps in order to start using your new account quickly.

Step 1. Create Projects

The first step is to decide what projects you will create for your company. You can configure each project with separate user access, security, applications, priorities, severities, status and types of bugs. One project was created when you signed up. You can edit this project and create new ones.

Step 2. Configure Security

There are a number of options available to you for configuring security for each project. There are a few basic security rights that are applied to each field within BugHost. They are:

Allows a user to view the data in a particular field
Allows a user to submit information for a particular field
Allows a user to edit or change bug information for a particular field
Allows a user to add certain information, such as files or notes to a bug report
Allows a user to delete certain information, such as a file attachment
Grants certain access to perform a task, such as Opening, Closing, Fixing and Verifying bugs

The easiest way to configure security is to set up security groups based on the type of users accessing your project. For instance, Administrators, Programmers, Testers, Managers and Technical Writers are some common group names. You can also name groups based on the type of access allowed, such as View Only, Submit Only, and Full. Most of the time, you will be able to assign each user into a single group and gain access to bugs the same way his or her co-workers do.

You can assign a user to only one group. If you need to have special access for one user, you can create custom security for that user. Setting custom security will allow you to control every function for that particular user only.

A user will not be able to access a project until security has been granted for that project. You should create a user account and then assign the user to a security group immediately to avoid access problems for that user. You can also assign users directly to security groups if the groups have been created before the user account.

Step 3. Create User Accounts

User accounts are shared amongst all projects within a single company. Depending on the security settings, each user can have access to any of the projects you create. Each user is required to have a unique and valid email address.

Once you create an account, a random password will be sent to the user via email automatically with information on how to log in. The user will only be able to log in to the project(s) you allow access to (see Step 2).

Users can participate in the bug life cycle by "owning" bugs. When a bug is added to the system, it is either assigned to nobody (possibly for review by a bug review team) or to a specific user (to start fixing the bug immediately). When the user finishes the work, he or she can assign it to another user to have further evaluation or work done. Eventually, the bug gets fixed, verified, and then closed. Therefore, it is necessary to decide which users you will add to the system and which ones do not need to participate in the bug life cycle.

After you create user accounts, it is important to configure the security settings.

Step 4. Configure Applications and Modules

Applications and modules are areas within your project that help classify where a bug was found. You should define all areas at a high level for your project. For instance, if you have a word processing project, you might set up the following Applications: Spell Checker, Editor, Preferences, Macros, etc. Modules can be further classifications of those applications, such as DLL's, functions or other areas within an application.

Step 5. Review Priority, Severity, Status, Categories, Operating Systems, and Bug Types

Several priority items, severity items, status items, operating systems, and bug types have been configured to get you started quickly. These items help classify a bug and help users find bugs efficiently. Take a few moments to review each of these items and configure them for your environment.

You may also want to define categories to help classify your bugs even further.

Step 6. Configure Submit and Edit Forms

Once you have completed Steps 1-5, you should review what fields are available on the submit and edit forms. These forms are presented with a set of defaults which allow you to get started quickly. You should make sure that all the fields are configured for your environment.

Each form allows you to set which fields are displayed, which ones are required and what default value to use for users who do not have sufficient security rights. Check each box on the left to display the field. Check Required for each field that you want to enforce. Set a default value to be used if the information cannot be supplied.

You can have certain fields auto-populated by requiring them but not showing them. If the field is not visible for the user to fill out, it will use the default value when the bug is submitted (if it is required).

Configuring WebSubmit

WebSubmit is a feature of BugHost that helps you to put up a Web page on your own Web site to accept input from your customers without creating a unique user account for each customer. You can have your customers submit bugs directly into your BugHost project from your own Web site. For more information, please see the WebSubmit Guide.

Exporting Data

If you should decide to import your data into another program, such as a spreadsheet, you can export all of the data in your project. From the Admin menu, select Projects, then the project you wish to export, and then click on the Export link. The data will be exported to a text file, using a standard Tab-delimited format. Each field will be separated by tabs, which most programs should be able to read.

Note: Some fields have a carriage-return and linefeed character to allow text to flow to a new line. The export will convert these to #CRLF# to prevent the text from wrapping around and causing the import to fail.