On Thu, Nov 15, 2012 at 3:09 AM, Peter Koželj <[email protected]> wrote:
> While we are already in new-fetures-discussion mode I would like to kick of > another one about ticket relations. > Here is my take on the subject: > > Although links are already possible through wiki formatting they feels like > an afterthought and most importantly does not enable us to make a first > class functionality on top of that. We need first class relations with > following capabilities: > 1. Relation is defined by source ticket, target ticket and relation type. > Source and traget ticket can belong to different products. > 2. Provide build in relation types with well defined semantics: > - Duplicate > This should be bound with ticket state/resolution in some way. BH > should require the user to eneter the duplicate ticket when resolving as > such. > - Parent/child (multiple levels should be supported) > - Blocks/depends > Ticket should no be resolvable until all the tickets that it depend on > are resolved > 3. User can define additional types with no semantic meaning through admin > interface > There is probably no need to make this product specific > 4. On UI ticket page would get a generic "Relations" section where user can > view and manage existing relations or add new ones. > This would work for build in and user defines types alike > 5. Special support for build in types can be added over time: > - duplicate tickets marked specially in search result and reports > - parent/child relations can be presented as a expand button that would > display entire tree, blocks/depends could follow the same steps > 6. Query language will have to be extended so that relations can be used > for searching. > Actually the query language is due for some overhaul (out of scope for this > discussion), this might better be added through that effort. I have done some work to bring the MasterTicketsPlugin (1) up to par and merge the feature base with the SubticketsPlugin (2), in order to provide a plugin that could serve as a starting point for Ticket relations in Bloodhound. I will get the rest of that work committed to the repository within the next few days and we can see if it will serve as a suitable starting point for implementing the other features suggested here. (1) https://trac-hacks.org/wiki/MasterTicketsPlugin (2) http://trac-hacks.org/wiki/SubticketsPlugin
