bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <>
Subject Proposal: Ticket relations
Date Thu, 15 Nov 2012 11:09:22 GMT
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
  - 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
   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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message