Descriptions of Components

[Matthew Harrison]

One annoying problem we have with our existing bug-tracking system is that users often
don't know what component to select for a ticket. They often end up choosing an inappropriate one.

One could argue that better component names would minimise this, but I've often found users to be
endlessly creative in their quest to misunderstand the (seemingly) obvious ;-)
A nice feature of bugzilla is that the component selector label is a link to a page listing the components for the project, along with owner and description. (If you prefer the link could be a separate item, like a '?' icon.)

(Currently I'm conducting a trial of trac, and I quite like it!)

[cboos]

A component could be a specific Trac object.
Clicking on a component would go to its page,
which would contain a wiki description.

See other suggested use for a Component object in
TracMultipleProjects/SingleEnvironment#UsingComponentobjects.

[cmlenz]

Components now have a "description" column in the table. It's not being used yet, but it will be in the future for this purpose.

[cboos]

(changing the status, as I've not actually started to work on that yet)

[cboos]

Can be done in GenericTrac, as a second step, in order to validate the steps needed to create of a new kind of resource.

[cboos]

#5860 closed as duplicate (was asking to actually make use of the component description that one can already set in the component admin panel).

[cboos]

Replying to cmlenz:

Components now have a "description" column in the table. It's not being used yet, but it will be in the future for this purpose.

Re-focusing this ticket for this goal. For the idea of having components as first-class object in the Trac system, see #3911.
#7411 closed as duplicate of this ticket.

[rblank]

This feature sounds useful. How about the following plan:

• Add a [[TicketComponents]] macro that expands to the list of components, with their descriptions and owners (similar to [[TracIni]] as a table, for example).

• Create a default page TicketComponents that includes the macro and some explanations.

• Link to the TicketComponents page from the "Component" label in the ticket properties, as suggested by the reporter.

[rblank]

The same functionality was requested on trac-users, but for the version field. In principle, nothing would stop us from adding a description to all enumerated field types, and to have a TicketEnumFields page with one table for each field containing the values and descriptions.

I'll start with the fields that have a description.

[jhammel@…]

Replying to rblank:

The same functionality was requested on trac-users, but for the version field. In principle, nothing would stop us from adding a description to all enumerated field types, and to have a TicketEnumFields page with one table for each field containing the values and descriptions.

I'll start with the fields that have a description.

In general, it would be nice to have wiki macros for the descriptions of fields with descriptions. They could then be used in the ticket form and where ever else the information is desired.

[rblank]

Replying to jhammel@…:

In general, it would be nice to have wiki macros for the descriptions of fields with descriptions. They could then be used in the ticket form and where ever else the information is desired.

Do you mean a macro that takes a field name and value, and expands to the description of the field value? How would you use that in the ticket form?

[rblank]

Doesn't block 0.12, re-targeting.

[Emil Bleaker <emil_bleaker@…>]

This sounds more like an enhancement than a defect.

[Ryan Ollos <ryano@…>]

Replying to Matthew Harrison:

A nice feature of bugzilla is that the component selector label is a link to a page listing the components for the project, along with owner and description. (If you prefer the link could be a separate item, like a '?' icon.)

Replying to rblank:

This feature sounds useful. How about the following plan:

• Add a [[TicketComponents]] macro that expands to the list of components, with their descriptions and owners (similar to [[TracIni]] as a table, for example).

• Create a default page TicketComponents that includes the macro and some explanations.

• Link to the TicketComponents page from the "Component" label in the ticket properties, as suggested by the reporter.

This could mostly be hacked together with the current system, which is sort of what I have done.

I've used the ​th:WikiTableMacro to show a list of components on a page, along with their descriptions.

{{{
#!SQLTable
SELECT name, description FROM component ORDER BY name
}}}

However, I agree that the macro would be a nice feature.

I've changed the ticket template to transform the Component: text into a link to a wiki page.

Another nice feature would be to have a tooltip showing the description when there is a mouseover on a particular component in the drop down list.

Replying to rblank:

The same functionality was requested on trac-users, but for the version field. In principle, nothing would stop us from adding a description to all enumerated field types, and to have a TicketEnumFields page with one table for each field containing the values and descriptions.

If this could be extended to custom fields as well, that would be ideal. I have a wiki page that explains all of the fields of the tickets, including a number of custom fields. I use the SQL query as shown above for items such as Component, but I have had to manually create and update the wiki page for custom fields.

[cboos]

Too big enhancement for a minor version.

[rblank]

Hey! I'm still interested!

[cboos]

Well, yes, but me too ;-)

I reset the owner as we're having two different approaches here (comment: 6 vs comment:9), and no immediate progress in either direction.

[lkraav <leho@…>]

btw, ​th:ComponentsProcessorMacro exists. looking at the this ticket's description, i think it could serve as a hold-me-over in many cases.