BEP 6 : Ticket Relations
- BEP 6 : Ticket Relations
- Reference Implementation
One of the deficiencies in the ticket handling workflow is the lack of any kind of ticket relations. Although referencing other tickets is possible in the fields that support WikiFormatting (e.g. comments), this is far from ideal. In order to fully support advanced ticket handling workflows, implementation of first-class ticket relations is vital.
Most, if not all competing issue tracking products provide at least one type of ticket relations. Attracting a wider audience in terms of both customers and developers may prove even more difficult without such functionality. There are several Trac plugins available which implement ticket relations to some extent, however without support for multiple relation types.
Ticket relations can be implemented either as a Bloodhound addon, or as a Trac plugin. The latter may be the preferred choice, as Trac users could also benefit from this feature.
This has also been discussed to some extent on the bloodhound-dev mailing list, Ryan proposed merging two existing Trac plugins (MasterTicketsPlugin and SubticketsPlugin) into one, and continuing from there.
Ticket relations are defined by source ticket, target ticket and relation type. Source and target tickets can belong to different products. The following relation types shall be implemented by default:
- indicates the defect was already reported in another ticket. This type should be bound to the "duplicate" ticket state. When a ticket is resolved as duplicate, users should be required to enter the ID of the original ticket.
- allows for splitting "larger" tickets into sub-tickets for more fine-grained control. This is especially useful for the "task" type tickets. Multiple levels of hierarchy should be supported.
- a ticket cannot be resolved until all of its dependencies have been resolved.
- an association between tickets that imposes no constraints.
Additionally it should be possible to define custom relation types with no semantic meaning through the admin interface.
Ticket Relations with Regards to Other New Features
In addition to relations within one product, this feature will allow referencing tickets from other products as well. This will enable easier tracking of closely related products, e.g. a Bloodhound ticket could be marked as dependent on a Trac ticket, or vice-versa.
If relationships are designed in terms of resources then resource neighborhoods proposal might be the foundations to link resources (e.g. tickets) to other resources managed by external systems . This is similar to Trac Relations but with neighborhood realm and ID added in resource_main and resource_dest).
Improved Search Architecture (BEP-0004)
The new search functionality should also allow searching for ticket relations. This will enable users to quickly find dependencies, duplicates, sub-tasks etc. Search should also be inter-product, i.e. able to find related tickets from other products.
Ticket relations will be displayed in the ticket view, below the ticket properties as depicted in the image below. The ticket view will also allow for removal of relations, one at a time, by clicking on the remove icons.
Each ticket can have multiple relations to other tickets, and those relations can be of different types. There are however certain constraints that should enforced by implementation:
- A ticket with parent/child relationships cannot relate to its ancestors or descendants with another relation type (i.e. a parent cannot be marked as a duplicate/blocker of its children or vice-versa).
- Parent/child relationships should be "one-way" (i.e. tree hierarchy, not a graph with backward relationships).
- Parent/child relationships cannot reference multiple products.
- A ticket cannot be marked as a duplicate of a ticket from a different product.
- A ticket cannot be marked as a duplicate of a newer ticket (only vice-versa).
- A ticket cannot be marked as a blocker of another ticket, if this creates a blocker cycle.
- A parent ticket cannot be closed until all of it's children are closed.
- A dependency (blocked) ticket cannot be closed until it's blocker is closed.
Some usage scenarios may need additional/special handling:
- What to do if a duplicate is reopened, i.e. it turns out it wasn't a duplicate after all? Should the duplicate relation be removed (and user informed beforehand)?
- Should parent/child relations be allowed only for tasks and possibly enhancements? Does it make sense for defects to be split in this manner?
In general there are no compatibility issues with previous versions, except for the duplicate relations. Currently duplicate tickets are only marked as such, with no indication of which ticket is the original in question. Since the duplicate ID will become required, existing tickets will either need to be upgraded somehow, or left as they are and handled in a special manner.
Source code management is powered by Apache™ Subversion.
UI mockups were made using Balsamiq Web Demo http://builds.balsamiq.com/b/mockups-web-demo/
$ svn co https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/bloodhound_relations
Bloodhound Relations plugin ticket summaryMore
- Trac Relations - document proposes generic relations between a Trac resource. There is no reference implementation.
- TicketLinks - ticket oriented solution with support of pluggable relations e.g. depend on, parent-child, one-way relation etc. There is reference implementation on trac branch that was never merged into trunk. Find more on implementation on wiki:TicketLinks. Related source repositories:
- trachacks:MasterTicketsPlugin - currently, only "blocked by/blocks" relation is supported. There are plans to include parent/child ticket functionality.
- trachacks:ChildTicketsPlugin / trachacks:ChildTicketTreeMacro
Apache Bloodhound, Apache, the Apache feather logo, and the Apache Bloodhound project logo are trademarks of The Apache Software Foundation.