[Patch] Support for subcomponents

[acarter24@…]

I'd like to request the addition of a subcomponent field. This would be useful for breaking large component pieces into smaller subsets. In particular, the project I'm working on includes a core engine and several plug-in style projects. It makes sense to keep it all in the same svn repository as well as the same trac db. However, with the addition of a subcomponet (or feature or something like that), the granularity of tracking for the plug-in projects would be much better.

[ph@…]

Where would it stop? Sub-sub-components? How many new select dropdowns would be added to the ticket page?

This can already be done simply by naming components as core, core-frontend, core-db, etc. Simple, functional, fairly scalable (if your components can't fit in one select dropdown, you're probably breaking down your project too much).

[fg@…]

A single level of subcomponents would go a long way to ease the managability of big projects with Trac.

Having everything in a dropdown with the ad-hoc semantics of prefix-suffix is just encoding structural information in-band in the component name, and makes it hard to use the data later on, for example for specific reports.

Saying "if your components can't fit in one select dropdown, you're probably breaking down your project too much" is really quite short-sighted, just because it works for you doesn't mean it works for everyone.

Please leave this (very legitimate) request for enhancement open.

[uncommon@…]

Wouldn't a custom field be good enough?

[Christian Boos]

Yes, I think we could leave it opened too. I don't see how it should be done, but at least I agree with you that it would ease the managability of big projects with Trac, especially in the context of TracMultipleProjects/SingleEnvironment.

Custom ticket properties are one thing, but if I understood correctly, what is expected is that the list of available subcomponents adapts to the currently selected component.

It's the same problematic expressed elsewhere, when people would like to see the list of versions adapt to the currently selected component, etc.

I'm looking for a generic solution.

[Matthew Good]

Well, short-sightedness is something that we want to avoid. However, that's my main concern with trying to implement sub-components based on the current suggestions. Adding a new dropdown that is somehow filtered based on the selected component seems like it will create more problems than it will solve. As was mentioned before, this could theoretically scale to a tree of arbitrary depth, so implementing a short-term solution of one set of subcomponents doesn't anticipate future expansion.

The other big problem I see here, as well as with any of the other situations in which people want dropdown lists filtered, is making Javascript necessary for Trac to operate correctly. So far Trac has quite nicely avoided this, allowing use of Javascript in ways that enhance the app, but always falling back gracefully when Javascript is not supported. Javascript seems to be the natural way to implement the dropdown filtering, but this would go contrary to Trac's efforts to avoid this pitfall.

Of course, one of my main concerns is always the cost of added complexity compared to the user benefit. Subcomponents may be quite useful for some users, but there are a lot of people using Trac quite effectively without them. We need to be sure to evaluate the impact of the added complexity on all users, not just the ones that happen to want the feature.

[jae+trac@…]

If the "component" selector in the ticket query tool would support "begins with" in addition to "is" and "is not", at least this part would enable some sort of subcomponent support, in that you could find a component and all subcomponents, provided you`d do "comp1.subcomp1" or similar schemes.

[anonymous]

Is there a limit to the number of items that can be added to a drop-list (the Component one in particular)?

[anonymous]

gmail supports filtering contacts when writing emails, and you can have a lot of contacts.

[jkletsky]

At this point in time, it is hard for me to name a browser in common use by product development teams that does not support Javascript (no, Lynx doesn't count), even on platforms such as the more advanced cell phones.

Being able to filter sublists based on the top-level component selected is very valuable and it would be beneficial to have it be revealed for other "primary" fields such as Version and Milestone.

One would have to think through what happens if a ticket is moved from one component to another and the milestone and/or version are not present in the new component. Some care needs to be taken here. For a specific use case:

• Bug is identified in "WWW UI" version "WWW 3.1.1" and is a stop-ship for "WWW 3.2.0"
• Engineering determines that the issue is in "Account Management" which is at version "AM 2.5.3" and there is no corresponding "Account Management"-related milestone

If the ticked is moved to "Account Management" what happens? It still needs to be fixed for "WWW 3.2.0" and still was observed in "WWW 3.1.1" so losing that information seems inappropriate.

If a dependent issue is created (which may be the "proper" way to handle this), then how would one assign "WWW 3.2.0" as the milestone?

[wkornew]

As you already said, a more flexible approach is required because some people even need subsubcomponents…though, it should probably stop there (over-categorization). I'm not suggesting to disallow deeper categorization, though.

But in general I think that it should be possible to add (sub-)components from within the ticket list. It would be too annoying to create a new subcomponent via the admin interface just to file a ticket for it.

When creating a ticket you choose the first component level (e.g.: Drivers), then a new field appears and you can choose its subcomponents (e.g.: Audio) and then in the next field you can choose another level (e.g.: AC97).

I'd also like to see this feature as early as possible (not wait for 2.0).

[wkornew]

If you're interested in integrating it, we have a nice generic solution at ​http://ezri.nextraweb.com/examples/js/haiku/

You will also find a fake demo on that page. It's currently in use on our private Trac install, but it's not yet 100% integrated:

• Roadmap/Milestone details view needs work: currently it shows one entry per component (which may easily be more than 100) instead of just the top-level parents (but including sub-items of all parents, of course)
• queries (View Tickets) should match sub-items, too, instead of exactly the selected component

Maybe someone is interested in integrating it? We want to finish it for our personal Trac branch, anyway. But your help is appreciated. ;)

[Joel]

Would very much appreciate this requirement becoming an "official plug-in"

[Christian Boos]

#3746 was closed as duplicate.

[danny.adair@…]

This sounds more like an interface issue.

If there was a naming convention like having a dot (or maybe a slash like in wiki pages) as a path separator, unobtrusive Javascript could turn a flat "Comp1.Sub1", "Comp1.Sub2", "Comp2.Sub1" into multiple drop-downs - if Javascript is available. If "Comp1" existed by itself, the second drop-down would also include a blank option. This could be done with any number of levels.

When selecting components for a report "is" and "is not" would still be sufficient, just make sure that if "Comp1" is selected (which should be available even if not defined as such, as long as there are sub components of it), everything starting with "Comp1." (or "Comp1/") also matches.

Internally nothing would need to change, I believe.

[asloan12@…]

I would also like to add my 2 bits and request a ticket component hierarchy. One level is all I need, it would be a tremendous help.

The only way I can think of getting around this right now is adding a custom ticket field for subcomponent and name subcomponent items as "component-subcomponent" and rely on the submitter to choose the right thing

Ticket report queries will also need to be modified of course

[Matthew Good]

Please don't change the milestones. If one of the developers decides to implement this sooner he will change the milestone.

[asloan12@…]

Another note, relating to whether to do one level or support multilevel, there is demand for one level, not multilevel.

It may come in the future if IBM-size companies want to use the tool, but the code could be refactored at that time.

I am guessing implementing one level functionality would be 10% of the development effort of multilevel and would satisfy 95% of the users requesting the feature.

For now I will overload the component field, like this guy is: ​http://ezri.nextraweb.com/examples/js/haiku/trac.html

[asloan12@…]

Since this won't be implemented for a while can someone outline a hack to tie us over? For 0.11dev code

Thanks

[robert@…]

Hi all, starting with the next major version of ​TYPO3 we'd like to use Trac (in fact ​we already do). As our project is quite large, we need something like sub components.

In our ​current bugtracker we have organized our "extensions" into "projects" and "categories". In the future we would like to group by "packages" and "subpackages" (instead of "extensions" and issue "categories"), so we need 1) sub components and 2) a possibility to change the label "Component" to "Package". At some point the number of packages will also become an issue as currently about 8000 extensions exist (which we don't manage all by our bug tracker though).

We would love to see a sub component feature in Trac and if we can be of any help in that regard, please let me know. However we're not Python programmers … ;-)

[Christian Boos]

Would the approach suggested in #5979 (i.e. organizing the components in a name hierarchy and be able to filter on them) already help, as a first step?

[endre@…]

I have attached a patch that adds subcomponent support. It is fairly complete, but I haven't written test cases yet. Thought I would wait with that part until I got some feedback on whether this is an acceptable solution or not. I opted for a solution that just adds to the existing codebase, so no rewrites or api changes or anything like that (KISS). Later refactoring should be easy anyway.

Requires an upgrade as I've added a table and modified one other.

[meta@…]

Replying to asloan12@yahoo.ca:

It may come in the future if IBM-size companies want to use the tool, but the code could be

refactored at that time.

I'd like to see the feature. I'm trying to use Trac at a company that's exactly the size of IBM. :-)

The problem is we have 50+ different components, and a single drop-down just isn't a good interface for that number of items.

[slv026@…]

In order to overcome the shortcomings we have experienced integrating Bugzilla with Subversion (a particular networking issue we cannot work around), we are investigating moving to Trac. To date, we have imported the Bugzilla history - BUT - Bugzilla had been organised in a component/sub-component structure and we have lost that relationship. This was pretty disappointing and although our division is not the size of an army brigade (more like a company!), the use of even one sub-division is almost 'essential' to us. Of course being a new user, I have little understanding of the 'back-end' implications of introducing such a change, but would regard it as 'effective use of development time'!!! It's got my support.

[luke-trac@…]

This would be a very useful feature to have. What is holding it up at this point?

[endre@…]

It is not considered useful enough to be included in core. Has to be done using a plugin. Not hard to write the plugin, but I don't have time to do it at the moment.

Should this ticket be closed (won't fix)?

[ilias@…]

Replying to endre@…:

It is not considered useful enough to be included in core.

you may look at the "CC" list of this ticket.

of course this is "consered useful enough", at least from the users (which you should take in account).

Has to be done using a plugin. Not hard to write the plugin, but I don't have time to do it at the moment.

Should this ticket be closed (won't fix)?

[endre@…]

Don't shoot the messegner - I wrote that patch and agree with you, but the main developers don't. See developers mailing list for discussions on this.

The idea is that this is only useful for a relativly small group, and should therefore be implemented as a separate plugin.

[ilias@…]

Replying to endre@…:

Don't shoot the messegner

I 'shoot' the team, as usual

• I wrote that patch and agree with you, but the main developers don't. See developers mailing list for discussions on this.

I know the style of those discussions, thus it's not neccessary to look at them.

The idea is that this is only useful for a relativly small group, and should therefore be implemented as a separate plugin.

That's a core feature for a tracking-system with such large distribution as trac has.

And some things just don't get implemented easily as plug-in's.

anyway, better a plugin than nothing.

[Christian Boos]

Milestone 1.0 deleted

[bret@…]

Wow this would be beautiful to have such a thing…..

If the report builder could do a "one of" components; then I could live without it.

At this point, I'm going to have to do something really disgusting to manage this. Forces on this project are already trying to get rid of trac; this just gives them more ammunition to make the point.

[Christian Boos]

MultipleProjectSupport will somehow limit the usefulness of this feature.

Still a support for a component hierarchy matching the layers or categories appropriate for a given project sounds useful (e.g. here, version control, version control/browser, version control/changeset view, version control/view log).

[tgwena@…]

Is there still any work on this issue?

In the database schema would it not be possible to just add a column "parent" in the table "component". This parent will then refer to another component.

[Mohamed Elkammar]

I wanted to re-iterate what other have been voicing in this thread. I truly think that this feature is important to the way use Trac.

Although, I understand the demand of this is not large, I wanted to share with you that having just one level of sub-components would simplify my life tremendously.

Thank you.

[Peter Suter]

I think it would be helpful to distinguish between the problems and the possible solutions.

Let's first describe what is the problem with the current functionality, including using hierarchical component/subcomponent names (like e.g. Trac's plugin/git and plugin/mercurial). I'm not a big user of components myself, but as far as I can tell from the comments above there are two problems:

1. The component selection dropdown can get very long. Selecting a component from such a long list is painful.
2. The query UI does not easily support queries for all subcomponents.

Anything else?

---

Then we can investigate possible solution alternatives:

1. No changes to Trac are required, just configure a custom field Subcomponents and use plugins for whatever is missing.
   • E.g. use ​th:TracTicketChainedFieldsPlugin to make the options in the subcomponent field dependent on the component field.
   • And maybe use ​th:CustomFieldAdminPlugin?
2. Integrate such missing functionality into Trac core.
   • E.g. add a new field type for chained fields. (Related to, but not quite the same as, #2464 and #8314.)
   • And maybe a custom field admin panel (#11469).
3. Add another first-class built-in ticket field Subcomponent.
   • E.g. add a new DB table and extend the ticket DB tables.
   • This essentially forces Trac to supporting at most two levels of components.
4. Extend the existing first-class ticket field Component to be fully hierarchical.
   • E.g. by adding a parent to the component DB table.
5. Use the plugin/git and plugin/mercurial approach, and implement the missing functionality based on that.
   • (This may first sound like a hack, but it works well enough for the Wiki system!)
   • E.g. use ​Chosen (groups and filters) for easier selection in long dropdowns. (Already proposed for multiselection fields.)
   • Allow prefix searches in the query UI frontend (#5979). The backend seems to already support them.

To me solution alternatives 3 and 4 feel like special cases that only help this one particular use case. But Trac core generally tries to provide customizable solutions that are flexible to be used in a variety of use cases. (E.g. you should be able to create your own custom ticket fields for platform and subplatform or package and subpackage etc.) 3 also seems too limited (only one layer). And 4 seems too complicated by default (forces everyone to use fully general component hierarchies).

2 and / or 5 seem more promising and in the spirit of Trac's philosophy (minimal but flexible).

[anonymous]

​th:SubcomponentsPlugin uses approach 5.