filter component list per milestone when raising a new ticket

[lord_dr_thaimeup@…]

Each milestone should be able to have specific components associated to it.

Then when you create a ticket and select milestone A only the components for milestone A should be displayed. This would be a cool feature.

[Matthew Good <trac matt-good net>]

The requested implementation seems a bit too complex. A simpler approach would be to simply maintain a list of "active" components. Old components that were removed from the system could be "archived" so that they would not show up for creating new tickets, but would still be available in the database for informational purposes on past tickets.

[Matthew Good <trac matt-good net>]

Proposed implementation

[Matthew Good <trac matt-good net>]

Attached a patch for my proposed solution.

[cboos@…]

This problematic is exactly fitting the one I'm beginning to address in the xref-branch: it's about how to create a semi-structured wiki.

Trac, besides its plain wiki roots, has already introduced some kind of rigid structure with the tickets and its ticket fields. Even if there's a web admin module for managing versions, components, severity and such (like Brad's one: ​http://trac.dsource.org/projects/test/admin/ticket) this would still be rigid:

• one list of milestones
• one list of components
• one list of versions …

Now consider having relationships: by attaching explicit semantic to links between Trac objects, one could use that to have a very structured, yet still flexible, way of constraining the content of the ticket fields:

Example: The description of milestone:Milestone2005-1 would contain:

...
This milestone is only about those components:
  * <<has-component>> EngineComponent
  * <<has-component>> WebInterfaceComponent
  * <<has-component>> wiki:kernel2.2
  * The GUIComponent is not taken into account for this milestone,
    it's too early :)

Given that information, it's possible to restrict the available components to those 3, once the Milestone2005-1 is selected.

Following the same pattern, the wiki page content for the EngineComponent page could contain:

...
The several versions that where released to the public for the engine are:
 * <<has-version>> wiki:engine-0.1
 * <<has-version>> wiki:engine-0.3
 * TODO: after the milestone:Milestone2005-1, don't forget
   to add a has-version for wiki:engine-1.0

That way, this EngineComponent page cross-reference wiki:engine-0.1, wiki:engine-0.3 and wiki:engine-1.0 (i.e. the EngineComponent appear among the backlinks for those pages), but only the first 2 have an explicit has-version attached to them, enabling to Ticket code to only pick those two when listing the available versions for a given component.

One can also imagine that:

• a TicketDefaultComponents page could be related to all the components that can be chosen from, if there's no explicit list given in the milestone,
• a TicketDefaultVersions page could be related to all the possible versions if there's no explicit list for a given component
• the same for TicketDefaultSeverity, TicketDefaultPriority, …
• this mechanism could be also extended for custom fields

[Christopher Lenz]

I don't really see the original problem. If a ticket is associated with the incorrect component at creation time (because that component doesn't exist for a version/milestone or whatever), you simply change it after creation of the ticket.

Ticket submission should be as simple as possible (which is — or at least should be — a primary goal of every bug tracking system). We don't want to add validation like "that component doesn't exist in the selected version!" (or similar). Assisting ticket submission with client-side filtering that changes the list of available components depending on the selected version or milestone might be an option, but I personally don't see enough benefit to justify the cost.

One problem is that different people use components, versions and milestones in very different ways. While you might want to associate components with milestones, many others (myself included) wouldn't think that that would make any sense.

Matt's proposal of adding an "archived" flag to components to hide obsolete components is okay, but I'm not sure whether it addresses the original request. And what if a user wants to file a ticket about an old version that she still is using for whatever reason, and the component does exist in that version? You'll create policies like "only archive a component when support for last the version that contained that component is phased out". And if you provide a couple years worth of support, the old milestones will still be in the list and potentially confuse users of the newer versions.

[Matthew Good <trac matt-good net>]

Yeah, Chris I agree that the filtering or validation of components associated to versions is probably more complicated than necessary, both in terms of the implementation as well as the required configuration.

Maybe there is something I'm missing about the ways people might expect components to be tied to milestones. I was assuming that the main issue here was to allow for the fact that people may add and remove components through the life of a project. You don't really want to delete components from the database since this would mess up old tickets associated with them. However, you may wish to have components that aren't in use anymore not show up.

I guess I was thinking about this along the lines of #1078 for removing completed milestones from the list. I do understand the problem with supporting old versions that may use the components though. (Why can't everyone stay on the bleeding edge? ;)

Altough, most of the projects I work on are services contracts where there are really only ever two versions in use: production and development. So, if a component is removed from production, there's no reason another ticket would come up for that component.

However, as is often the case, removing components isn't a common thing, so the projects don't tend to have much in the way of deprecated components left behind.

Of course, I suppose if we do have a way to phase out components, it should also be possible to phase out versions.

(Also, I noticed that my patch doesn't take into account the possibility to try to re-add an archived component, which should really just reactivate it)

[Christopher Lenz]

Not for 0.9

[Emmanuel Blot]

(Cleaning up milestone after spam)

[Christian Boos]

I think the original intent could be achieved using conditional filtering for the component field, based on the current value of the milestone field. See #2464.