[Trac-tickets] Re: [The Trac Project] #886: Add support for Master tickets

[The Trac Project]

#886: Add support for Master tickets
-------------------------------+--------------------------------------------
 Reporter:  dmurphy25 at csc.com  |        Owner:  cboos   
     Type:  enhancement        |       Status:  assigned
 Priority:  normal             |    Milestone:  1.0     
Component:  ticket system      |      Version:  0.7.1   
 Severity:  major              |   Resolution:          
 Keywords:  relations          |  
-------------------------------+--------------------------------------------
Changes (by cboos):

  * severity:  normal => major
  * keywords:  => relations

Comment:

 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.

-- 
Ticket URL: <http://projects.edgewall.com/trac/ticket/886>
The Trac Project <http://trac.edgewall.com/>