Edgewall Software
Modify

Opened 10 years ago

Last modified 4 months ago

#886 reopened enhancement

Add support for Master tickets

Reported by: dmurphy25@… Owned by: nkantrowitz
Priority: highest Milestone: next-major-releases
Component: ticket system Version: devel
Severity: major Keywords: relations
Cc: marcandre.lureau@…, hwinkel@…, mrovner@…, trac@…, dpeterson@…, bruno@…, shishz@…, alecclews@…, jorvis@…, jkletsky@…, peter.merel@…, Andreas.Podgurski@…, nick+trac@…, gerz@…, daved@…, josh.moore@…, dlawson@…, mark81@…, carwyn@…, tobias.roeser@…, erikand@…, patrik@…, zeph.gillen@…, janne@…, m.galante@…, dilshod@…, fotos@…, j.vargas@…, trac-eolg@…, planders@…, trac@…, Ingmar@…, zhenxin0603@…, luke@…, munsey@…, alex.chugunov@…, drop_s@…, itamarost@…, ray@…, stepmoore@…, mikko.rantalainen@…, alex@…, joao.antunes@…, j.beilicke@…, david@…, franz.mayer@…
Release Notes:
API Changes:

Description

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.

Attachments (0)

Change History (149)

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

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

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

comment:4 Changed 10 years ago by Tristan Seligmann <mithrandi@…>

This sounds like a dup of #31 to me.

comment:5 Changed 9 years ago by cboos

  • Milestone set to 0.9
  • Owner changed from jonas to cboos
  • Status changed from new to assigned

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.

comment:6 Changed 9 years ago by cmlenz

  • Milestone changed from 0.9 to 1.0

Deferred.

comment:7 Changed 9 years ago by Gunnar Wagenknecht <gunnar@…>

  • Cc gunnar@… added

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

comment:9 Changed 9 years ago by cboos

  • Keywords relations added
  • Severity changed from normal to major

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.

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

comment:11 Changed 9 years ago by mrovner@…

  • Cc mrovner@… added

see also #2075

comment:12 Changed 9 years ago by asmodai@…

Potential duplicate ticket: #2087?

comment:13 Changed 9 years ago by cmlenz

#2193 has been marked as duplicate of this ticket.

comment:14 Changed 9 years ago by trac@…

  • Cc trac@… added

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.

comment:15 Changed 9 years ago by 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'): ...

comment:16 Changed 9 years ago by dpeterson <dpeterson@…>

  • Cc dpeterson@… added

comment:17 Changed 9 years ago by 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.

comment:18 Changed 9 years ago by 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.

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

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

comment:21 Changed 9 years ago by 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.

comment:22 Changed 9 years ago by 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.

comment:23 Changed 9 years ago by anonymous

  • Cc bruno@… added

comment:24 Changed 9 years ago by anonymous

  • Cc shishz@… added

comment:25 Changed 9 years ago by anonymous

  • Cc alecclews@… added

comment:26 Changed 9 years ago by anonymous

  • Cc jorvis@… added

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

comment:28 Changed 9 years ago by 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!

comment:29 Changed 9 years ago by cmlenz

#2659 has been marked as duplicate of this ticket.

comment:30 Changed 9 years ago by anonymous

  • Cc jkletsky@… added

comment:31 Changed 9 years ago by anonymous

  • Cc mrovner@… added; mrovner@… removed

comment:32 Changed 9 years ago by anonymous

  • Cc peter.merel@… added

comment:33 Changed 9 years ago by anonymous

  • Cc peter.merel@… added; peter.merel@… removed

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.

comment:34 Changed 9 years ago by 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.

comment:35 Changed 8 years ago by anonymous

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

comment:36 Changed 8 years ago by 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) 

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

comment:38 Changed 8 years ago by anonymous

  • Cc nick+trac@… added

comment:39 Changed 8 years ago by anonymous

  • Cc gerz@… added

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

comment:40 Changed 8 years ago by anonymous

  • Cc daved@… added

comment:41 Changed 8 years ago by anonymous

  • Cc peter.merel@… Andreas.Podgurski@… zoogie@… added; peter.merel@… removed

comment:42 Changed 8 years ago by anonymous

  • Cc josh.moore@… added

comment:43 Changed 8 years ago by anonymous

  • Cc dlawson@… added

comment:44 Changed 8 years ago by anonymous

  • Cc mark81@… added

comment:45 Changed 8 years ago by anonymous

  • Cc carwyn@… added

comment:46 Changed 8 years ago by anonymous

  • Cc trac.tickets@… added

comment:47 Changed 8 years ago by athomas

  • Milestone changed from 1.0 to 0.11
  • Owner changed from cboos to athomas
  • Status changed from assigned to new

To reflect reality, reassigning and targetting for 0.11.

comment:48 Changed 8 years ago by athomas

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

comment:49 Changed 8 years ago by anonymous

  • Cc gunnar@… removed

comment:50 Changed 8 years ago by anonymous

  • Cc hwinkel@… added; mrovner@… trac@… dpeterson@… bruno@… shishz@… alecclews@… jorvis@… jkletsky@… peter.merel@… Andreas.Podgurski@… nick+trac@… gerz@… daved@… zoogie@… josh.moore@… dlawson@… mark81@… carwyn@… trac.tickets@… removed

comment:51 Changed 8 years ago by anonymous

  • Cc mrovner@… trac@… dpeterson@… bruno@… shishz@… alecclews@… jorvis@… jkletsky@… peter.merel@… Andreas.Podgurski@… nick+trac@… gerz@… daved@… zoogie@… josh.moore@… dlawson@… mark81@… carwyn@… trac.tickets@… added

Adding us all back to the CC list.

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

comment:53 Changed 8 years ago by TobiasRoeser <tobias.roeser@…>

  • Cc tobias.roeser@… added

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

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

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

comment:57 follow-up: Changed 8 years ago by Noah Kantrowitz <coderanger@…>

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

comment:58 in reply to: ↑ 57 Changed 8 years ago by 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"

comment:59 follow-up: Changed 8 years ago by 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'?

comment:60 in reply to: ↑ 59 ; follow-up: Changed 8 years ago by 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
  1. 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.

comment:61 in reply to: ↑ 60 Changed 8 years ago by 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.

comment:62 Changed 8 years ago by anonymous

  • Cc erikand@… added

I want to listen in on this..

comment:63 Changed 8 years ago by elmarco

  • Cc marcandre.lureau@… added

comment:64 Changed 8 years ago by anonymous

  • Cc karl.erisman@… added

comment:65 Changed 7 years ago by anonymous

  • Cc patrik@… added

comment:66 Changed 7 years ago by 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!

comment:67 Changed 7 years ago by cboos

  • Milestone changed from 0.11 to 0.12

Sorry, not going to happen for 0.11.

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

comment:69 Changed 7 years ago by cboos

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

comment:70 Changed 7 years ago by athomas

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

comment:71 Changed 7 years ago by anonymous

  • Cc r6dude@… added

comment:72 Changed 7 years ago by anonymous

  • Cc zeph.gillen@… added

comment:73 Changed 7 years ago by anonymous

  • Cc janne@… added

comment:74 Changed 7 years ago by anonymous

  • Cc karl.erisman@… removed

comment:75 Changed 7 years ago by anonymous

  • Cc m.galante@… added

comment:76 Changed 7 years ago by number5@…

  • Cc number5@… added

comment:77 Changed 7 years ago by anonymous

  • Cc dilshod@… added

comment:78 Changed 7 years ago by nkantrowitz

  • Owner changed from athomas to nkantrowitz
  • Version changed from 0.7.1 to devel

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.

comment:79 in reply to: ↑ 3 ; follow-up: Changed 7 years ago by martin.marcher@…

  • Cc martin.marcher@… added

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

comment:80 in reply to: ↑ 79 Changed 7 years ago by 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.

comment:81 Changed 7 years ago by nkantrowitz

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

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

comment:83 follow-up: Changed 7 years ago by anonymous

  • Cc fotos@… added

comment:84 in reply to: ↑ 83 Changed 7 years ago by Ingmar

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

comment:85 follow-up: Changed 7 years ago by Ingmar

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

comment:86 Changed 7 years ago by cboos

It's not forgotten, at least ;-)

comment:87 in reply to: ↑ 85 Changed 7 years ago by 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

comment:88 Changed 7 years ago by anonymous

  • Cc pierreroth64@… added

comment:89 Changed 7 years ago by Jonathan Vargas <j.vargas@…>

  • Cc j.vargas@… added

comment:90 Changed 7 years ago by trac-eolg@…

  • Cc trac-eolg@… added

comment:91 Changed 6 years ago by chrisk

  • Cc ckarcher@… added

comment:92 Changed 6 years ago by planders@…

  • Cc planders@… added

comment:93 Changed 6 years ago by trac@…

  • Cc trac@… added

comment:94 Changed 6 years ago by nkantrowitz

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

comment:95 Changed 6 years ago by martin.marcher@…

  • Cc martin.marcher@… removed
  • 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.

comment:96 follow-up: Changed 6 years ago by Ingmar@…

  • Cc Ingmar@… added

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?

comment:97 in reply to: ↑ 96 ; follow-up: Changed 6 years ago by nkantrowitz

Replying to Ingmar@clarontech.com:

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

That would be me. I go by "coderanger" on IRC, and can be found there most of the time.

comment:98 follow-up: Changed 6 years ago by Ingmar

Sorry to clutter this with communication trouble, but "coderanger" on IRC does not help me enough, my pidgin client is capable of connecting to AIM, MSN, Yahoo!, XMPP, ICQ, IRC, SILC, SIP/SIMPLE, Novell GroupWise?, Lotus Sametime, Bonjour, Zephyr, MySpaceIM, Gadu-Gadu, and QQ all at once, but it still can not locate "coderanger". You already have my full email from the previous post, so please email me how to contact you directly (email or phone).

comment:99 in reply to: ↑ 98 Changed 6 years ago by anonymous

http://trac.edgewall.org/wiki/IrcChannel

Replying to Ingmar:

Sorry to clutter this with communication trouble, but "coderanger" on IRC does not help me enough, my pidgin client is capable of connecting to AIM, MSN, Yahoo!, XMPP, ICQ, IRC, SILC, SIP/SIMPLE, Novell GroupWise?, Lotus Sametime, Bonjour, Zephyr, MySpaceIM, Gadu-Gadu, and QQ all at once, but it still can not locate "coderanger". You already have my full email from the previous post, so please email me how to contact you directly (email or phone).

comment:100 in reply to: ↑ 97 ; follow-up: Changed 6 years ago by cboos

Replying to nkantrowitz:

Replying to Ingmar@clarontech.com:

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

That would be me. I go by "coderanger" on IRC, and can be found there most of the time.

I'd like to remind everyone that "TracTeam != coderanger on IRC".

Of course, if you only aim to implement this feature within the scope of his TH:MasterTicketsPlugin, that would be the way to go.

But if you'd like to get something like SubTickets implemented in Trac itself, the development discussion should take place on the Trac-dev MailingList, where everyone interested in the topic could participate.

comment:101 in reply to: ↑ 100 Changed 6 years ago by anonymous

Replying to cboos:

But if you'd like to get something like SubTickets implemented in Trac itself, the development discussion should take place on the Trac-dev MailingList, where everyone interested in the topic could participate.

No matter where these features end up, starting over from scratch seems silly. Subtickets is mostly a UI that can use much of the same data model as the existing code.

comment:102 Changed 6 years ago by anonymous

  • Priority changed from normal to highest

comment:103 Changed 6 years ago by zhenxin0603@…

  • Cc zhenxin0603@… added

comment:104 follow-up: Changed 6 years ago by anonymous

  • Resolution set to fixed
  • Status changed from new to closed

comment:105 in reply to: ↑ 104 Changed 6 years ago by osimons

  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to anonymous:

Please don't do that.

comment:106 Changed 6 years ago by luke@…

  • Cc luke@… added

comment:107 Changed 5 years ago by motumboe@…

  • Cc motumboe@… added

I think this feature would be quite interesting.

comment:108 Changed 5 years ago by anonymous

please, this SubTickets proposal seems a no-brainer, it is needed!

comment:109 Changed 5 years ago by Sebastian Heuchler <sheuchler@…>

  • Cc sheuchler@… added

comment:110 Changed 5 years ago by munsey@…

  • Cc munsey@… added

comment:111 Changed 5 years ago by gareth@…

  • Cc gareth@… added

comment:112 Changed 5 years ago by pierreroth64@…

  • Cc pierreroth64@… removed

comment:113 Changed 5 years ago by alex.chugunov@…

  • Cc alex.chugunov@… added

comment:114 Changed 5 years ago by Drops <drop_s@…>

  • Cc drop_s@… added

comment:115 follow-up: Changed 5 years ago by anonymous

But if you'd like to get something like SubTickets implemented in Trac itself, the development discussion should take place on the Trac-dev MailingList, where everyone interested in the topic could participate.

comment:116 in reply to: ↑ 115 Changed 5 years ago by anonymous

Replying to anonymous:

But if you'd like to get something like SubTickets implemented in Trac itself, the development discussion should take place on the Trac-dev MailingList, where everyone interested in the topic could participate.

Ok, thanks you

comment:117 in reply to: ↑ 3 Changed 5 years ago by ivan@…

Replying to 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.

This is excellent idea!

comment:118 Changed 4 years ago by anonymous

How does the new TH:SubticketsPlugin relate to this ticket?

comment:119 Changed 4 years ago by number5@…

  • Cc number5@… removed

comment:120 Changed 4 years ago by sheuchler <sheuchler@…>

  • Cc sheuchler@… removed

comment:121 Changed 4 years ago by itamaro

  • Cc itamarost@… added

comment:122 Changed 4 years ago by ckarcher@…

  • Cc ckarcher@… removed

removing from CC list

comment:123 Changed 4 years ago by gareth@…

  • Cc gareth@… removed

removing email

comment:124 Changed 4 years ago by Michael Imamura <zoogie@…>

  • Cc zoogie@… removed

comment:125 Changed 4 years ago by anonymous

can i comment?

comment:126 Changed 4 years ago by Ingmar

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

This is excellent idea!

I disagree. I'd like to be able to define a few master tickets for my milestone, i.e. the top level feature list. If a feature has separate implementation blocks maybe to to given to different developers then I'd like to make second level master tickets at children of the top level feature ticket. There may be cases where I want three or four levels also.

And finally, when I get error reports, I'd like to make bug tickets as children of the feature ticket that the bug is reported for.

So in fact there does not need to be any difference between a master ticket and a child ticket. Just have one ticket type that can have children.

Also when making a child ticket by clicking on a link in the parent ticket, the ticket should be by default owned by the same login as the parent ticket, and have the same milestone, same severity, etc. And it would be fantastic if each ticket could have an editable time estimate field, and a non editable one that is the sum of its time and the times of its complete child tree.

comment:127 Changed 4 years ago by ray@…

  • Cc ray@… added

comment:128 Changed 4 years ago by r6dude@…

  • Cc r6dude@… removed

comment:129 Changed 4 years ago by Dave Morgan <morgand@…>

In reply to Ingmar….

Master tickets should be able to be children of other master tickets.

That way you can "ticket" a release - yet also break your tasks into sub-projects that can then each have their own children (and so on)…

This then also begs the question - what is the difference between a Milestone & a 1st level (ie top level) Master ticket (ie a ticket that has no parent).

comment:130 Changed 4 years ago by jim.callahan.hsqe@…

  • Cc jim.callahan.hsqe@… added

comment:131 Changed 4 years ago by stepmoore@…

  • Cc stepmoore@… added

comment:132 Changed 4 years ago by stepmoore@…

  • Cc moore@… added

comment:133 Changed 4 years ago by moore@…

  • Cc moore@… removed

comment:134 Changed 4 years ago by trac.tickets@…

  • Cc trac.tickets@… removed

comment:135 Changed 4 years ago by fbrettschneider@…

Some here say a milestone is just a master ticket.

But I think the big difference is: a ticket is a piece of work, a milestone is more a special date on the time line. A ticket has a duration, a milestone is just a moment in time, a completion date (perhaps of a quality improvement step in a software cycle). At such date, one can bill how much work has been done measured in tickets.

The time between milestones must be organized by arranging the tickets in questions of time and resources. Currently, we just see the progress bar of a milestone, kind of a simple scheduler. I could also image a Gantt chart. Those little bars are the same as Trac's tickets. The sub ticket stuff sounds to me like a trial to reinvent a Gantt chart. Because a ticket is an activity there, the master ticket is a summary element.

comment:136 Changed 4 years ago by Mikko Rantalainen <mikko.rantalainen@…>

  • Cc mikko.rantalainen@… added

comment:137 Changed 4 years ago by Alex Willmer <alex@…>

  • Cc alex@… added

comment:138 Changed 4 years ago by joao.antunes@…

  • Cc joao.antunes@… added

comment:139 Changed 4 years ago by j.beilicke@…

  • Cc j.beilicke@… added

comment:140 Changed 3 years ago by Dave Heston <david@…>

  • Cc david@… added

comment:141 Changed 3 years ago by anonymous

We use sub tasks in Jira all the time. I really miss it in Trac. Milestones are too complex to create.

comment:142 Changed 3 years ago by anonymous

I have used sub tasks in Jira too. This wasn't in the 1st version of Jira I used and I noticed an uptick in productivity when it came in.

comment:143 Changed 3 years ago by rblank

#10231 was closed as a duplicate, and contains a simple patch with a limited implementation of parent tickets.

comment:144 Changed 22 months ago by franz.mayer@…

  • Cc franz.mayer@… added

comment:149 Changed 11 months ago by motumboe@…

  • Cc motumboe@… removed

comment:150 Changed 11 months ago by jim.callahan.hsqe@…

  • Cc jim.callahan.hsqe@… removed

comment:151 Changed 11 months ago by jim.callahan.hsqe@…

  • Cc jim.callahan.hsqe@… removed

comment:153 Changed 4 months ago by anonymous

Any hope that this will get implemented? It is a key reason why I am looking for a different system to replace trac. With hirarchical tickets I could

  • get some type of gant chart information out of trac - really needed
  • get to inherit owners from parent - speeds up time to create tho ticket
  • reduce micromanagement

comment:154 Changed 4 months ago by TimeHorse

Folks, I speak Python. I can help. But my concern is that it could be implemented by just adding a new custom field type of "trac" reference. In other words, you can at your will add a "parent" field or a "child" field that you select from a combo box. The issue, as I see it, is maintaining back-references, but as a first cut maybe just forward-links would make a lot of folks happy.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as reopened The owner will remain nkantrowitz.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from nkantrowitz to anonymous. Next status will be 'assigned'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.