Ticket Types

Warning: this feature is not yet availble in the mainline Trac

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 where 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?

in the Ticket page's title:	​http://projects.edgewall.com/trac/attachment/wiki/TicketTypes/tt_title.2.png?format=raw
in the TracTimeline:	​http://projects.edgewall.com/trac/attachment/wiki/TicketTypes/tt_timeline.2.png?format=raw
Also, it's the first field you can select when creating a new ticket:	​http://projects.edgewall.com/trac/attachment/wiki/TicketTypes/tt_new.2.png?format=raw

What if I don't like ticket types?

No problem. With trac-admin, you can use the ticket_type to perform a few things on ticket types:

• list
• add
• delete
• rename

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 the 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 the severity command in trac-admin.

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.

Feedback on latest patch

By: ChristopherLenz

• "trac-admin help" doesn't include ticket_type
• default ticket types are capitalized, the other enum names aren't → default ticket types should probably also be lower-case
• trac-admin unit tests are failing
• missing space between ticket type and status/resolution in ticket view heading (for example: "Ticket #877 - Defect(closed: fixed)")
• new ticket form: ticket type field should be below reporter and summary
  I don't completely agree here. Ticket Type should come before the summary e.g. the old way Summary: [ER] Add ticket types will be replaced by
  Type: Enhancement Summary: Add ticket types
• milestone statistics should have a "Type" group
  …once on the trunk :)

ChristianBoos: the above status corresponds to [1689]