= Ticket Types =

''This feature is now integrated in Trac since milestone:0.9 (see [1691])''

== Rationale ==

When creating a new ticket, Trac enables you to select 
the appropriate type for that ticket.
Indeed, a ''ticket'' can represent anything ranging from
a problem report, a support request, an idea for a new feature
or actually any artifact that fits in your development process.

Among issue trackers, Trac was initially on the ''undifferentiated'' camp,
everything was treated the same and it was only from the description
that one could tell in which category a ticket would fit.

However, the need for a more structured partitioning of the ticket type
appeared (e.g. #919, #1399) and several Trac sites were actually 
tweaking the ''severity'' field to be the ''ticket type'', or creating 
TracTicketsCustomFields for that purpose.

Now, with the ticket ''type'' field, one is able to store this information as 
part of the core properties of the ticket, which permits to display
the type of a ticket in more interesting places, usually next to 
the ticket number.

== What does it look like? ==

'''Those screenshot correspond to intermediate development status: to be updated (or removed?)'''

|| in the Ticket page's title: || [[Image(tt_title.3.png)]] ||
|| in the TracTimeline: || [[Image(tt_timeline.3.png)]] ||
|| Also, it's the first field you can select when creating a new ticket: || [[Image(tt_new.3.png)]] ||


== What if I don't like ticket types? ==

No problem. With [wiki:TracAdmin trac-admin], you can
use the `ticket_type` command to perform a few actions on ticket types:
 * `add`
 * `change`
 * `list`
 * `order`
 * `remove`

You can customize the ticket types to match your local requirements.

If you delete __all__ ticket types, then the feature is gone!
Trac will work the same way it ever did without ticket types
(i.e. {{{Trac 0.[5-8].x}}} behavior).


== Why is the severity field gone? ==

Trac strives to be a simple to install, simple to use system.
Offering in the default setup a combination of ticket type, 
severity, priority and milestone was deemed too daunting 
for new users.

The advised configuration is therefore:
 * ''type'', for categorizing the ticket
   * '''Defect''':  a bug, anything that does not work as expected
   * '''Enhancement''': a new feature or an improvement over an existing one
   * '''Task''': everything else, something that needs to be done
 * ''milestone'' used for scheduling
 * ''priority'', for asserting the importance of a ticket
   * '''blocker''': basic functionality is not available until this is fixed
   * '''critical''': severe loss of data due to the defect or highly needed enhancement
   * '''major''': defect with major impact / big enhancement
   * '''minor''': defect with minor impact / small enhancement
   * '''trivial''': defect with little or no impact / cosmetic enhancement

However, some users would like to keep the current distinction
between ''severity'' and ''priority'':
 * ''type'', for categorizing the ticket
 * ''milestone'' used for scheduling
 * ''severity'' for trying to assert the __objective__ importance or impact of the ticket
   (the values would be the same as those listed for the ''priority'' field above)
 * ''priority'' to help organize the scheduling within a given milestone
   (fields like '''highest''', '''high''', '''normal''', '''low''', '''lowest''').
   This is more a __subjective__ field, based on other considerations than the
   objective severity (typically those of a product manager :-) ).

In order to support that usage, the ''severity'' field has been kept
in the database. It simply needs to be "activated" by using `trac-admin`'s `severity add` command, or through the web administration page.

== Other issues ==

=== Different custom fields depending on ticket type ===
By: ''pkou at ua.fm''

It would be nice if different sets of custom fields are visible to end user when ticket type is changed.

Rationale: Different ticket types can require different types of additional information that needs to be entered, for example:
 * ''Event'': Due date, location;
 * ''Enhancement'': Source, Benefit, Link to business case/requirement, Review status, Approval status, Links to specifications;
 * ''Defect'': Customer ID
 * ''Task'': ''No additional custom fields.''
Hidden custom fields are initialized with zero/empty values.

Standard fields represent common information that should be available in every ticket.

Affected areas of functionality:
 * When existing ticket is displayed, then unnecessary custom fields are hidden;
 * When new ticket is created, then custom fields are displayed depending on selected ticket type.