Ticket Dependency Variant

[chandlerc@…]

This is a ticket to provide a simpler, stripped down solution to the often requested ticket dependencies, that does not involve anything as complex as TracCrossReferences, but still provides the very useful functionality of being able to break apart tickets, and use dependency to determine the order they should be worked on.

[chandlerc@…]

Having spoken with several people on IRC concerning a simple way to do this, here is the current proposal:

• Tickets can depend on several other tickets being closed before they can be closed.
• Tickets can be added directly to dependencies. This is however not the recommended method.
• Tickets can be created via a UI element of an existing ticket that are "children", or depended upon by the existing ticket.
  • These new tickets' descriptions can be (by a UI element in their creation page) automatically added as a comment to the existing ticket.
• Reports should allow to sort tickets in a dependancy correct manner, if such an ordering is possible.

Outstanding issues are:

• Where are the dependancies stored?

My proposal as to how to store dependancies is as follows:

• There are two obvious options:
  • Each ticket stores a set of tickets upon which it depends.
  • Each ticket stores a set of tickets which depend upon it.
• These both suffer from the difficulty of displaying the other.
  • In other words, each ticket will need to display both the tickets it depends upon, and those that depend upon it. While one of these is directly available, the other one becomes nearly impossible to determine.
• Therefore, create a table specifically to store ticket dependancies.
  • A row would then be "<Dependie> <Dependant>" where both are ticket IDs.

Comments? Suggestions?

I will be attempting to implement this, so please give feedback.

[dragisha@…]

Model of UI for creation assumes it's "single parent" so it's, for first take, good idea to have only parent field in ticket for child tickets. It's easy to query from trac's db. When ticket is toplevel, it's parent is 0, or it's own id.

In case we allow dep tree to be altered (and I don't see point there, as milestones are already that one "toplevel" sort device) then table is good idea as deps there can run really wild. But I am not sure if we need more than "single parent" and milestones for ticket sorting/grouping.

This "parent ticket" establishes formal dependency, and TrackLinks? in tickets and comments allow for informal dependencies. IMHO, that's exact measure for first take on this.

[asmodai@…]

In how much is this a duplicate of #886?

[cboos]

​TracHacks:MasterTicketsPlugin can be considered as fulfilling this ticket.

For the implementation of ticket dependencies within Trac core, refer to #886.