Edgewall Software
Modify

Opened 14 years ago

Last modified 3 years ago

#548 new enhancement

[Patch] Support for subcomponents

Reported by: acarter24@… Owned by:
Priority: low Milestone: next-major-releases
Component: ticket system Version: devel
Severity: normal Keywords: patch ticket component hierarchy
Cc: wkornewald, jae+trac@…, muti@…, trac.tickets@…, develop@…, jkletsky@…, ilias@…, davidf@…, gfoureau@…, leho@…
Release Notes:
API Changes:

Description

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.

Attachments (1)

subcomponent.patch (30.8 KB ) - added by endre@… 11 years ago.

Download all attachments as: .zip

Change History (54)

comment:1 Changed 14 years ago by acarter24@…

Milestone: 1.0

comment:2 Changed 13 years ago by ph@…

Resolution: worksforme
Status: newclosed

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

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by uncommon@…

Wouldn't a custom field be good enough?

comment:5 Changed 13 years ago by Christian Boos

Resolution: worksforme
Status: closedreopened

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.

comment:6 Changed 13 years ago by anonymous

Cc: muti@… added

comment:7 Changed 13 years ago by Matthew Good

Milestone: 1.02.0

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.

comment:8 Changed 13 years ago by anonymous

Cc: trac@… added

comment:9 Changed 13 years ago by anonymous

Cc: trac_ticket.548@… added

comment:10 Changed 13 years ago by anonymous

Cc: trac_tickets@… added; trac_ticket.548@… removed

comment:11 Changed 13 years ago by Gunnar Wagenknecht <gunnar@…>

Cc: gunnar@… added

comment:12 Changed 13 years ago by anonymous

Cc: trac.tickets@… added; trac_tickets@… removed

comment:13 Changed 13 years ago by jae+trac@…

Cc: jae+trac@… added

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.

comment:14 Changed 13 years ago by anonymous

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

comment:15 Changed 12 years ago by anonymous

Cc: develop@… added

comment:16 Changed 12 years ago by anonymous

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

comment:17 Changed 12 years ago by Bruce Christensen <trac@…>

Cc: trac@… removed

comment:18 Changed 12 years ago by jkletsky

Cc: jkletsky@… added

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?

comment:19 Changed 12 years ago by 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).

comment:20 Changed 12 years ago by 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. ;)

comment:21 Changed 12 years ago by wkornew

Cc: wkornew added

comment:22 Changed 12 years ago by anonymous

Cc: gunnar@… removed

comment:23 Changed 12 years ago by wkornewald <wkornewald>

Cc: wkornewald added; wkornew removed

comment:24 Changed 11 years ago by Joel

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

comment:25 Changed 11 years ago by ilias@…

Cc: ilias@… added

comment:26 Changed 11 years ago by Christian Boos

Keywords: hierarchy added; subcomponent removed
Milestone: 2.01.0

#3746 was closed as duplicate.

comment:27 Changed 11 years ago by 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.

comment:28 Changed 11 years ago by asloan12@…

Milestone: 1.00.11.1
Priority: normalhigh
Version: 0.7.1devel

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

comment:29 Changed 11 years ago by Matthew Good

Milestone: 0.11.11.0
Priority: highnormal

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

comment:30 in reply to:  28 ; Changed 11 years ago by 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

comment:31 Changed 11 years ago by asloan12@…

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

Thanks

comment:32 Changed 11 years ago by 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 … ;-)

comment:33 Changed 11 years ago by 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?

Changed 11 years ago by endre@…

Attachment: subcomponent.patch added

comment:34 Changed 11 years ago by endre@…

Summary: Support for subcomponents[Patch] Support for subcomponents

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.

comment:35 Changed 10 years ago by davidf@…

Cc: davidf@… added

comment:36 in reply to:  30 Changed 10 years ago by 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.

comment:37 Changed 10 years ago by 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.

comment:38 Changed 10 years ago by luke-trac@…

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

comment:39 Changed 10 years ago by 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)?

comment:40 in reply to:  39 Changed 10 years ago by 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)?

comment:41 Changed 10 years ago by 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.

comment:42 in reply to:  41 Changed 10 years ago by 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.

comment:43 Changed 9 years ago by Gaylord Foureau <gfoureau@…>

Cc: gfoureau@… added

comment:44 Changed 8 years ago by lkraav <leho@…>

Cc: leho@… added

comment:45 Changed 8 years ago by Christian Boos

Milestone: 1.0unscheduled

Milestone 1.0 deleted

comment:46 Changed 8 years ago by 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.

comment:47 Changed 8 years ago by Christian Boos

Milestone: triagingnext-major-0.1X
Priority: normallow

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

comment:48 Changed 5 years ago by 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.

comment:49 Changed 4 years ago by 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.

comment:50 Changed 4 years ago by 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.
  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).

Last edited 4 years ago by Peter Suter (previous) (diff)

comment:51 Changed 4 years ago by anonymous

th:SubcomponentsPlugin uses approach 5.

comment:52 Changed 3 years ago by Ryan J Ollos

Owner: Jonas Borgström deleted
Status: reopenednew

comment:53 Changed 3 years ago by figaro

Keywords: patch added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set.
The owner will be changed from (none) to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.