Add ability to define ticket types

[tomek@…]

The ability to distinguish between bug tickets and feature tickets is something that in my mind is a core requirement of any software development management system.

I have to juggle between mutliple projects and each has many customers who either provide general feedback, report bugs or ask for new features. My customers are also interested in being able to track the list of features already requested and to see their state. Trac's ticket system almost allows for this except there is no nice way to distinguish between the various types of tickets.

Please add a "Ticket Type" property to ticket properties. This should be configurable and searchable just like the other properties are.

[tomek@…]

I've just realised that this can be accomplished using custom ticket properties which can be defined in trac.ini. Still, I think that this is important enought that it should be included as a default property. This property should also be at the top of the property list as this is likely to be the first thing which users will select.

[Matthew Good <trac matt-good net>]

Feature requests should be indicated by using the severity value "enhancement", bug tickets will be given some other severity to indicate the level of the problem.

If you have other needs for ticket fields that are not included by default see TracTicketsCustomFields for defining your own fields. The custom fields, like the standard fields, can be used in reports or searched on using the "Custom Query" link available on the "View Tickets" page.

[mgood]

Oops, I guess you discovered TracTicketsCustomFields while I was writing that, but it's not necessary for distinguishing feature requests from bugs. As I noted before, that's what the severity level of "enhancement" is for, so it is there by default.

[cboos]

Well, I tend to agree almost entirely with the ticket reporter.

Indeed, that's what I implemented a few month ago in #919
and use in my customized Trac.

It's true that currently one can use the severity field
to distinguish a feature request from a bug report, but, as
the reporter said, it should be made more prominent, even the
first thing to select when creating a ticket.
Not to mention the fact that when planning future releases,
it also makes sense to associate a severity to an enhancement
request (e.g. this ER is a blocker for that milestone,
don't ship without that ER, or its a minor enhancement, etc.)

[cboos]

I'll create shortly the source:cboos-dev/category-branch
to revive the #919 patch.