relationships between issues integrated with the status field

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
dww's picture

there's are a few issues in the project module's queue (http://drupal.org/node/44162 and some duplicates), about how to link different issues together and record relationships between issues. so far, we've been talking about issues from the project module, but the ideas are generally applicable. i thought people interested in the issue tracking and relationships groups might have ideas. a few potential use cases:

1) recording the duplicate issue id so that a) we can automatically add a comment to the "parent" issue that another duplicate was just created (which bumps the issue's access time, since effectively the duplicate means another instance of the issue was just noticed), b) we could have a block of links in the parent that showed all the duplicates, and c) we have a consistent way to display the parent issue inside the child...

2) adding a "blocked" status to indicate that some other issue must be resolved before progress can be made on this one. ideally, the child (blocked) issue would automatically move from blocked to active once the parent was either closed or fixed.

3) keeping track of issue relationships more generally. maybe 2 issues are related to each other, but neither one is really a dupllicate of the other, and neither is blocked on the other. of course, you can just record that fact via a URL in each one pointing to the other, but if there was a more structured approach, we could do cool views of issues to see how they relate to each other, etc.

let's discuss how this could/should work in general (not specific to any particular drupal-based issue tracking system) and see which of the existing implementations and prototypes floating around lend themselves to solving this problem more easily. not that it's a competition, but i bet the CCK-esque ones will be able to do this most gracefully, and project will have the most trouble. ;) but, that aside...

any other use cases folks can come up with?
how should the UI look/work?
what underlying relationship technology could/should we use for this in 4.7 modules? in 4.8?

thanks!
-derek

Comments

Very happy with Mantis

Sara Adams's picture

Talking abut UI - I'm very happy with the way Mantis (http://www.mantisbt.org/) works.

Although the issues are in German, you can see how things might be displayed:

http://bugs.conquer-space.net/view_all_bug_page.php is an overview
http://bugs.conquer-space.net/view.php?id=761 is a duplicate
http://bugs.conquer-space.net/view.php?id=720 has a related issue

How are relationships added there?

If you have the rights, there's always something displayed which looks kind of like this:
New relationship: Current issue (dropdown) (text input) [Add]
dropdown has the choices:
"related to", "child of", "parent of", "has duplicate", "duplicate of"
In the text input you insert the id of the other issue.

Relationships only have to be entered for one of the two issues. Example:
Say Issue 1 is a duplicate of Issue 2.
Then in Issue 1 I might add "duplicate of 2". Then automaticly the relationship "has duplicate 1" is added to Issue 2. Similarly, if I delete the relationship from Issue 1, it will also be deleted from Issue 2.

(Note that if I add "related to" to issue 1 and issue 2 and then add "related to" to issue 1 and issue 3, then issue 2 and issue 3 are not automaticly going to be related. This makes sense, but might be a question you ask yourself when reading the above. Basicly - you always enter one side of a 2-item relationship and the second side is done for you - but nothing else.)

Something I also quite frequently use:
When resolving an issue I can give a few reasons, one of which is "duplicate". Again there's a text field where I can enter the id of the other issue and relationships are added accordingly.

How are relationships displayed?

Now when I view an issue, there's also a list of related issues. Each list item tells you
- what the relationship is
- a link to the other issue
- the status of the other issue
- whom it is assigned to and
- what the title is.
Also, the background of the item is color encoded according to the status.

I think it's a very intuitive way of dealing it and it might be a good idea to do something similar to it. It would definately be a step to getting rid of mantis and using drupal for the bugtracker, too.

Hoping this description makes sense,

-- Sara

P.S. I also really like that there's a history displayed which shows what happened when and which user did the changes. But that might be a different story altogether.

JIRA handles this pretty nicely, too

dww's picture

i just looked at http://www.atlassian.com/software/jira. that seems to handle this idea pretty well, too. more food for thought...

relationships

anarcat's picture

I think the way this should work is indeed like Mantis or RT: we have a generic "relationship" mechanism with various "types" of relationships. I would implement the following distinct relationships:

  • "duplicate" (UI: duplicate of)
  • "block" (UI: blocking/blocked by)
  • "parent" (UI: parent, children)
  • "refers" (UI: refers to, refered to by)

All would be manually assigned, but the last one could be automatically adjusted when issues are mentionned in the comments of the page. Of all those, I think "duplicate" and "block" are the most important. Block, particularly, will allow building "milestone" issues to keep track of larger goals in a project (which is a bit difficult right now, although it's possible to do it with tags).

Those settings should be part of the regular comment form.

Relationships & site structuring

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: