A ticket is an object describing and tracking a bug, feature request, project, action item, or any other type of thing that you might want to track within a software development team.
Unlike some issue tracking systems, CVSTrac doesn't associate significant amounts of process overhead with tickets. There aren't any constraints on who can change specific fields, what states can lead to other states, who can assign tickets, etc.
Tickets have the following fields available:
- Ticket Number is unique to each ticket and can be referenced in wiki markup using the #n syntax.
- Title should be as descriptive as possible since it appears in various cross-references, reports, ticket link titles, etc.
- Type describes the kind of ticket, such as bug, action item, etc. Ticket types are configurable.
- Status describes the current state of the ticket. Possible states are also configurable.
- Severity defines how debilitating the issue is. A scale from one to five is used, with one being most critical.
- Priority decribes how quickly the ticket should be resolved. This isn't necessarily related to Severity (i.e. a serious bug in a non-operational product isn't always high priority).
- Assigned To identifies which CVSTrac user should be handling the ticket.
- Creator identifies which CVSTrac user created the ticket (including, possible, anonymous)
- Version should be used to report the product version related to the ticket.
- Created shows when the ticket was created.
- Last Changed shows when the ticket was last changed.
- Subsystem is intended to identify which component/area has a problem. This list must be configured by the administrator.
- Derived From lists a parent ticket, if any.
- Contact lists a way to get hold of the problem reporter. Typically, this is an e-mail address. Contact information is not made available to anonymous CVSTrac users.
- Description is a wiki field providing information about the nature of the ticket.
Additional custom ticket fields may be defined by the administrator. This could include things like billing information, due dates, completion percentages, resolutions, reporting organizations, etc.
The Remarks property is a special wiki field which can be editted directly, but also has a special append option where users can add comments and discussion to a ticket. When appending, a timestamp and user name is automatically added into the remarks.
Tickets may also have children which reference them in their Derived From properties. These child tickets will be listed in a separate section, allowing a certain amount of hierarchical project task management.
A separate page containing a full ticket history provides a chronologically ordered list of all events associated with a ticket. Property changes, remarks, check-ins, attachments, inspections, etc, are all listed here.
Changes to certain fields, such as Description and Remarks are shown in diff style.
Arbitrary files may be attached to tickets. This could include things like screenshots, specifications, standards documents, etc. Attachments are of limited size.
Creating New Tickets
A new ticket is created by clicking on the Ticket link available in the navigation bar. A new ticket form will be opened and the user would then enter all appropriate information.
The ticket form is a combination of text fields and dropdown menus. Dropdown menus provide a fixed set of items to choose from and are often populated with reasonable defaults.
A large text area is provided for the problem description. As with most components of CVSTrac, this text area allows (and encourages) the use of wiki formatting.
As with any such system, detailed and complete information is encouraged.
Ticket properties can be editted by following the Edit link in the ticket view. Remarks can be added by following the Add remarks link in the Remarks area of a ticket view.
In some cases, ticket changes may result in notifications being triggered, if the administrator has configured this.
When in the history view, it's possible to undo changes. A user with delete permissions or the user responsible for the change can do this within 24 hours while a user with admin permissions can do so at any time. An undo link is included at the last item of the history page in this case.
Users with setup permissions can always delete tickets. Tickets should only be deleted as a last resort. If a ticket contains valuable project history, it should instead be closed.
Users (except anonymous) with delete permissions can delete tickets created by anonymous within 24 hours of ticket creation.