|
Default Fields
Fast BugTrack is packaged with a set of default fields to help ease the installation of the product and allow users to get up and running in the quickest amount of time. The default fields can be customized using the "Default Fields" menu, where there is also the option to disable some of them. In addition, their attributes can be changed in the "Field Control" menu, where they can be hidden /protected if undesired.
In some cases, customers choose to rename them by changing the text strings in the "Customize Strings" menu. Unfortunately, the default field types cannot be changed (ie: Area is a drop down item not a text string). If you wish to change a default field type, you will need to disable or hide the existing one and then create a new custom field.
The most common default fields are listed in the following table :
| Project | A development team can easily be involved with a number of different products or projects. The project field allows bugs to be grouped according to the products that they are discovered in. In addition, groups of users can be limited to specific projects in the system. Updating these values will affect the menus that appear when creating and modifying bugs. If a value is deleted, and bugs are currently set to this value, they will continue to be set to this value. |
| Status | The status fields refer to the different states that a bug or issue can assume. The idea is to have each bug run through these steps until it is eventually fixed and closed. The default status fields (in order) are : Open Ready For Retest Rejected Deferred Closed Updating these values will affect the menus that appear when creating and modifying bugs. If a value is deleted, and bugs are currently set to this value, they will continue to be set to this value. |
| Priority | A unique integer value (number) must be specified for each priority. When priorities are displayed, they are sorted by this numeric value. The priority field is used to rate the importance of a bug to the system. This allows a team to sort issues according to importance, and fix the most important problems first. The default setup is : 1 - Emergency 2 - High 3 - Medium 4 - Low 5 - Very Low 6 Change Request |
| Environment | An environment refers to the system where the problem or bug was discovered. The purpose of this field is to provide helpful information to the individuals that will eventually try to reproduce the bug and fix it. Typically, this includes the type of machine and OS being used. (ie: Windows, Unix, Mac)Updating these values will affect the menus that appear when creating and modifying bugs. If a value is deleted, and bugs are currently set to this value, they will continue to be set to this value. |
| Version | A version can refer to the Environment Version or to the Version of the item that is being tracked. This field is a text string by default and can not be changed. If you desire another field type, the best solution is to disable this field and create a new custom field. |
| Area | An area refers to the area within the product where the bug was found. This information can help any individuals further on in the cycle, so that they have enough information to work on the problem. Updating these values will affect the menus that appear when creating and modifying bugs. If a value is deleted, and bugs are currently set to this value, they will continue to be set to this value. |
| Description | This field allows every update to have a unique description. In many cases, this field is renamed to Notes or Comments.It is by default a history field so that every historical update is shown with the description applicable to that change.It is a unique field in that there is no overall value that is shown in the details section of the view/edit bug screen. In this case, it is just a historical field. |
The default Project Management fields allow you to link related issues together (Fields can be added, moved or removed, depending on your requirements). Once linked, the attributes of the parent fields change to reflect the children :
| Requested Due Date | A date field that can be used to record a Due Date for the issue. Commonly used when creating events to notify about overdue or upcoming due dates.
|
| Actual Completion Date | A date field commonly used for recording the date an issue is Closed or when work is completed.
|
| Percent Complete | A numerical field used for recording the percentage of work that is complete.
|
| Estimated Hours | A numerical field used to record the number of hours that an issue is estimated to require.
|
| Actual Hours | A numerical field used to record the number of hours actually used.
|
| Parent | The parent field allows you to link an issue to a related parent issue. When an issue becomes a parent, it will then list all children in it's details section. Children are listed with field values in a similar way to the normal main menu (see child example below).
Additional Properties :
A parent issue can not be closed until all of it's children are closed.
The "Requested Due Date" and "Actual Completion Date" become readonly and is calculated as the earliest due date of the children
The "Estimated Hours", "Actual Hours" and "Percent Complete" fields become readonly and are calculated as a sum of the values for the children.
|
Child example
|