Edgewall Software
Modify

Opened 19 years ago

Last modified 3 months ago

#886 new enhancement

Add support for Master tickets

Reported by: dmurphy25@… Owned by:
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@…, tobias.roeser@…, erikand@…, patrik@…, zeph.gillen@…, janne@…, m.galante@…, dilshod@…, fotos@…, j.vargas@…, trac-eolg@…, planders@…, trac@…, Ingmar@…, luke@…, munsey@…, alex.chugunov@…, drop_s@…, itamarost@…, ray@…, stepmoore@…, mikko.rantalainen@…, joao.antunes@…, david@…, franz.mayer@…, leho@… Branch:
Release Notes:
API Changes:
Internal 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 (161)

comment:1 by zilvinas@…, 19 years ago

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 by cboos@…, 19 years ago

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 by dmurphy25@…, 19 years ago

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 by Tristan Seligmann <mithrandi@…>, 19 years ago

This sounds like a dup of #31 to me.

comment:5 by Christian Boos, 19 years ago

Milestone: 0.9
Owner: changed from Jonas Borgström to Christian Boos
Status: newassigned

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 by Christopher Lenz, 19 years ago

Milestone: 0.91.0

Deferred.

comment:7 by Gunnar Wagenknecht <gunnar@…>, 19 years ago

Cc: gunnar@… added

comment:8 by dmbrucker@…, 19 years ago

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 by Christian Boos, 19 years ago

Keywords: relations added
Severity: normalmajor

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 by dmbrucker@…, 19 years ago

…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 by mrovner@…, 19 years ago

Cc: mrovner@… added

see also #2075

comment:12 by asmodai@…, 19 years ago

Potential duplicate ticket: #2087?

comment:13 by Christopher Lenz, 18 years ago

#2193 has been marked as duplicate of this ticket.

comment:14 by trac@…, 18 years ago

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 by Christian Boos, 18 years ago

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 by dpeterson <dpeterson@…>, 18 years ago

Cc: dpeterson@… added

comment:17 by trac@…, 18 years ago

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 by dpeterson <dpeterson@…>, 18 years ago

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 by Christian Boos, 18 years ago

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 by trac@…, 18 years ago

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 by trac@…, 18 years ago

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 by dpeterson <dpeterson@…>, 18 years ago

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 by anonymous, 18 years ago

Cc: bruno@… added

comment:24 by anonymous, 18 years ago

Cc: shishz@… added

comment:25 by anonymous, 18 years ago

Cc: alecclews@… added

comment:26 by anonymous, 18 years ago

Cc: jorvis@… added

comment:27 by anonymous, 18 years ago

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 by anonymous, 18 years ago

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 by Christopher Lenz, 18 years ago

#2659 has been marked as duplicate of this ticket.

comment:30 by anonymous, 18 years ago

Cc: jkletsky@… added

comment:31 by anonymous, 18 years ago

Cc: mrovner@… added; mrovner@… removed

comment:32 by anonymous, 18 years ago

Cc: peter.merel@… added

comment:33 by anonymous, 18 years ago

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 by anonymous, 18 years ago

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 by anonymous, 18 years ago

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

comment:36 by Ilias Lazaridis <ilias@…>, 18 years ago

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 by Emmanuel Blot, 18 years ago

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 by anonymous, 18 years ago

Cc: nick+trac@… added

comment:39 by anonymous, 18 years ago

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 by anonymous, 18 years ago

Cc: daved@… added

comment:41 by anonymous, 18 years ago

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

comment:42 by anonymous, 18 years ago

Cc: josh.moore@… added

comment:43 by anonymous, 18 years ago

Cc: dlawson@… added

comment:44 by anonymous, 18 years ago

Cc: mark81@… added

comment:45 by anonymous, 18 years ago

Cc: carwyn@… added

comment:46 by anonymous, 18 years ago

Cc: trac.tickets@… added

comment:47 by Alec Thomas, 18 years ago

Milestone: 1.00.11
Owner: changed from Christian Boos to Alec Thomas
Status: assignednew

To reflect reality, reassigning and targetting for 0.11.

comment:48 by Alec Thomas, 18 years ago

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

comment:49 by anonymous, 18 years ago

Cc: gunnar@… removed

comment:50 by anonymous, 18 years ago

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 by anonymous, 18 years ago

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 by s.e.latham@…, 17 years ago

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 by TobiasRoeser <tobias.roeser@…>, 17 years ago

Cc: tobias.roeser@… added

comment:54 by drew, 17 years ago

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 by Stefan, 17 years ago

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 by alex@…, 17 years ago

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 by Noah Kantrowitz <coderanger@…>, 17 years ago

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

in reply to:  57 comment:58 by anonymous, 17 years ago

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 by anonymous, 17 years ago

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'?

in reply to:  59 ; comment:60 by Bill Pennington <bill@…>, 17 years ago

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.

in reply to:  60 comment:61 by Noah Kantrowitz <coderanger@…>, 17 years ago

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 by anonymous, 17 years ago

Cc: erikand@… added

I want to listen in on this..

comment:63 by elmarco, 17 years ago

Cc: marcandre.lureau@… added

comment:64 by anonymous, 17 years ago

Cc: karl.erisman@… added

comment:65 by anonymous, 17 years ago

Cc: patrik@… added

comment:66 by dpeterson@…, 17 years ago

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 by Christian Boos, 17 years ago

Milestone: 0.110.12

Sorry, not going to happen for 0.11.

comment:68 by Alec Thomas, 17 years ago

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 by Christian Boos, 17 years ago

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

comment:70 by Alec Thomas, 17 years ago

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

comment:71 by anonymous, 17 years ago

Cc: r6dude@… added

comment:72 by anonymous, 17 years ago

Cc: zeph.gillen@… added

comment:73 by anonymous, 17 years ago

Cc: janne@… added

comment:74 by anonymous, 17 years ago

Cc: karl.erisman@… removed

comment:75 by anonymous, 17 years ago

Cc: m.galante@… added

comment:76 by number5@…, 17 years ago

Cc: number5@… added

comment:77 by anonymous, 17 years ago

Cc: dilshod@… added

comment:78 by Noah Kantrowitz, 17 years ago

Owner: changed from Alec Thomas to Noah Kantrowitz
Version: 0.7.1devel

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.

in reply to:  3 ; comment:79 by martin.marcher@…, 17 years ago

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

in reply to:  79 comment:80 by Noah Kantrowitz, 17 years ago

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 by Noah Kantrowitz, 17 years ago

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

comment:82 by jfrancis@…, 17 years ago

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 by anonymous, 17 years ago

Cc: fotos@… added

in reply to:  83 comment:84 by Ingmar, 16 years ago

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

comment:85 by Ingmar, 16 years ago

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

comment:86 by Christian Boos, 16 years ago

It's not forgotten, at least ;-)

in reply to:  85 comment:87 by daniel.oconnor@…, 16 years ago

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 by anonymous, 16 years ago

Cc: pierreroth64@… added

comment:89 by Jonathan Vargas <j.vargas@…>, 16 years ago

Cc: j.vargas@… added

comment:90 by trac-eolg@…, 16 years ago

Cc: trac-eolg@… added

comment:91 by chrisk, 16 years ago

Cc: ckarcher@… added

comment:92 by planders@…, 16 years ago

Cc: planders@… added

comment:93 by trac@…, 16 years ago

Cc: trac@… added

comment:94 by Noah Kantrowitz, 16 years ago

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

comment:95 by martin.marcher@…, 16 years ago

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 by Ingmar@…, 16 years ago

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?

in reply to:  96 ; comment:97 by Noah Kantrowitz, 16 years ago

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 by Ingmar, 16 years ago

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

in reply to:  98 comment:99 by anonymous, 16 years ago

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

in reply to:  97 ; comment:100 by Christian Boos, 16 years ago

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.

in reply to:  100 comment:101 by anonymous, 16 years ago

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 by anonymous, 16 years ago

Priority: normalhighest

comment:103 by zhenxin0603@…, 16 years ago

Cc: zhenxin0603@… added

comment:104 by anonymous, 16 years ago

Resolution: fixed
Status: newclosed

in reply to:  104 comment:105 by osimons, 16 years ago

Resolution: fixed
Status: closedreopened

Replying to anonymous:

Please don't do that.

comment:106 by luke@…, 15 years ago

Cc: luke@… added

comment:107 by motumboe@…, 15 years ago

Cc: motumboe@… added

I think this feature would be quite interesting.

comment:108 by anonymous, 15 years ago

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

comment:109 by Sebastian Heuchler <sheuchler@…>, 15 years ago

Cc: sheuchler@… added

comment:110 by munsey@…, 15 years ago

Cc: munsey@… added

comment:111 by gareth@…, 15 years ago

Cc: gareth@… added

comment:112 by pierreroth64@…, 15 years ago

Cc: pierreroth64@… removed

comment:113 by alex.chugunov@…, 15 years ago

Cc: alex.chugunov@… added

comment:114 by Drops <drop_s@…>, 15 years ago

Cc: drop_s@… added

comment:115 by anonymous, 14 years ago

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.

in reply to:  115 comment:116 by anonymous, 14 years ago

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

in reply to:  3 comment:117 by ivan@…, 14 years ago

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 by anonymous, 14 years ago

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

comment:119 by number5@…, 14 years ago

Cc: number5@… removed

comment:120 by sheuchler <sheuchler@…>, 14 years ago

Cc: sheuchler@… removed

comment:121 by Itamar Ostricher, 14 years ago

Cc: itamarost@… added

comment:122 by ckarcher@…, 14 years ago

Cc: ckarcher@… removed

removing from CC list

comment:123 by gareth@…, 14 years ago

Cc: gareth@… removed

removing email

comment:124 by Michael Imamura <zoogie@…>, 14 years ago

Cc: zoogie@… removed

comment:125 by anonymous, 14 years ago

can i comment?

comment:126 by Ingmar, 14 years ago

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 by ray@…, 14 years ago

Cc: ray@… added

comment:128 by r6dude@…, 14 years ago

Cc: r6dude@… removed

comment:129 by Dave Morgan <morgand@…>, 14 years ago

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 by jim.callahan.hsqe@…, 14 years ago

Cc: jim.callahan.hsqe@… added

comment:131 by stepmoore@…, 13 years ago

Cc: stepmoore@… added

comment:132 by stepmoore@…, 13 years ago

Cc: moore@… added

comment:133 by moore@…, 13 years ago

Cc: moore@… removed

comment:134 by trac.tickets@…, 13 years ago

Cc: trac.tickets@… removed

comment:135 by fbrettschneider@…, 13 years ago

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 by Mikko Rantalainen <mikko.rantalainen@…>, 13 years ago

Cc: mikko.rantalainen@… added

comment:137 by Alex Willmer <alex@…>, 13 years ago

Cc: alex@… added

comment:138 by joao.antunes@…, 13 years ago

Cc: joao.antunes@… added

comment:139 by j.beilicke@…, 13 years ago

Cc: j.beilicke@… added

comment:140 by Dave Heston <david@…>, 13 years ago

Cc: david@… added

comment:141 by anonymous, 13 years ago

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

comment:142 by anonymous, 13 years ago

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 by Remy Blank, 13 years ago

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

comment:144 by franz.mayer@…, 11 years ago

Cc: franz.mayer@… added

comment:149 by motumboe@…, 11 years ago

Cc: motumboe@… removed

comment:150 by jim.callahan.hsqe@…, 11 years ago

Cc: jim.callahan.hsqe@… removed

comment:151 by jim.callahan.hsqe@…, 11 years ago

Cc: jim.callahan.hsqe@… removed

comment:153 by anonymous, 10 years ago

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 by TimeHorse, 10 years ago

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.

comment:155 by lkraav <leho@…>, 9 years ago

Cc: leho@… added

comment:156 by Ryan J Ollos, 9 years ago

Owner: Noah Kantrowitz removed
Status: reopenednew

comment:157 by zhenxin0603@…, 9 years ago

Cc: zhenxin0603@… removed

comment:158 by Alex Willmer <alex@…>, 9 years ago

Cc: alex@… removed

in reply to:  153 comment:159 by Ingmar, 8 years ago

Same reason why I am looking for another system to replace trac. This is the highest priority missing feature.

Last edited 8 years ago by Ryan J Ollos (previous) (diff)

comment:160 by figaro, 8 years ago

comment:161 by Jan Beilicke <j.beilicke@…>, 8 years ago

Cc: j.beilicke@… removed

comment:162 by Carwyn Edwards <carwyn@…>, 8 years ago

Cc: carwyn@… removed

in reply to:  160 comment:163 by Cinc-th, 8 years ago

Replying to figaro:

Some plugins are available that implement this feature request to a degree:

Another one:

There is an additional macro th:ChildTicketTreeMacro to print a ticket tree on wiki pages.

comment:164 by anonymous, 6 years ago

It is true that there are plugins, but plugins might always be discontinued.

This might be the "most" wanted functionality for users.

Wouldn't it be possible to integrate e.g. SubticketsPlugin into main? I think parent-child relationships cover most use-cases of "normal" users.

comment:165 by figaro , 6 years ago

It is rare for plugins to be discontinued, although they might stay inactive for some time. When plugins are deprecated, they are mostly superceded by an alternative plugin with similar functionality. Trac core is continuously being upgraded for stability, performance and external dependencies (Python3, jinja). See also #comment:115.

comment:166 by anonymous, 6 years ago

Well "rare" is not impossible. So users have to ask themselves whether they want to take that risk or not.

Personally I think such basic functionality, which users might know from other tools (JIRA et al.) should be supported out of the box. Most users will want to be able to link tickets and having to tell them to "chose a plugin from this list" might put them off before they even start using trac.

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. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


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