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!)

[Christian Boos]

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.

[Christopher Lenz]

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.

[Christian Boos]

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

[Christian Boos]

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

[Christian Boos]

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

[Christian Boos]

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.

[Remy Blank]

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.

[Remy Blank]

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.

[Remy Blank]

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?

[Remy Blank]

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.

[Christian Boos]

Too big enhancement for a minor version.

[Remy Blank]

Hey! I'm still interested!

[Christian Boos]

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.

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to Ryan Ollos <ryano@…>:

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.

This has been implemented by ​matobaa in the ​FieldTooltipPlugin.

I'd be interested in implementing the plan in comment:9 for Components, Versions and all of the ticket enums. I've also previously thought it would be valuable to have a Description field for the ticket enums, so I'd also be interested in implementing that feature as well (comment:10).

Would there be interesting in integrating those features into the core if I developed them on a branch, or is the focus entirely on the long-term vision of GenericTrac?

[Christian Boos]

It would be nice as such. For this kind of feature, changing the DB representation would have little impact, so no need to delay.

The current link on the component field of tickets goes to a custom query for that component, it would be nice to somehow keep that possibility with the proposed macro, even indirectly (i.e. the macro could generate that link into an extra column open tickets).

OTOH, having a full blown component "page", looking much like the milestone page, but with side-by-side edit capabilities like a wiki page, keeping track of the history of changes, etc. is of course what GenericTrac is about ;-)

[Ryan J Ollos <ryan.j.ollos@…>]

Okay, cool. I have a few other in-progress patches to finish up first, but I'll add this ticket to the queue, and hope to provide a patch in the coming weeks.

[Ryan J Ollos]

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,

#11649 is a ticket for adding a description field to each ticket system enum.

[Ryan J Ollos]

Replying to rblank:

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

Since this ticket will be a large amount of work I created a separate ticket for adding the macro: #11702.

[Ryan J Ollos]

It's probably more realistic to target this in milestone:1.1.4 or later.

[Ryan J Ollos]

#5211 is a subtask in implementing first-class Components.

[Ryan J Ollos]

Milestone renamed

[Ryan J Ollos]

#4827 requests that addition of COMPONENT_CREATE, COMPONENT_MODIFY, etc …

[Ryan J Ollos]

Narrowing focus for milestone:1.2. Please move ticket to milestone:1.2 if you intend to fix it.

[Ryan J Ollos]

Milestone renamed

[Ryan J Ollos]

Milestone renamed