|Version 4 (modified by walnut, 6 years ago) (diff)|
Support for pseudo child-tickets and a visual reference to these within a parent ticket.
NOTE @ 19/04/2010: I have just been looking through the proposals for future support of Parent/Child tickets in trac core (SubTickets) and want to point out that this plugin proved useful for my old dev team (and _old_ firm) but I've not tried to provide any kind of resolution for ticket:31 nor ticket:886. From one of the last comments on ticket:886 I see that itota has also recently published a very similar plugin, SubticketsPlugin. I plan to collect the features of this plugin and raise them as new issues/features for itota's SubticketsPlugin - it makes little sense to have more than one plugin doing the same job (and I quite like itota's simpler child-ticket list in the parent ticket.)
Some time ago I came across the problem of how to manage child tickets in a meaningful fashion, we were using coderanger's original 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.
Having child-tickets is extremely useful when it comes to managing multiple releases (ie. 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.
This plugin modifies the ticket description box and adds a child ticket listing table and a 'create' button for adding new child tickets. It has the following features:
It is possible to control in trac.ini the following aspects of child-ticket creation/viewing:
- allow/disallow child-tickets for a certain type of ticket
- to define the table headers displayed in the parent ticket
- to define a default for the child type to be created
- to restrict the type of child-ticket
- to define whether the parent milestone is adopted by child tickets or not
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. I have not tried it with 0.12 yet.
In order to keep the plugin as compact and simple as possible and to allow future compatibility with different CSS schemes, I have simply 'pinched' the existing CSS classes for generating the table and its components.
The plugin makes use of the 'ticket-custom' field and so requires no extra db tables to be created. The following fields are required in the 'trac.ini' (see table below for a generic description of the options):
[components] childtickets.* = enabled childtickets.childtickets.tracchildticketsmodule = enabled [ticket-custom] parent = text parent.format = wiki parent.label = Parent ID [childtickets] # 'enhancements' : child tickets will typically be bug-fix tickets with the same milestone. parent.enhancement.allow_child_tickets = true parent.enhancement.table_headers = type, status, owner, summary parent.enhancement.default_child_type = bug-fix parent.enhancement.restrict_child_type = bug-fix, task parent.enhancement.inherit_milestone = true # 'bug-report' : child tickets will typically be bug-fix parent.bug-report.allow_child_tickets = true parent.bug-report.default_child_type = bug-fix parent.bug-report.table_headers = type, priority, owner, summary, milestone parent.bug-report.inherit_milestone = false # 'issue' : child tickets will typically be task tickets with no default milestone. parent.issue.allow_child_tickets = true parent.issue.default_child_type = task parent.issue.table_headers = type, status, owner, summary, milestone parent.issue.inherit_milestone = false # 'bug-fix' : child tickets are not allowed. parent.bug-fix.allow_child_tickets = false # 'task' : child tickets are not allowed. parent.task.allow_child_tickets = false
|parent.<type>.allow_child_tickets||Define whether child tickets are allowed or not|
|parent.<type>.table_headers||List of column headers for display in parent ticket|
|parent.<type>.default_child_type||Default child type|
|parent.<type>.restrict_child_type||A list of possible child types, trying to create a child of a different 'type' will create an error.|
|parent.<type>.inherit_milestone||Define whether the child will adopt the parent ticket's milestone|
If you have any issues, create a new ticket.
Download the zipped source from [download:childticketsplugin here].
Handling multiple bug-fixes for single bug-report
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 ...
Handling sub-tasks from a single issue
Probably self explanatory: you have something that needs to be done by several different people. Split it up into sub-tasks.
A New Feature generates bugs
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!
- 15128 by rjollos on 2015-12-19 23:57:49
2.5.4dev: Refactor database queries
- 15100 by rjollos on 2015-12-07 03:58:46
2.5.4dev: Cleanup whitespace
- 15066 by rjollos on 2015-11-19 04:48:51
2.5.4dev: Revise installation requirements
Enforce Trac >= 1.0. Genshi and Python version is enforced
- bug-report-example.jpg (45.7 KB) - added by walnut 6 years ago.
- issue-example.jpg (34.3 KB) - added by walnut 6 years ago.
- MultipleChildType.png (7.1 KB) - added by walnut 5 years ago.
(27.4 KB) -
added by walnut 5 years ago.
The ProgressMeterMacro also provides some nice features
- NewChildTicketTable.png (40.1 KB) - added by walnut 5 years ago.
Download all attachments as: .zip