Provide interface to fill custom select-boxes

[Markus.Staab]

would be nice to have a interface which can provide data for the selectboxes you can find in the properties fieldset of a ticket.

we have the problem that our software has a lot of plugins which are all described in the trac-wiki and the ticket system is used for managing the bugs etc.

The component select-box is very often not uptodate because someone added a new plugin and this plugin wasn't added to the component list yet.. so the problem is, that nobody can report bugs/feature request which are related to the new plugin..

[Christian Boos]

The ideal solution for your situation would be to have components as 1^st class resources. Therefore each time you would create and document a new component, it will become available in the drop-down (see #5211).

One interim solution is to give more people the possibility to update the list of components (TICKET_ADMIN + WebAdmin plugin, as you're using 0.10).

The alternative of providing an input text field to all users is a bit risky, as you'll likely end up with duplicate or invalid components.

[Remy Blank]

Components as first-class resources is not on the radar yet.

[Christian Boos]

Milestone 2.0 deleted

[anonymous]

Replying to rblank:

Components as first-class resources is not on the radar yet.

Please try harder

[Ryan J Ollos]

We have WebAdmin integrated into Trac and TracFineGrainedPermissions can be used to grant TICKET_ADMIN for /admin/ticket/components if you wish to allow a broader audience to edit the available components (since milestone:1.0.2, see #11069).

In addition to #5211, #1233 will focus on making Components first-class objects of the ticket system.

Closing as a duplicate of #11069.