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

RESOLVED WONTFIX

Status

()

P2
enhancement
RESOLVED WONTFIX
20 years ago
8 years ago

People

(Reporter: CodeMachine, Unassigned)

Tracking

(Depends on: 1 bug)

Details

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

Attachments

(1 attachment, 4 obsolete attachments)

(Reporter)

Description

20 years ago
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...
(Reporter)

Comment 2

20 years ago
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?

Updated

19 years ago
Status: NEW → ASSIGNED
Priority: P3 → P2

Comment 3

19 years ago
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

Updated

19 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 4

19 years ago
*** Bug 42800 has been marked as a duplicate of this bug. ***

Comment 5

19 years ago
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)).

Comment 7

19 years ago
> it shouldn't include the bug it was run from in the query (#2800).

good idea.  fixed :)
(Reporter)

Updated

18 years ago
Whiteboard: 3.2

Comment 8

18 years ago
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
(Reporter)

Comment 12

18 years ago
Heavily voted enhancement, target for 2.16.
Priority: P2 → P3
Target Milestone: Bugzilla 3.2 → Bugzilla 2.16
(Reporter)

Comment 13

18 years ago
Moving to new Bugzilla product ...
Assignee: tara → justdave
Status: ASSIGNED → NEW
(Reporter)

Comment 14

18 years ago
Really moving ...
Assignee: justdave → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → unspecified
Whiteboard: [relations:other]

Comment 15

18 years ago
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. ***

Comment 21

16 years ago
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.

Comment 24

15 years ago
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.

Updated

15 years ago
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. ***

Comment 27

14 years ago
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.

Updated

14 years ago
Blocks: 163993
(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

Updated

14 years ago
No longer blocks: 163993

Comment 29

14 years ago
Created attachment 187459 [details] [diff] [review]
initial patch

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!

Comment 30

14 years ago
Created attachment 187688 [details] [diff] [review]
advanced patch

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

Comment 31

14 years ago
Created attachment 188321 [details] [diff] [review]
advanced patch, v2

Updated patch.	Added sanitycheck support.
Attachment #187688 - Attachment is obsolete: true

Comment 32

14 years ago
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)

Comment 33

14 years ago
(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.

Comment 34

14 years ago
Albert Ting, ping? No reply to my last comment?

Comment 35

14 years ago
(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. 

Comment 36

14 years ago
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 37

14 years ago
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-

Comment 38

13 years ago
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

Comment 39

13 years ago
Created attachment 203468 [details] [diff] [review]
v3, based on the 2.22 tip

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)

Updated

13 years ago
Assignee: myk → altlst

Comment 40

13 years ago
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-

Comment 41

13 years ago
(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

Comment 42

13 years ago
I'll vote that the relation should be symmetrical.  If you're feeling adventurous, you could make a preference to control it.  :)

Comment 43

13 years ago
(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.

Comment 44

13 years ago
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...

Comment 46

13 years ago
I don't think this feature should be transitive.

Comment 47

13 years ago
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.

Comment 48

13 years ago
(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.

Comment 49

13 years ago
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.

Comment 50

13 years ago
(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.

Comment 52

13 years ago
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.

Comment 53

13 years ago
(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.

Comment 54

13 years ago
(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.

Comment 55

13 years ago
(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).

Comment 56

13 years ago
(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.

Comment 58

13 years ago
(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."

Comment 60

13 years ago
*** Bug 332541 has been marked as a duplicate of this bug. ***

Comment 61

13 years ago
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. ***

Comment 63

13 years ago
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 ..."

Updated

13 years ago
QA Contact: mattyt-bugzilla → default-qa
Keywords: dogfood
Keywords: dogfood
Whiteboard: [relations:other] → [relations:other] [wanted-bmo]

Comment 64

13 years ago
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

Comment 65

12 years ago
*** Bug 363065 has been marked as a duplicate of this bug. ***

Comment 66

12 years ago
I'd really like to see this bug implemented!  We really have a need for it in our installation.

Comment 67

12 years ago
Created attachment 250245 [details] [diff] [review]
v4, based on 12/26/06 tip

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 69

12 years ago
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-

Comment 70

12 years ago
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

Comment 73

12 years ago
I take it it's too late for 3.2?  Patch is probably bitrotted by my company is already using it in 3.x.

Comment 74

11 years ago
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

Comment 75

10 years ago
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
Last Resolved: 10 years ago
Resolution: --- → WONTFIX

Updated

10 years ago
Target Milestone: Bugzilla 4.0 → ---

Comment 77

10 years ago
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?

Comment 78

10 years ago
(In reply to comment #77)
> Can you give a pointer to the bug that describes the other "See Also" field? 

bug 472872

Comment 79

10 years ago
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.

Updated

10 years ago
Whiteboard: [roadmap: 4.0][relations:other] [wanted-bmo] → [relations:other] [wanted-bmo]

Comment 81

9 years ago
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.
(Reporter)

Comment 82

9 years ago
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.
(Reporter)

Comment 83

9 years ago
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.
(Reporter)

Comment 85

9 years ago
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).
(Reporter)

Comment 87

9 years ago
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)."
(Reporter)

Comment 89

9 years ago
> 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.

Updated

9 years ago
Blocks: 537749

Comment 90

9 years ago
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).

Comment 92

9 years ago
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.