Add support for Master tickets

[dmurphy25@…]

It would be cool if you could create master tickets that other tickets refer to. Work could then be broken down into chunks (and assigned to different people), but the master ticket could only be closed when all referring tickets had been resolved.

You could also have it so that referring tickets are excluded from the Roadmap ticket counts.

[zilvinas@…]

That sounds like project. Each task is composed to of tickets, the only way to complete 'task' is close all tickets. Sounds like a good idea.

[cboos@…]

That even sounds like milestone to me...

What about a little rework of the Roadmap module and the ticket and milestone objects.

Let me explain the idea.

Instead of having distinct ticket and milestone objects as we have now, we should only have tickets, but different categories of tickets:

• ER Enhancement Request (simple)
• PR Problem Report (simple)
• Milestone ... like the milestones we already have (aggregate)
• MasterTicket ... like suggested initially (aggregate)
• Deployments see #821 (simple)
• Task anything else (simple)
• ... etc. (the list can be customized

They would have a different icon for the timeline view.

The Roadmap module could show the (aggregate) categories: Milestones, Master Tickets, ...

A (simple) ticket can be attached to an (aggregate) ticket:

• to a milestone, as it is done now (display in the combobox only available milestone tickets)
• to a master ticket (display in that combobox only available master tickets)

It remains to be seen if an (aggregate) ticket could itself be attached to another (aggregate) ticket... A master ticket attached to a milestone makes sense.

The great unification... :) (and we need to parse smileys too!)

[dmurphy25@…]

You're quite right - reworking the modules and breaking down the tickets into different types seems a good solution, and more flexible than simply 'bolting on' master tickets.

Master tickets should be children of Milestone tickets, but not other Master tickets.

[Tristan Seligmann <mithrandi@…>]

This sounds like a dup of #31 to me.

[cboos]

This is a kind of duplicate for #31. However, there was an additional suggestion in the comments there about being able to create child tickets, which fits nicely with the original description of this ticket:

Work could then be broken down into chunks (and assigned to different people), but the master ticket could only be closed when all referring tickets had been resolved.

By adding a Create sub-ticket, or Create child ticket link, any ticket could be easily broken down into subtasks. That link would create a new ticket and a depends-on relationship between the parent ticket and the newly created child ticket. That way, one could only close the parent ticket when all its children are resolved, thanks to the solution for #31.

[cmlenz]

Deferred.

[dmbrucker@…]

I'm really interested in this feature, it will really add some useful workflow capabilities. I think it would be better, though, to make it more generic: don't have a special type of ticket for a Master Ticket. A ticket is a ticket is a ticket, each capable of N-levels of dependence and reference. It should be the context of the reference that gives a ticket its meaning in relation to the other tickets.

I see three types of relationships:

1) Depends on/Depended on by: This would be a true blocking relationship; the ticket could not be resolved until each ticket it depends on is resolved. It does not necessarily mean that any ticket is the parent or child of the other, just that there is a required order to their completion. One ticket may be depended on by multiple other tickets, i.e. Tickets A and B both depend on C. A ticket can be in any milestone greater then or equal to the highest milestone of its dependencies.

2) Parent of/Child of: This is the task+subtask context described here and #31. The parent encapsulates a portion of work that is accomplished through its collection of children. A child can only have one parent. This type is definitely different then a milestone. The Milestone page could either include or elide the child tickets, with the opposite view being available with another checkbox below "Show already completed milestones". Moving a ticket to another milestone would include the option of also moving some or all its children. Individual child tickets could be left in milestones lesser then their parents, especially if they are depended on by a ticket in the lesser milestone.

3) Duplicate of: All of the tickets describe a similar bug/feature/request/problem. If A is a duplicate of B, and B is a duplicate of C, then A is a duplicate of C. Taken as a group of tickets, they all talk about pretty much the same thing. Since trac uses a linear display of comments, instead of threaded, it might be better to keep the tickets unmerged for readability and context. Rather then merging the tickets, an interesting way of handling this might be to create a new ticket of type 2 above, that is the parent of all the duplicate tickets, just so it would be easy to find all the dups and see what had been discussed in each.

Each of these relationships is independent of the rest. One ticket can depend on another ticket of which it is not the parent. A parent can explicitly depend on one of its children, requiring the child to be resolved first. One ticket can be the parent of 9 other tickets, 3 of which are duplicates. Etc. There may be more relationships that would be useful to implement in the future.

This is a lot of description, and is basically just a brain dump. My main point is that tickets should be generic when it comes to relationships. I think it will help to keep them more usable and extensible later.

[cboos]

Very interesting. Thanks for sharing your thoughts! Let me add a few comments.

don't have a special type of ticket for a Master Ticket

Yes. I agree with this too, now.

1) and 2)

Very interesting. So far, I didn't make a difference between the <<depends-on>> relation and the <<parent-of>> relation. But I see the point, now.

2) ... This type is definitely different then a milestone.

You may be right, but I'm not yet sure about that. Think about the Milestone view: it would also make sense for a Master Ticket (i.e. any ticket with children) to be displayed like that. How many of its children (optionally including sub-children) are completed and how many are left to be done, the children ticket status by component/type/priority, etc.

3)

Yes, but no need to create one more ticket: it would be enough to display, besides the duplicate status, the list of all the duplicated tickets (the transitive closure of the <<duplicate-of>> relation).

Each of these relationships is independent of the rest.

Yes. What I said above about the relationship between the <<child-of>> and <<depends-on>> relations can be implemented without too much complexity at the point where the check is made to see if a ticket can be closed. The check would be: there are no depended upon tickets opened and no child tickets opened.

My main point is that tickets should be generic when it comes to relationships.

You're again quite right. It's the way I intend to implement it. Support for that is already (partially) there in the TracCrossReferences branch, and more is to come soon.

[dmbrucker@…]

...it would also make sense for a Master Ticket ... to be displayed like that...

I totally agree. A "milestone ticket", one designated as the parent of all tickets assigned to the milestone would be, I think, an excellent design. I was responding more to what had been discussed, that this feature could be a rework of milestones as they currenly are, which I don't think is appropriate. But, if a ticket-type object with a couple extra fields/features could be used for milestones as well, that would be very good.

...no need to create one more ticket...

Even better! If this can be done _without_ creating an extra, ugly growth type ticket, that's all the better.

[mrovner@…]

see also #2075

[asmodai@…]

Potential duplicate ticket: #2087?

[cmlenz]

#2193 has been marked as duplicate of this ticket.

[trac@…]

I like the idea of the milestone being replaced by a ticket that is the parent of other tickets.

I am not sure that the <<depends-on>> and <<duplicate-of>> relation is as important. I find navigation links fine for linking wikis to tickets, tickets to other tickets. If a ticket truly depends on another one, then it cannot be completed before the other is completed, so who would do so? Simple links to the other tickets will give enough information for this.

<<child-of>, however, really is useful to have explicit because then milestones can be replaced, tickets can be half-done, and you can form a hierarchy of increasing levels of task abstraction, which is very useful for project management. Clearly, a parent ticket cannot be closed before all its children (subtasks) are complete.

This also ties in nicely with the idea of "Actionable" tickets (see #31).

I think that once the scope is narrowed to only the special <<child-of>> relation, TracCrossReferences becomes overkill to achieve this.

I disagree that relationships should be handled in a generic way, because they are not generic (some have explicit logic behind them, which is why we need them in the first place instead of just using navigation links) and there are only a few (IMHO one, others think three) that will ever be useful to the majority of users.

[cboos]

I think that once the scope is narrowed to only the special <<child-of>>

relation, TracCrossReferences becomes overkill to achieve this.

That's the opinion stated in #2087. Well, we'll see what that alternative approach will provide.

I'm currently busy with the low-level sqlite issues, but as soon as this is done, I'll try to get some progress on this topic, using the TracCrossReferences approach.

I fail to see why having a generic support for relationships between objects prevents one to associates some logic to those dependencies... Consider it's simply a programming convenience, which enables one to write code like for child in ticket.relation('parent-of'): ...

[trac@…]

I have added a specifications proposal for SubTickets on the wiki. It summarises a lot of what was discussed in this ticket and #31 (and a lot of my own opinions). Once I get some feedback I will begin implementing the changes.

[dpeterson <dpeterson@…>]

I personally like what you've proposed except that I think the logical starting implementation should not include any attempt at swapping in parent tickets for milestones.

While I can't think of anything right now that forces milestones to be of a unique object type, the fact of the matter is that they are unique right now in Trac. (as seen by the fact that milestones have a due date and a separate db table.)

Thinking of potential differences as I type:

• I think of a milestone as having only statuses of not started, in-progress, or complete. How would we rule out the other resolve type actions on a milestone if it was a ticket?
• I don't usually think of a milestone as having a 'type' such as enhancement, task, or defect. Would we try to prevent this from being set on a milestone-replacement-ticket?
• Do milestones have relative priorities? I don't think they do. The project manager or owner simply schedules them out within the calendar. If you don't use that kind of process on a project, then perhaps priorities is needed?
• Do milestones have severities? I've never thought of them that way and I'm not sure what that would buy me. If we don't want that, how would we prevent people from picking a priority on a parent ticket and not seeing any change in organization within the roadmap view or reports?

At this point, I think I've convinced myself that milestones actually are a unique type of object.

[cboos]

The short term prototype will not make the Milestone object disappear. I'd simply like to push the common functionality of (parent) Tickets and Milestones to a common parent class (be it the TracObject class itself or some new intermediate common ancestor, e.g. TicketGroup)

The long term idea, expressed in TracObjectModelProposal (need to refresh that page, btw.) would be to have most of the functionality available at the TracObject level, and subclasses would only alter or build upon the generic behavior (e.g. that way one could have fields and custom fields for any objects, and also the comments and changes history).

[trac@…]

I agree that milestones are different. I see that now, but I am not sure we should dismiss the replacement entirely; I think the milestone concept is somewhat incomplete and some more thought should be put into exactly what they are.

A good point was raised about statuses, priorities and severities for milestones. They don't make sense. But currently milestones are just groups of tickets with a date. No ordering is enforced (though it is implied via the date the milestone was created). But the problems mentioned with respect to milestones apply equally well to parent tickets. Do subtickets have the same type as their parent? How do the priorities of subtickets relate to the parent? They can't have relative priorities because they all must be completed to complete the parent ticket. How can their severities be different?

Perhaps we should not be trying to generalise subtickets at all.

[trac@…]

I like Christian's proposal to abstract common functionality into a TicketGroup class in his x-ref branch. I would recommend against the TicketGroup being descended from TracObject because this would result in the worst kind of multiple inheritance, a common ancestor inherited twice. Instead, I would propose the TicketGroup just be an abstraction of group functionality only, and not actually a TracObject.

   TracObject  TicketGroup
     /    \     /   |
Ticket   Milestone  |
   \                |
  ParentTicket ------

The only potential problem either of the designs is that subtickets are not aware they are subtickets, meaning it might be more difficult to say, show only parent tickets in a search.

[dpeterson <dpeterson@…>]

I would say that it is not necessary for subtickets to know they are subtickets to differentiate between them and parents -- it's enough if just the parents know they are parents. i.e. rather than saying 'hide all subtickets' you would say 'show only parent tickets'.

Maybe not ideal, but it should work.

[anonymous]

I am new to using track (2 weeks) but this is one of the main blocking issues for me to use it well - no sub-tasks.

I very much want to be able to have a ticket representing a major task. Then I want to break the work of the major task down into smaller sub-tasks to generate a work-task breakdown with estimates. I need to have the sub-tasks be ordered (to represent the order in which I need to do them) and I need the parent task to take it's time values from the sum of the child tickets. One level of child task would be sufficient in 80% of cases, but two or three would be even better for managing large projects.

Then in the view of a milestone or tickets, you could set the "depth" of the view and it would just show the main first level, say, or you could see down to the first child level (depth = 2).

Anyway, I just wanted to let you know how much I would like this feature and how much easier it would be for me to "sell" the company I'm working at on using Trac if it had this.

[anonymous]

oh - another thing I've thought would go with this - an "outline" view of a milestone. So you have the depth concept mentioned previously but also could have "reveal" type triangles like in an outline and could collapse tickets that had sub-tickets to see different parts of the tree of tickets.

time to learn Python so I can help!

[cmlenz]

#2659 has been marked as duplicate of this ticket.

[anonymous]

I wouldn't drop the Milestone-concept or touch it in any way - hierachical tickets still can be part of a milestone. I like the idea of both beeing different things.

[anonymous]

Yes, I'd say that milestone (and unimplemented release notice) are different (marketing) view of a project and as such are very important. However they are almost independent of developer/qa view for which master/hierarhical tickets are needed.

[anonymous]

Any update on when (date, not just "milestone 1.0") this will become available?

[Ilias Lazaridis <ilias@…>]

This feature is very important for Trac.

Below is a simple implementation Sequence.

Goal:

a) enable simple migration from competitive tracking system
databases(e.g.bugzilla)

The resulting fields would be initially:

a) Depends On
b) Blocks

Possible Implementation Sequence:

a) provide the "Depends On" field
b) provide the "Blocks" field (read only)
c) provide automatism to update entries (Depends On => Blocks)
d) provide visualization of dependency tree
e) make "Blocks" field writable
c) provide automatism to update entries ( Blocks => Depends On) 

[eblot]

As a side note, I really hope this feature will come with an option to disable it as a whole, so that Trac can stay simple, as least from the user (and admin) perspective. I know that a lot of people have been waiting for this feature for a very long time, but I think it will bring a lot of issues on its own. Therefore, a single option to enable or disable the whole ticket dependency / master ticket feature would be very nice.

[anonymous]

Just my two cents:

From a project manager's perspective, the current timeline feature is rather useless. But even developers want to see the progress of their work from time to time.

Today, if you ask Trac to display all (ticket) changes for the last 3 months (because you want to compile a quarterly report), you are flooded by a long list of minor things. The timeline feature lacks to provide you with a compact representation such that you get a feeling about what you have achieved.

Hierarchical tickets and/or milestones may help to solve this issue. (BTW: Is there a document that describes the use/semantics of tickets and milestones? Can a milestone be considered as a ticket of type "milestone"? I think/hope that Trac will evolve to a light-weight project management tool (the sooner the better). This would be excellent as long as Trac is based on a small set of simple concepts).

Michael Gerz

[athomas]

To reflect reality, reassigning and targetting for 0.11.

[athomas]

Just to clarify that last comment...WorkFlow will allow for master tickets.

[anonymous]

Adding us all back to the CC list.

[s.e.latham@…]

Just wanted to say that we at BADC http://badc.nerc.ac.uk and NDG http://ndg.nerc.ac.uk really need sub-tasks and dependencies. Then we really can use it in earnest as a light-weight project management tool. (We are using not-very-good workarounds at the moment.) So very interested in the outcome of this.

[drew]

I was led to this ticket from #2071. From an XP perspective, I think sub-tasks get you half way there. You could enter a story as a master task and sub tasks could be the engineering tasks resulting from the story.

Iterations however, are better described as child-milestones than as child-tasks. Priority and severity don't matter to them. An iteration is a specific time period in which to complete a set unit of work. The parent-milestone would then be a release or backlog. You'd also need the ability to move an iteration(child-milestone) from one release(parent-milestone) to another.

[Stefan]

Yes, subtickets would be very usefull for our company in the way we execute scrum.

http://en.wikipedia.org/wiki/Scrum_%28development%29

It would very, very neat and useful to have subtickets.

[alex@…]

We would really like to be able to use subtickets. I was surprised that Trac didn't already have that.

As for master-tickets vs. milestones: parent-tickets could be used as milestones, as long as it was as simple to change a ticket's parent as it is to change the milestone. The semantics are different - milestones are like a target, allowing that things can move in and out of them as plans change; parent tickets, on the other hand, really are entirely composed of their children. When you decompose a task into subtasks, it generally doesn't make sense to move one of those subtasks to a different parent. But if the mechanics are similar enough, maybe that doesn't matter.

[Noah Kantrowitz <coderanger@…>]

Can some people please try this? Just install it like any other plugin, and add a custom text field called "blocking".

[anonymous]

Replying to Noah Kantrowitz <coderanger@yahoo.com>:

Can some people please try this? Just install it like any other plugin, and add a custom text field called "blocking".

Noah that is pretty nice. However it looks like I can only say "This ticket blocks this ticket(s)" It would be nice if I could also say "This ticket depends on this ticket"

[anonymous]

What happens, when I add a ticket number in this field. Is this then blocked from closing, or anything else? What is the correct format, just a number like '886' or like a reference '#886'?

[Bill Pennington <bill@…>]

Replying to anonymous:

What happens, when I add a ticket number in this field. Is this then blocked from closing, or anything else? What is the correct format, just a number like '886' or like a reference '#886'?

After installing the plugin and adding the Blocking text field you can do the following:

1. In the blocking field of a ticket put the number of the ticket it blocks. Multiple ticket #s can be separated by commas

2. For every ticket you entered in #1 above a new field will show up that says "blocked by" then list the tickets that are blocking this ticket and the status. For example "Blocked By: Blockers open #1588"

That is what I have been able to figure out so far.

[Noah Kantrowitz <coderanger@…>]

Replying to Bill Pennington <bill@whitehatsec.com>:

That is what I have been able to figure out so far.

Yep, thats all it does so far.

[anonymous]

I want to listen in on this..

[dpeterson@…]

Hi Noah / Coderanger,

Just ran into a bug in the Master Ticket plugin you provided -- see ticket:4891. Except for that it seems to be working pretty good!

[cboos]

Sorry, not going to happen for 0.11.

[athomas]

WorkFlow will be in 0.11 and this functionality can be implemented with that system. In that respect, this will be possible in 0.11, but not integrated into core.

[cboos]

Well, there can certainly be a workaround using the WorkFlow features, but in my view, this ticket corresponds to the SubTickets specification.

[athomas]

Not sure how it's a "workaround" if WorkFlow allows plugins to implement the behaviour in SubTickets/this ticket.

[nkantrowitz]

I suppose I should go ahead and officially grab this ticket. MasterTickets 2.0 is in the pipeline, and should hopefully fix the issues people found with the last system.

[martin.marcher@…]

Replying to dmurphy25@csc.com:

You're quite right - reworking the modules and breaking down the tickets into different types seems a good solution, and more flexible than simply 'bolting on' master tickets. Master tickets should be children of Milestone tickets, but not other Master tickets.

Hmm why not?

If that is refactored to reflect possible hierarchies why should it be artificially limited to only one level?

Also why not have Multi-Parented tickets - ticket 5 is a child of ticket 12 and ticket 15, or the other way around: ticket 12 and ticket 15 can only be closed when ticket 5 is closed.

Also if Workflow in wiki:0.11 provides a workaround could someone with insight provide a quick exampel?

thanks

[nkantrowitz]

Replying to martin.marcher@openforce.com:

Replying to dmurphy25@csc.com:

You're quite right - reworking the modules and breaking down the tickets into different types seems a good solution, and more flexible than simply 'bolting on' master tickets. Master tickets should be children of Milestone tickets, but not other Master tickets.

Hmm why not? If that is refactored to reflect possible hierarchies why should it be artificially limited to only one level?

Done in MasterTickets already.

Also why not have Multi-Parented tickets - ticket 5 is a child of ticket 12 and ticket 15, or the other way around: ticket 12 and ticket 15 can only be closed when ticket 5 is closed.

Also done.

[nkantrowitz]

Are there any requests here that aren't met by the current MasterTickets plugin? If not I think we can close this.

[jfrancis@…]

The MasterTickets plugin is great, but I think that it is missing some fundamental philosophies behind this ticket. The plugin allows for what I would call "ticket dependencies". So this ticket cannot be closed before that ticket, etc. It does not, however, fulfill the idea of a ticket hierarchy.

What I am looking for is a way to have a ticket at one level of abstraction, which breaks down into tickets of a lower level of abstraction. Clearly, there are dependencies involved, but dependencies are not the whole picture.

So a progress bar would be nice on the master ticket. For those that track efforts, it would be nice to have a protocol for being able to calculate the fields of the master ticket based on the child tickets, and so on.

Take a look at SubTickets for a start on what is required here.

[Ingmar]

The SubTicket? description at http://trac.edgewall.org/wiki/SubTickets is great! Is there any effort going on to implement this ?

[Ingmar]

The SubTickets description is great!
Is there any effort going on to implement this ?

[cboos]

It's not forgotten, at least ;-)

[daniel.oconnor@…]

Replying to Ingmar:

The SubTickets description is great!
Is there any effort going on to implement this ?

#6328 is a duplicate of SubTickets / this ticket

[nkantrowitz]

Objections to marking this closed and moving outstanding feature requests over to the MasterTickets plugin?

[martin.marcher@…]

• I have no idea what to enter here so that it isn't marked by your tool to prevent unwanted message
• Hence I'm entering nonsense real text to get around it
• I really think there should be an easier option to get unsubscribed this is like the 5th time I try a new comment.

[Ingmar@…]

Objections to marking this closed and moving outstanding feature requests over to the http://trac-hacks.org/wiki/MasterTicketsPlugin plugin?

According to that ticket's lead description it is NOT trying to achieve the core needs of SubTickets:

• It does not provide ticket-hiding for sub-tasks of a top-level ticket.
  • There is no parent/child relationship possible
  • You cannot view the descriptions of tickets depending on the current ticket
  • In fact, there are no explicit features that can assist you with sub-task management
  • Although it would be cool.

• It does not allow you to create a dependent ticket from the current ticket

• It does not include reporting features to show how tasks are interrelated (other than the dependency graph already described above).

Only if those apparently key design goal differences can be eliminated would it make sense to merge this request with the plugin.

However, would this ticket not be better as part of the core system? It adds a lot in terms of the ability to track requirements (the master ticket) and their implementation (sub tickets) as well as auto assignment of fields that can be inherited from the master (i.e. project, milestone, developer to work on, etc). These things are so core to project management that according to the vision on the top of the page (Integrated SCM & Project Management) Trac should support this natively.

Who do I need to talk to if I want to help implement this?

[nkantrowitz]

Replying to Ingmar@clarontech.com: