Changes between Version 26 and Version 27 of ChildTicketsPlugin
- Timestamp:
- Apr 9, 2015, 11:48:08 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ChildTicketsPlugin
v26 v27 5 5 == Description 6 6 7 Some time ago I came across the problem of how to manage child tickets in a meaningful fashion, we were using [wiki:coderanger]'s original [wiki:MasterTicketsPlugin] and it was great until we started to allow tickets to be viewed and created by people outside of our immediate development group. We found that people who were not familiar with our processes would simply create child tickets of the wrong 'type' and needed some help in getting it right. In addition, users found that the lack of visual information (ie. what are this tickets child tickets?) was also a hindrance.7 This plugin modifies the ticket description box and adds a child ticket listing table and a 'create' button for adding new child tickets. 8 8 9 Having child-tickets is useful when multiple releases need to be managed. For example for s single 'bug-report' ticket and a single 'bug-fix' ticket for each milestone/branch of development, for managing sub-tasks of an issue and for managing 'bug-fixes' required when developing a new (larger) enhancement. 10 11 This plugin modifies the ticket description box and adds a child ticket listing table and a 'create' button for adding new child tickets. 9 Having child-tickets is useful when multiple releases need to be managed. For example for a single 'bug-report' ticket and a single 'bug-fix' ticket for each milestone/branch of development, for managing sub-tasks of an issue and for managing 'bug-fixes' required when developing a new (larger) enhancement. 12 10 13 11 It is possible to control in trac.ini the following aspects of child-ticket creation/viewing: … … 16 14 * to define a default for the child type to be created / restrict the type of child-tickets 17 15 * to define which fields are inherited by child-tickets 16 17 === Background 18 19 Some time ago I came across the problem of how to manage child tickets in a meaningful fashion, we were using [wiki:coderanger]'s original [wiki:MasterTicketsPlugin] and it was great until we started to allow tickets to be viewed and created by people outside of our immediate development group. We found that people who were not familiar with our processes would simply create child tickets of the wrong 'type' and needed some help in getting it right. In addition, users found that the lack of visual information (ie. what are this tickets child tickets?) was also a hindrance. 18 20 19 21 Under Trac 0.10 I had to modify the ticket.html templates to get this working in any 'pretty' sense so I have not provided support for 0.10. As of 0.11, the ITemplateStreamFilter allows this to be incorporated nicely into a neat plugin. … … 37 39 Download the zipped source from [download:childticketsplugin here]. 38 40 39 == Source ==41 == Source 40 42 41 43 You can check out ChildTicketsPlugin from [http://trac-hacks.org/svn/childticketsplugin here] using Subversion, or [source:childticketsplugin browse the source] with Trac. … … 88 90 #!html 89 91 <table class="wiki"> 90 <tr><td width=20%>parent.<b><i>parent-type</i></b>.allow_child_tickets </td><td> Define whether child tickets are allowed or not </td><td> Default: False</td></tr> 91 <tr><td width=20%> parent.<b><i>parent-type</i></b>.table_headers </td><td> List of column headers for display in parent ticket </td><td> Default: summary, owner </td></tr> 92 <tr><td width=20%> parent.<b><i>parent-type</i></b>.default_child_type </td><td> Default child type </td><td> Default: See [ticket] section of trac.ini (default_type) </td></tr> 93 <tr><td width=20%> parent.<b><i>parent-type</i></b>.restrict_child_type </td><td> A list of possible child types, trying to create a child of a different 'type' will create an error. As of version 1.1.0, if this option is used, a list of submit buttons will be rendered allowing the user to decide which type of child ticket he/she wants to create. </td><td> Default: None </td></tr> 92 <tr><td><b>Field</b></td><td><b>Description</b></td><td><b>Default value</b></td></tr> 93 <tr><td width=20%>parent.<b><i>parent-type</i></b>.allow_child_tickets </td><td> Define whether child tickets are allowed or not </td><td> False</td></tr> 94 <tr><td width=20%> parent.<b><i>parent-type</i></b>.table_headers </td><td> List of column headers for display in parent ticket </td><td> summary, owner </td></tr> 95 <tr><td width=20%> parent.<b><i>parent-type</i></b>.default_child_type </td><td> Default child type </td><td>See [ticket] section of trac.ini (default_type) </td></tr> 96 <tr><td width=20%> parent.<b><i>parent-type</i></b>.restrict_child_type </td><td> A list of possible child types, trying to create a child of a different 'type' will create an error. As of version 1.1.0, if this option is used, a list of submit buttons will be rendered allowing the user to decide which type of child ticket he/she wants to create. </td><td>None </td></tr> 94 97 <tr><td width=20%> parent.<b><i>parent-type</i></b>.inherit </td><td> Define a list of inherited fields. </td><td> Default: None </td></tr> 95 <tr><td width=20%> default.max_depth </td><td> Limit the creation of too deep a hierarchy. </td><td> Default: 5</td></tr>98 <tr><td width=20%> default.max_depth</td><td> Limit the creation of too deep a hierarchy. </td><td>5</td></tr> 96 99 </table> 97 100 }}} 98 101 99 == Issues / Caveats102 == Known Issues / Caveats 100 103 101 104 * If you change the behaviour of the parent type (using for example allow_child_tickets/restrict_child_type) and tickets already have child tickets assigned to them you will not receive a warning about any possible conflicts until you try and modify any of the child tickets.
