Changes between Version 22 and Version 23 of ChildTicketsPlugin


Ignore:
Timestamp:
Jan 5, 2012 9:53:17 PM (3 years ago)
Author:
walnut
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ChildTicketsPlugin

    v22 v23  
    9696You can check out ChildTicketsPlugin from [http://trac-hacks.org/svn/childticketsplugin here] using Subversion, or [source:childticketsplugin browse the source] with Trac. 
    9797 
    98 == NOTE: New 'look and feel' For 0.12 == 
     98== Examples == 
    9999 
    100 Since trac 0.12 has the nice looking 'collapsible' areas for 'Attachments' and 'Modify Ticket' sections, I have decided to use these for the child ticket tables. It is now possible (and looks much nicer, I think!) to hide the child tickets as they are incorporated into there own collapsible section. 
    101  
    102 [[Image(NewChildTicketTable.png)]] 
    103  
    104 == Example == 
    105  
    106 === Handling multiple bug-fixes for single bug-report === 
    107  
    108 In my last job using trac with svn, we had a branch of development for each milestone of development plus a 'special' milestone to assign for hotfix/patches. Rather than creating a single 'bug-fix' ticket and commenting on the ticket that the fix had been applied to milestone X on branch X, milestone Y on branch Y, etc..., we would create a single 'bug-report' ticket (with version info but no milestone) and this ticket would, after assessment from developers/project-mgr, have a bug-fix child-ticket created per milestone - each with its own life-cycle, priority, (sometimes) developer, etc ...  
    109  
    110 [[Image(bug-report-example.jpg)]] 
    111  
    112 === Handling sub-tasks from a single issue === 
    113  
    114 Probably self explanatory: you have something that needs to be done by several different people. Split it up into sub-tasks. 
    115  
    116 [[Image(issue-example.jpg)]] 
    117  
    118 === A New Feature generates bugs === 
    119  
    120 When developing a new feature (a single ticket), our developers would 'finish' the feature and pass it to our testing department. The feature, on the whole, might be OK but require several days testing. Within that time several bugs are generated as a direct result of this new feature. It makes no sense to pass the original feature ticket back to the developers (the feature has not been 'rejected' and is still in testing!), so instead, the testing tem can make 'bug-fix' child-tickets for this parent ticket. The feature might even be released with known bugs but at least they're recorded and owned by someone/somewhere! 
    121  
    122 === Using the 'parent.type.restrict_child_type' Option === 
    123  
    124 If you are using the above option, the available child types will be rendered as individual buttons. 
    125  
    126 [[Image(MultipleChildType.png)]] 
    127  
    128 === Creating a Progress Bar for Child Tickets === 
    129  
    130 If you have a lot of child tickets for one parent, and want an overview of those tickets, you can use the ProgressMeterMacro as provided by [wiki:qwp0]. In order to use this, simply provide the 'parent' as the only search query. For example, if you put the following macro definition in your ticket description: 
    131  
    132 {{{ 
    133 [[ProgressMeter(parent=#1)]] 
    134 }}} 
    135  
    136 Then the following will appear in the ticket description: 
    137  
    138 [[Image(progmeter_ticket.png)]] 
     100Some examples [wiki:ChildTicketsPlugin/Examples here].  
    139101 
    140102