Closed Bug 12286 Opened 21 years ago Closed 11 years ago

Implement "Related bugs" feature ("See Also")

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement, P2)

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: CodeMachine, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [relations:other] [wanted-bmo])

Attachments

(1 file, 4 obsolete files)

Related to the idea of dependent bugs would be "related" bugs, bugs that
someone reading this bug might be interested in, but that are not dependent.  Of
course this relationship would need to be a little stronger than a similar
component.

For example, bug #9307 asks for the ability for window.open in JS to fail.  A
natural extension is to prevent this for certain sites - this is bug #7380.
Neither is dependent on one another, they are quite orthogonal, but there is a
distinct relationship, such that someone interested in one may be in the other.

I believe this should be a symmetric relationship - this means you only need one
field rather than two for dependencies.
I like this idea...
Yes, the more I think about it, the more situations I see where this is useful.

You would probably also want to extend the dependency tree to become a
relationship tree that also show the bugs related to that.  Or would you want to
show bugs related to dependent bugs and vice versa?
Status: NEW → ASSIGNED
Priority: P3 → P2
tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
*** Bug 42800 has been marked as a duplicate of this bug. ***
For people who can't wait for this feature to be included in bugzilla, try the 
bookmarklet at http://www.cs.hmc.edu/~jruderma/mozilla/buglinks.html.
> For people who can't wait for this feature to be included
> in bugzilla, try the 
> bookmarklet at http://www.cs.hmc.edu/~jruderma/mozilla/buglinks.html.

Wow! That's really great! I tried it on bug #2800 :), and it worked perfectly 
(well, I found one small bug; it shouldn't included the bug it was run from in 
the query (#2800)).
> it shouldn't include the bug it was run from in the query (#2800).

good idea.  fixed :)
Whiteboard: 3.2
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.
QA Contact: matty
moving to real milestones...
Whiteboard: 3.2
Target Milestone: --- → Bugzilla 3.2
to the bugzilla 3 component.
Component: Bugzilla → Bugzilla 3
The Bugzilla 3 component is going away.  We're going to depend on the Milestones 
for this.  At the time this component was created, we didn't have milestones for 
Bugzilla.
Component: Bugzilla 3 → Bugzilla
Heavily voted enhancement, target for 2.16.
Priority: P2 → P3
Target Milestone: Bugzilla 3.2 → Bugzilla 2.16
Moving to new Bugzilla product ...
Assignee: tara → justdave
Status: ASSIGNED → NEW
Really moving ...
Assignee: justdave → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → unspecified
Whiteboard: [relations:other]
really like this idea, would be so helpful.
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
*** Bug 154655 has been marked as a duplicate of this bug. ***
*** Bug 173462 has been marked as a duplicate of this bug. ***
I got just dupes (stupid me). Here is what I suggested:

---cut---
We have fields for bug dependencies. But often there are other bugs somehow
related or similar, but no strictly depending. Those are mentioned in the
comments, which means this is possibly hard to find for long bugs.

So I suggest to add a field "also see bugs" next to the dependency fields. It
should work as those two fields, but not alert the bugs mentioned there (to
avoid spamming, futhermore, this relationship may not be symmetric).
---cut---

So the difference is that I don't think this needs to be symmetric.

This would also enable "private tracking bugs". I have just seen someone doing
it with dependencies. He stopped pretty soon because of the spam effect;-)

pi
*** Bug 198124 has been marked as a duplicate of this bug. ***
I also love to see  this feature implemented. 

As for comment #19, how about adding two new button/links
for bugs that refer to/cite this bug and bugs that are cited/referred
to by this bug? 'Citing and being cited by' are not symmetric so that
we need two buttons. Clicking on either of them will bring up a list
of bugs similar to what one gest as a query result. Basically,
this is a cusomized query short-cut per bug.  I guess to
reduce the query time, bugzilla DB internally has to keep(or
at least cache) two lists for each bug.  

Back to 'related bug', I think it's symmetric so that we just
need one field. 
See also bug 188815

A related bugs feature would make this statement unecessary.
I agree with comment 21.

More on comment 19, and based on bug 172537 comment 12, in cases where there
would be a need for active tracking, then a meta bug could be created and used.
My suggested requirements ( in the hope that my ideas fit a common need ):
The Problem: when you have several branches of code off the same trunk, all 
supported and/or in development, a bug will appear in multiple branches. Each 
branch requires differing fixes and timing for the same bug. Multiple 
developers may be used, as well. Simply creating multiple bug reports creates a 
tracking mechanism, but is inefficient, and awkward for users.

The Goal: a bug report should have the concept of related ( sibling) bug 
reports. (Not dependencies) The relatedness of bug-reports should be 
highlighted for the user, not lost in the system. It should be possible to 
create a bug report and copy it to other versions/products/components/platforms 
multiple times. Each copy should have all the functions of a normal bug-report, 
once created. (assume each has a unique lifecycle) Queries and reports on any 
of the cloned or original bugs should (optionally?) retrieve all in some way 
(listbox?). Some positive reminder should appear with queries and show-bugs 
that presents the information that there are other sibling bugs to be dealt 
with.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
*** Bug 260492 has been marked as a duplicate of this bug. ***
I think that this is a good idea, and I just wanted to also suggest that this
feature not be transitive; i.e. if bug 1 is related to bug 2 which is related to
bug 3, bug 1 should not be related to bug 3. This would make having symmetrical
relatedness a lot more meaningful, I think.
Blocks: majorbugs
(In reply to comment #6)
> > For people who can't wait for this feature to be included
> > in bugzilla, try the 
> > bookmarklet at http://www.cs.hmc.edu/~jruderma/mozilla/buglinks.html.
> 
> Wow! That's really great! I tried it on bug #2800 :), and it worked perfectly 
> (well, I found one small bug; it shouldn't included the bug it was run from in 
> the query (#2800)).

This tool has moved to http://www.squarefree.com/bookmarklets/mozilla.html
No longer blocks: majorbugs
Attached patch initial patch (obsolete) — Splinter Review
I took a stab at creating a simplified version, similar to what the javascript
did.  Patch based on the main 2.19 stream but with minor tweaks it should
easily work in 2.18.  

Key things:
    - it auto generates the related bugs by scanning the comments
    - will only display related bugs if some exists
    - it's not optional (I didn't bother to add a bugzilla parameter, yet...)
    - provides a "show related bugs as list" link.

Downsides:
    - Yes, it might be nice to have an input field to add more related bugs.
      But you might as well just add a comment explaining why it's related.  
    - You can't remove a related bug (unless you delete the comment).  

But hey, it's a simple solution!
Attached patch advanced patch (obsolete) — Splinter Review
Thought about this some more and concluded having an input field would be
useful.  This updated patch now offers the following:

   - new admin parameter, userelatedbugs.  Choice of 4 settings:
     automatic	 - essentially the original patch, where bugzilla automatically

		   scans for all bug numbers in the comment section
     userdefined - support an input field, similar to bug dependencies
     both	 - display both automatic and usedefined related bugs
     none	 - none of the above
Attached patch advanced patch, v2 (obsolete) — Splinter Review
Updated patch.	Added sanitycheck support.
Attachment #187688 - Attachment is obsolete: true
Comment on attachment 188321 [details] [diff] [review]
advanced patch, v2

I'm aware that this will need to be updated to the tip.  But would like to get
an idea if I'm on the right track and hope to fix it for the 2.22 release.
Attachment #188321 - Flags: review?(LpSolit)
(In reply to comment #30)
>    - new admin parameter, userelatedbugs.  Choice of 4 settings:

I think we should treat the "related bugs" field as we do for the status
whiteboard, for instance, i.e. 'use_related_bugs' should be a boolean and when
turned on, it should be an input field only, i.e. with no automatic detection.
The reason is that automatic detection is based on a regexp, and this is hardly
compatible with customised terms such as [% terms.bug %]. And I don't think we
want all bugs mentioned in comments to be added to this field, as some of them
should/could go into the dependency fields.
Albert Ting, ping? No reply to my last comment?
(In reply to comment #34)
> Albert Ting, ping? No reply to my last comment?

Sorry, been out of town this past week.  Also thought some other folks might
pipe in.

> I think we should treat the "related bugs" field as we do for the status
> whiteboard, for instance, i.e. 'use_related_bugs' should be a boolean and
> when turned on, it should be an input field only, i.e. with no automatic
> detection.  

I disagree.  I think automatic is useful, especially for a bugzilla system
that's been around for a while.  Granted, one may get some false positives,
but it's pretty benign.   Plus, you can turn off the automatic detection
and just have "userdefined".

> The reason is that automatic detection is based on a regexp, and this is
> hardly compatible with customised terms such as [% terms.bug ].

I can update the patch to take into account terms.bug.

> And I don't think we want all bugs mentioned in comments to be added to
> this field, as some of them should/could go into the dependency fields.

True.  But I think "related bugs" should be a superset of "dependent
bugs".  Still, one can turn off automatic detection if people don't
want that. 
Albert, could we split the patch into two distinct parts, one implementing this
"related bugs" field where bugs can be manually entered (the part I'm
interesting in and which I agree to review) and later a second part implementing
some automatic process to fill this field (the part I disagree per my comment 33
and which I won't review anyway). This is the reason I haven't reviewed your
patch yet.
Comment on attachment 188321 [details] [diff] [review]
advanced patch, v2

r- per my previous comment + the fact that defparams.pl and CGI.pl no longer exist on tip.
Attachment #188321 - Flags: review?(LpSolit) → review-
The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.24
Attached patch v3, based on the 2.22 tip (obsolete) — Splinter Review
I know this is late, but got tied with my real job... :)

In any case, I've finally updated my development environment to the 2.22 tip, updated the patch, and removed the automatic feature.
Attachment #203468 - Flags: review?(LpSolit)
Assignee: myk → altlst
Comment on attachment 203468 [details] [diff] [review]
v3, based on the 2.22 tip

>+++ checksetup.pl	2005-06-28 20:13:47.000000000 -0700

>+AddFDef("related", "RelatedBugs", 1);

Write "Related bugs".



>+++ process_bug.cgi	2005-06-28 20:36:05.000000000 -0700

>-sub SnapShotDeps {
>-    my ($i, $target, $me) = (@_);
>-    SendSQL("SELECT $target FROM dependencies WHERE $me = $i ORDER BY $target");
>+sub SnapShotBugList {
>+    my ($table, $i, $target, $me) = (@_);
>+    SendSQL("SELECT $target FROM $table WHERE $me = $i ORDER BY $target");

I disagree with this change. If bugA blocks bugB, then bugB depends on bugA (there is some "hierarchy"). But if bugA is related to bugB, then bugB is also related to bugA and so they are both at the same "level". So you should write a distinct routine for related bugs.


>+    my @related;
>+    if (defined $cgi->param('related')) {
>+        foreach my $i (split('[\s,]+', $cgi->param('related'))) {

Please use split(/foo/, bar) instead of quotes.


>+            next if $i eq "";
>+            if ($i eq $id) {
>+                ThrowUserError("related_same_bug_id",
>+                               { id => $i });

The error message associated with this check makes no sense:
[% terms.Bug %] [%+ id FILTER html %] is already related to itself.

How could a bug be (already) related to itself?? I had to reread the message twice to understand what you meant. So please rewrite the error message in a better way (e.g. "a bug cannot be marked as related to itself").


>+            }
>+            push (@related, $i) if lsearch(\@related, $i) < 0;

For this kind of check, $related{$i} = 1; is more appropriate. The bug IDs are then easily accessible using "keys %related".


>+    if (defined $cgi->param('related')) {
>+        my $table = "relatedbugs";
>+        my $target = "related";
>+        my $me = "bug_id";
>+        my @oldlist = @{$dbh->selectcol_arrayref("SELECT related FROM $table
>+                                                  WHERE bug_id = ? ORDER BY related",
>+                                              undef, $id)};

As I said, there is no hierarchy among related bugs, so you have to query both columns.


>+                if ($oldlist[0] != $newlist[0]) {
>+                    $dbh->bz_unlock_tables(UNLOCK_ABORT);
>+                    die "Error in list comparing code";
>+                }

Please don't use die() but ThrowCodeError() which will automatically unlock tables and use a translatable error message (moreover die() has pseudo-security implications).


>+            SendSQL("delete from $table where $me = $id");
>+            foreach my $i (@related) {
>+                SendSQL("insert into $table ($me, $target) values ($id, $i)");

SQL keywords have to be uppercase (INSERT INTO, VALUES, DELETE, FROM, WHERE). Moreover, SendSQL() is deprecated.



>+++ Bugzilla/Config/BugChange.pm	2005-11-16 18:34:34.000000000 -0800
>   {
>+   name    => 'userelatedbugs',
>+   type    => 's',
>+   choices => ['userdefined', 'none'],
>+   default => 'none',
>+   checker => \&check_multi
>+  },

This parameter has nothing to do here. It should go in BugFields.pm.
Moreover, please write use_related_bugs.



>+++ template/en/default/admin/params/bugchange.html.tmpl	2005-11-16 18:35:53.000000000 -0800

>+  userelatedbugs => "Do you wish to support related bugs?  You can choose to " _
>+                    "let the user define the list or not. ",

This parameter description must go in bugfields.html.tmpl. And a better explanation would be helpful.



>+++ Bugzilla/DB/Schema.pm	2005-06-28 19:52:30.000000000 -0700

>+    relatedbugs => {
>+        FIELDS => [
>+            bug_id   => {TYPE => 'INT3', NOTNULL => 1},
>+            related  => {TYPE => 'INT3', NOTNULL => 1},
>+        ],
>+        INDEXES => [
>+            dependencies_related_idx   => {FIELDS => [qw(bug_id related)],
>+                                           TYPE => 'UNIQUE'},
>+        ],
>+    },

How do you handle the fact that there is no hierarchy among related bugs? What happens if I insert (bugA, bugB) and then (bugB, bugA)?
Moreover, the name of indexes has a well defined format: ${table_name}_foo_idx.
And finally, write "related_bugs" for the table name.



>+++ Bugzilla/Bug.pm	2005-11-17 16:46:04.000000000 -0800

>+sub related {
>+    my ($self) = @_;
>+    return $self->{'related'} if exists $self->{'related'};
>+    return [] if $self->{'error'};
>+    return [] if (Param("userelatedbugs") eq "none");
>+
>+    my @pre_related = ();

@pre_related is never used.


>+    my @related = ();
>+    my @definedrelated = ();
>+
>+    if (Param("userelatedbugs") eq "userdefined") {
>+        my $dbh = Bugzilla->dbh;
>+        my $sth = $dbh->prepare("SELECT related
>+                                 FROM relatedbugs
>+                                 WHERE bug_id=?
>+                                 ORDER BY related");

There is no hierarchy! So unless you insert (bugA, bugB) *and* (bugB, bugA) in post_bug.cgi and process_bug.cgi, or you query both columns here.


>+        $sth->execute($self->{bug_id});
>+        while (my $bug = $sth->fetchrow_array()) {

Use $dbh->selectcol_arrayref() instead.


>+            push (@related, $bug) if lsearch(\@related, $bug) < 0;

No need to check whether $bug is already inserted as the table doesn't accept duplicates.


>+    @related = sort {$a <=> $b} @related;

@related is already sorted (you added ORDER BY in the SQL query).


>+    $self->{'related'} = \@related;
>+    $self->{'definedrelated'} = \@definedrelated;

What's the difference between both???


>+sub definedrelated {
>+    my ($self) = @_;
>+    return $self->{'definedrelated'} if exists $self->{'definedrelated'};
>+    return [] if $self->{'error'};
>+
>+    $self->related();
>+    return [] if $self->{'definedrelated'};
>+}

I don't understand what this method is supposed to do. Both methods need POD anyway (or at least comments as Bug.pm has no POD yet).



>+++ template/en/default/bug/edit.html.tmpl	2005-06-28 19:36:20.000000000 -0700

>+    [% IF (Param("userelatedbugs") == "userdefined") %]

Parens are useless.


>+          [% FOREACH relbug = bug.related %]
>+            [% relbug FILTER bug_link(relbug) %][% " " %]
>+          [% END %]

./runtests.pl fails due to unfiltered fields.

not ok 143 - (en/default) template/en/default/bug/edit.html.tmpl has unfiltered directives:
#   534: relbug FILTER bug_link(relbug)
#   538: bug.definedrelated.join(', ')
#   542: bug.related.join(",")
# --ERROR



>+++ template/en/default/global/user-error.html.tmpl	2005-06-28 20:37:36.000000000 -0700

>+  [% ELSIF error == "related_same_bug_id" %]
>+    [% title = "Already related" %]
>+    [% terms.Bug %] [%+ id FILTER html %] is already related to itself.

As I said above, please write a better error message.



>+++ sanitycheck.cgi	2005-06-29 12:17:36.000000000 -0700

>     foreach my $pair ('attachments/', 'bug_group_map/', 'bugs_activity/', 'cc/',
>                       'dependencies/blocked', 'dependencies/dependson',
>-                      'duplicates/dupe', 'duplicates/dupe_of',
>+                      'duplicates/dupe', 'duplicates/dupe_of', 'relatedbugs/related',
>                       'flags/', 'keywords/', 'longdescs/', 'votes/') {

You have to check both columns of the table.


>            ["dependencies", "blocked"],
>            ["dependencies", "dependson"],
>+           ["relatedbugs", "related"],

Here also, you have to check both columns.
Attachment #203468 - Flags: review?(LpSolit) → review-
(In reply to comment #40)
Thanks for the review.  I'll clean up the various pointers you had mentioned.  But before I do that, I see a fundamental difference in what "related" means.

My implmenetation says that if A is related to B, it does not mean B is related to A.  That is, I was not making them symmetrical.  This is why a lot of the code reused the existing bug-dependency routines.

We've been using this solution for a while now and it seems to work pretty well.  But if the majority feel it is better that it be symmetrical, I'll do that. 
Status: NEW → ASSIGNED
I'll vote that the relation should be symmetrical.  If you're feeling adventurous, you could make a preference to control it.  :)
(In reply to comment #42)
> I'll vote that the relation should be symmetrical.  If you're feeling
> adventurous, you could make a preference to control it.  :)
> 

I don't think we want a control for that. Asymmetry would lead to a new system of blockers/bugs depending on others. For me, this kind of relationship is close to equality, and as far as I know, A == B <=> B == A.
Current decision by Frederic and Dave is to make them not only symmetrical but linked.  That is, if A is related to B and B is related to C, then A is related to C.  All three bugs would show the other two in the related field.  That is, rather than "related bugs", we are defining "related groups".  This simplifies how the database schema should look like.

There are still questions what happens when you join related groups, especially if you want to undo and/or split a group.  Also unclear is how to address BugActivity logs. 
I'm wondering whether it might be a good idea to make it so that assymetric relations are possible, too. We might be able to replace the "duplicate" resolution by a duped/dupe relationship pair, which could be used to rid us of the awkwardness of open duplicate bugs being undistinguishable from closed ones...
I don't think this feature should be transitive.
I agree with comment 42 and comment 43. This feature shouldn't be symmetric, nor transitive, nor reflexive.

(In reply to comment #44)
> Current decision by Frederic and Dave is to make them not only symmetrical but
> linked ... This simplifies how the database schema should look like.

How is that a valid argument? It would be even more simple to just not implement this feature at all... and AFAIAC, it's better to wait for a good 'related to' scheme than to have the baggage of a clearly lacking one.
(In reply to comment #47)
> I agree with comment 42 and comment 43. This feature shouldn't be symmetric,
> nor transitive, nor reflexive.

So you don't agree. :)


(In reply to comment #46)
> I don't think this feature should be transitive.

Jesse, why not? Also, how do you imagine the DB structure in this case?


justdave's suggestion and mine was that related bugs should be grouped together, involving "related groups" as Albert said in comment 41. I'm definitely against an asymmetric relation, for the reasons I give in comment 43.
The reason I want this feature is that I find myself making lots of comments of the form "see also bug XXX" in our bugzilla.  Every time I do that (when I'm being a good bugzilla-citizen, anyway) I also make a "see also bug YYY" comment on bug XXX.  So that's why I think this feature should be symmetric.

I think the analogy with equality (comment 43) is a bit specious.  I think of duplicate bugs as being more akin to equality -- i.e. having two bugs that represent the exact same conceptual defect or feature request.  I think of the "related bugs" feature as bugs that are *not* about the same conceptual defect or feature request.  Rather, their fixes might interact in interesting ways, they might represent fixing the same defect on different branches in CVS, etc.

Given the above, I don't think this feature should be transitive, because I can certainly imagine that bug X's fix interacts with part of bug Y's fix, while another part of bug Y's fix interacts with bug Z -- but no parts of bug X's and bug Z's fixes interact with each other.
(In reply to comment #49)
> The reason I want this feature is that I find myself making lots of comments of
> the form "see also bug XXX" in our bugzilla.  Every time I do that (when I'm
> being a good bugzilla-citizen, anyway) I also make a "see also bug YYY" comment
> on bug XXX.  So that's why I think this feature should be symmetric.

Uh, no, that's why you think this feature should not be anti-symmetric:

http://en.wikipedia.org/wiki/Antisymmetric_relation

Now, no one is suggesting that it be anti-symmetric, so you can have the situation you want (X related to Y and Y related to X), while we can have the situation we want (e.g. X related to Y but Y not related to X).


> I think the analogy with equality (comment 43) is a bit specious. 

Still, it is possible that the fix for one bug will affect another, while the opposite is not true.

As for the DB structure - I'm no DB expert, but if one of the fields of a bug can be a set of references to another bug, I don't see the problem of not having symmetry or transitivity.
(In reply to comment #49)
> I think the analogy with equality (comment 43) is a bit specious.  I think of
> duplicate bugs as being more akin to equality -- i.e. having two bugs that
> represent the exact same conceptual defect or feature request.  I think of the
> "related bugs" feature as bugs that are *not* about the same conceptual defect

Ok, I can see this.

Fully symmetric relations might be modeled like this:

 id_relation | id_bug
 --------------------
 4711        | 110815
 4711        | 110816
 4711        | 110817

In addition, we might have a table like this:

 id_relation | relation_type
 ---------------------------
 4711        | 1

... where there is a defined set of relation types (1-"generically related", 2-...)

I agree that this is orthogonal to an asymmetric relation like this:

 id_relation | id_bug_relating | id_bug_related
 ----------------------------------------------
 4712        | 110815          | 170601
 4712        | 110815          | 170602
 4712        | 110815          | 170603

...using the same relationship type table as above,

 id_relation | relation_type
 ---------------------------
 4712        | 17

...where "17" means "duplicate".

I do think, though, that there is a certain similarity between the two, and that they might share the relationship type table, perhaps. Making duplicate-ness a relationship would enable us to find duplicates when we find open bugs, and it would enable us to mirror state changes of the original bug so that dupes would changes their state along with it. I imagine this to help people searching and people having filed (or CC'ed to) dupes, too.

I'd like to stress that I do think it's not a good idea to mix up symmetric and asymmetric relations, even though you can fake symmetric relations by setting up two-way asymmetric relations.
Not sure this helps, but here is the discussion I had with justdave last week-end on IRC:

(19:56:41) justdave: bugs: A B C D E F
(19:56:48) justdave: bugs A B C are related to each other
(19:56:55) justdave: bugs D E F are related to each other.
(19:57:06) justdave: so ABC has rID 1
(19:57:09) justdave: DEF has rID 2
(19:57:15) justdave: someone visits bug C
(19:57:32) justdave: says "oh, this is related to bug D" and adds D to the related list.
(19:57:45) justdave: that now means A B C D E and F are all related now
(19:58:03) justdave: so to set that in the database, you would have to take everything in rID 2 and make it rID 1 instead
(19:58:10) LpSolit: right
(19:58:15) justdave: (or vice versa)
(19:58:45) ***justdave can imagine confusion
(19:58:55) justdave: "hey, I only added one bug to the list, how come there's 50 now?"
(19:58:56) LpSolit: hum... the nasty thing is that if you add D as related to C by mistake, you cannot reverse it
(19:59:07) justdave: yeah, exactly
(19:59:25) LpSolit: but that's what we want anyway (the "adding one but having 50 new ones added")
(19:59:31) justdave: although if we log it well enough in the bug activity, maybe we can provide an undo mechanism
(20:00:11) LpSolit: so the table would have the following structure: "bug_id, relation_id", right?
(20:00:18) justdave: yeah
(20:00:34) LpSolit: sounds good
(20:01:55) LpSolit: justdave: or should the relation list be per user?
(20:02:08) LpSolit: i.e., bug_id, relation_id, user_id?
(20:03:18) justdave: if relations are per user then we'd have our personal metabugs, too. :)
(20:03:27) LpSolit: right
(20:03:38) LpSolit: this would avoid all these useless meta bugs
(20:05:29) LpSolit: hum.. wait
(20:05:40) LpSolit: how do you define a meta bug? there is no hierarchy
(20:05:50) LpSolit: a meta bug would be a relation now
(20:05:57) LpSolit: relation = meta bug

That's what Albert was referring to in comment 44.
(In reply to comment #52)
> (20:05:40) LpSolit: how do you define a meta bug? there is no hierarchy
> (20:05:50) LpSolit: a meta bug would be a relation now

Well, first of all, we need to disambiguate "relation" in the mathematical sense from the specific "related-to" relation.

So it seems we need to have the fields bug_id, relation_bug_id, relation_id, user_id

for user-specific relations, and a separate table (?) bug_id, relation_bug_id, relation_id

for non-user-specific relations.
(In reply to comment #50)
> (In reply to comment #49)
> > The reason I want this feature is that I find myself making lots of comments of
> > the form "see also bug XXX" in our bugzilla.  Every time I do that (when I'm
> > being a good bugzilla-citizen, anyway) I also make a "see also bug YYY" comment
> > on bug XXX.  So that's why I think this feature should be symmetric.

> Now, no one is suggesting that it be anti-symmetric, so you can have the
> situation you want (X related to Y and Y related to X), while we can have the
> situation we want (e.g. X related to Y but Y not related to X).

Sorry, maybe I was a bit unclear.  The point of my parenthetical "good bugzilla-citizen" bit was this: whenever a user adds the "X related to Y" link, he ought to add the "Y related to X" link as well.  But relying on users to follow these kinds of guidelines is bad -- instead, the system should do it for them.

It seems to me that the easiest way to do this is simply to make the relation symmetric.  But I guess another way to go would be to implement asymmetric relations, and then introduce a parameter ("automatically-create-inverse-relations") that does exactly what it sounds like it would.
(In reply to comment #54)
> whenever a user adds the "X related to Y" link, he ought to add the "Y related 
> to X" link as well.  But relying on users to follow these kinds of guidelines 
> is bad -- instead, the system should do it for them.

Looks like good idea to me, this way history of relations will be kept in both bugs.

I also support the idea of having relations symmetric (this could be option), but not transitive! (if you decide for transitive, please make possibility to turn it off).
I'm also user of other BTS with transitive relations, and eventually bugs ends with dozens of "related" bugs, which are not really related. 
Also possibility to see related bugs structure (similar to dependency tree/graph) would be nice (as per comment #2).
(In reply to comment #55)
> Looks like good idea to me, this way history of relations will be kept in both
> bugs.

You're only thinking about the use-cases you're interested in, not the ones other people may be thinking of.
This entire feature actually falls under "Multiple-entry bug number fields" as part of Custom Fields. I doubt we would accept it in any other fashion.

If there isn't already a bug for that, feel free to file one.
(In reply to comment #57)
> This entire feature actually falls under "Multiple-entry bug number fields" as
> part of Custom Fields. I doubt we would accept it in any other fashion.
> 
> If there isn't already a bug for that, feel free to file one.
> 

What you are saying is that we won't accept any new field which doesn't already exist? I strongly disagree with that.
(In reply to comment #58)
> What you are saying is that we won't accept any new field which doesn't already
> exist? I strongly disagree with that.

  No, I'm saying that this would be more valuable as the *ability* to have a field *like* this, rather than just having this field.

  Also, with all the disagreements on how it should work, we could have fields like this have different options, and people could set up the field locally to work the way they want it to.

  We could ship with one field like this by default, and that would accomplish "related bugs."
*** Bug 332541 has been marked as a duplicate of this bug. ***
IMHO, I prefer supporting symmetric and asymmetric related bugs, or perhaps only symmetric bugs.  Something simple!  I'm also pretty happy with the current patch (minus the automated related-bug code), as it just extends the existing bug dependencies code.

Still, we are kind of stuck until there is a quorum in what this ticket should really support.  
Assignee: altlst → nobody
Status: ASSIGNED → NEW
*** Bug 341461 has been marked as a duplicate of this bug. ***
there are at least 4 types of relationships where it would probably make sense to natively support them by default, as they could provide very useful meta information concerning the feasibility of implementing proposed feature requests:

"depends on/requires ..."    
"excludes/conflicts with ..."
"simplifies ..."
"complicates ..."

QA Contact: mattyt-bugzilla → default-qa
Keywords: dogfood
Whiteboard: [relations:other] → [relations:other] [wanted-bmo]
This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
*** Bug 363065 has been marked as a duplicate of this bug. ***
I'd really like to see this bug implemented!  We really have a need for it in our installation.
I took a stab at coming up with a more general solution.  This latest patch does the following:

     - supports both symmetrical and asymmetrical connections (via a param)
     - abstracted the bug dependency code to support related dependencies 
     - does not yet update the database when switching from asymmetrical to 
       symmetrical (probably have to add a 
       Bugzilla::Config::Common::check_related function) 
     - limited sanity checking (doesn't clean up symmetrical links).

I myself was only interested in asymmetrical links, but it was straightforward to add symmetrical support.  It would be great if we could at least see an agreement on the approach, and then clean up the code if need be.

Thanks,
Albert
Attachment #187459 - Attachment is obsolete: true
Attachment #188321 - Attachment is obsolete: true
Attachment #203468 - Attachment is obsolete: true
Attachment #250245 - Flags: review?(LpSolit)
Mmmmm, why a search on bmo with the word "related" doesn't include this bug, but includes other dupes of this? Seems like another bug... (sorry for bugspam).
Comment on attachment 250245 [details] [diff] [review]
v4, based on 12/26/06 tip

I'm surprised by the very low numbers of conflicts with current code:

patching file process_bug.cgi
Hunk #1 FAILED at 188.

patching file Bugzilla/Bug.pm
Hunk #2 FAILED at 696.
Hunk #3 FAILED at 919.

Anyway, I'm changing my mind a bit compared to comment 58 I made 14 months ago: this feature should really be implemented as a custom field. This would better match what we do currently and (I hope) will avoid making functions even more complex. I don't really like adding new parameters for each new field.

Also, we should be sure that the DB table is still correctly readable when going from symmetrical to asymmetrical.
Attachment #250245 - Flags: review?(LpSolit) → review-
Making this a custom field would require generalizing the dependency related features (symmetrical and asymmetrical).  In fact, we would want to first convert depends/dependson into custom fields.
(In reply to comment #70)
> Making this a custom field would require generalizing the dependency related
> features (symmetrical and asymmetrical).  In fact, we would want to first
> convert depends/dependson into custom fields.

  That would be fine. I don't think it would require that--we thought that for the other custom fields, and it turned out to not be the case. But we'd be happy to genercize current fields in Bugzilla so people who don't need them can disable them.
Recent discussions and other researches have caused me to decide that we definitely want this, and it should be in 4.0.
Priority: P3 → P2
Summary: "Related bugs" feature. → "Related bugs" feature ("See Also")
Whiteboard: [relations:other] [wanted-bmo] → [roadmap: 4.0][relations:other] [wanted-bmo]
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
I take it it's too late for 3.2?  Patch is probably bitrotted by my company is already using it in 3.x.
I recently installed the latest patch on my 3.0 installation, and it was pretty
clean.  There were a few files I had to hand fix.  I found later that the 
email_in.pl script also needs to be patched.  Otherwise, it seems to work as 
advertised. It's a great feature, whichever way it is implemented, and we are 
using it frequently.  
Assignee: nobody → create-and-change
Is this bug still wanted now that we already have a "See Also" field? Having yet another field seems overkill to me (and our goal should be to reduce the number of hardcoded fields, not to add more field).
Yes, our current "See Also" field is probably enough.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Target Milestone: Bugzilla 4.0 → ---
Can you give a pointer to the bug that describes the other "See Also" field?  (Maybe even resolve this bug as a dupe of that bug.)  All I could find was bug 231429, which seems like it's about linking to bugs in other BZ installations, not bugs in the same installation.  Or is the same installation ref just a special case of that bug?
(In reply to comment #77)
> Can you give a pointer to the bug that describes the other "See Also" field? 

bug 472872
I'm not sure whether to raise this issue here, in bug 472872, or a new bug.  If this is the wrong place, please let me know where it belongs.  :)

The patch for bug 472872 describes the See Also field (in part) like this: 'You should normally use this field to refer to bugs in <em>other</em> installations. For bugs in this installation, it is better to use the "Depends On" and "Blocks" fields.'

If that See Also feature is really going to meet the requirement in this bug, which is explicitly about bug relationships *other than* dependencies, this seems like the wrong thing to be telling users.  Not knowing the details of the implementation, I'm not sure whether a simply rewording that text is enough, or if there are more fundamental problems using bug 472872's see-also to refer to bugs in the same installation.  I guess either of those would be a new bug, but I'm not sure which one to file.  ;-)
(In reply to comment #77)
> Or is the same installation ref just a special case of that bug?

  The same-installation ref is just a special case of that bug. There are also "Bug ID" custom field types in 3.4 if you want to use those.
Whiteboard: [roadmap: 4.0][relations:other] [wanted-bmo] → [relations:other] [wanted-bmo]
For what it's worth, the "Bug ID" custom field appears to only handle single asymmetric relationships.  This ticket addresses multiple symmetric relationships, something we use heavily.  I don't know the effort to support such a thing, but it shouldn't be that bad once Bugzilla can handle custom block/depends_on bug id's.
If symmetric bug fields aren't supported it's probably time to start a new bug for that as a lot has changed.  Once that's fixed you can argue on a bmo configuration bug whether to turn it on here.

See Also is probably trying to solve a different problem really.
It should also be remembered that there's a difference between "hardcoded" and "default" fields.

I would suggest that such a field should be default (and in general new installations should include lots of fields, because it's easier for an admin to remove fields than it is for them to think of all those they might find useful.

On the other hand, hardcoded fields should be ruthlessly hunted down and shot.
(In reply to comment #83)
> I would suggest that such a field should be default (and in general new
> installations should include lots of fields, because it's easier for an admin
> to remove fields than it is for them to think of all those they might find
> useful.

With lots of fields displayed by default, this would make Bugzilla hard to use by default, which is a bad user experience, IMO. When I use a (new) program which has too much stuff in it, I quickly stop using it because it contains too many fields/options/parameters I don't fully understand and make me loose energy understanding what is important (the minimal set of fields to have something working) and what is secondary. That's also why we f.e. already removed not less than 10 parameters in Bugzilla 3.6 (compared to Bugzilla 2.22), to make it easier to use.
It's not clear whether you're talking about user or administrator experience here either.

I don't think that you can expect the set of fields that come out of the box to ever be what the admin is happy with, admins always need to properly configure their system, so the user experience should be irrelevant here.  Given this, admins should always be turning fields on and off when they install anyway.  Adding in fields by default won't make a difference because it's just extra configuration information, not an extra feature the admin needs to learn.

And as for the user experience of whether it's a useful feature in a specific environment, the admin can decide that anyway.  I'm not suggesting adding fields that aren't useful.  A symmetric related bugs has always been something that users would have found useful, they've just never had the opportunity to use it.
(In reply to comment #85)
> It's not clear whether you're talking about user or administrator experience
> here either.

This makes no difference when you are new to an application. It's as important to make Bugzilla easy to use by default for administrators as it's important to make it easy to use by default for users. I'm pretty sure that in your opinion, an administrator is a Bugzilla expert, which is probably wrong most of the time (you only become familiar after some time).
I never said that.  What I said was they need to become familiar with the ability to add and remove fields when they are learning just the same as they need to learn to add and remove products.  Whether there are 10 rows or 0 rows in the custom field table at the start doesn't change the learning curve.

Bugzilla has always had issues with complexity, but often its necessary complexity, at least for BMO.  Better solutions to user or administrator overload are to attack the problems directly, for example, to provide documentation within the interface, or providing simplified interfaced such as when in the past simplified bug reporting and querying was introduced.

But removing things that people will find useful, even by default, is often counter-productive to user-friendliness, because the user does not have access to features that will make their life easier.
(In reply to comment #87)
> But removing things that people will find useful, even by default, is often
> counter-productive to user-friendliness

Sure, I agree with that. And I think we have been pretty good so far at removing parameters which are useless to most (if not all) of us. But we are not going to remove 50% of the parameters just to make the Parameters page lighter, for instance. :)

Now talking about fields by default, the idea of custom fields is to let you add new fields if you need them, rather than add them by default and let you *remove* them if you don't need it. If the documentation is well-written, this seems a better alternative to me. My reasoning when I try to become familiar with a new application is "if this field or parameter is not displayed by default, this means I can live without it for now without affecting my productivity. And when I will be more familiar with the application, I can start looking at what the advanced features are (hopefully with good documentation and examples to makes things even clearer and more obvious)."
> Now talking about fields by default, the idea of custom fields is to let you
> add new fields if you need them, rather than add them by default and let you
> *remove* them if you don't need it.

Well the original idea was to introduce the customised fields and then unhardcode the existing fields, I'm not sure of the current progress but I'm gathering part 1 has occurred but part 2 has not, and I'm presuming the goals are still the same.

So given this, BZ should eventually get to a situation where most of the fields are custom.  At this point a bare-bones system would almost certainly be way too simple, the admin will always need to add fields anyway.

What might be a good compromise however, is to include a library of "templates" for common fields, with name, type, values, documentation, whatever.  Then you could let an administrator easily access the options even if the table starts empty.
Blocks: 537749
I created bug 537749 to discuss the original "related bugs" request.  Ironically, this is a perfect example where a related bugs field would be useful to have, rather than finding this comment in the 90 replies we have here. 

I also feel this "See Also" field should have been a custom field or at least an optional field.  It's an extra field we don't need (the URL field suffices).
(In reply to comment #90)
> Ironically, this is a perfect example where a related bugs field would be
> useful to have, rather than finding this comment in the 90 replies we have
> here. 

I don't see how it would have helped here.


> I also feel this "See Also" field should have been a custom field or at least
> an optional field.  It's an extra field we don't need (the URL field suffices).

It's an optional field. You can disable it from the Parameters page. And it's a very useful field we will need once it's fully implemented, see bug 504164 (something the URL field cannot do).
Thanks for pointing out about disabling the "See Also" field.  Didn't realize it was possible.
No longer blocks: 537749
Depends on: 537749
Summary: "Related bugs" feature ("See Also") → Implement "Related bugs" feature ("See Also")
You need to log in before you can comment on or make changes to this bug.