112532 - Bug Lists: For duplicates, link to the real one

Status: REOPENED

(Bugzilla :: Query/Bug List, enhancement)

Description

[xyzzy]

When a bug list contains a duplicate bug, it would be nice to have a link to the
"real" bug instead of just the one marked as a duplicate.  This might require
chasing down a chain of duplicates until a non-duplicate is found.

The interface for this might be simply converting the result field "DUPL" to
linked  text to the "real" bug.

Comment 1

[Christian Reis]

I don't think this is a good idea: it violates the principle that buglist points
to the bug in question. A duplicate bug *is* a real bug -- it just a "semantic
duplicate" of another; it's often important to visit a duplicate to see who was
the original reporter, what platform it was reported on, and so on.

I understand your motivation for optimizing finding the real bug, but why are
you listing and visiting duplicates in the first place?

Marking WONTFIX; please reopen if you think you have a good rationale for this.

(One perhaps "more valid" approach might be adding a "Duplicate Of" column to
buglist.cgi, but this isn't what's being proposed here)

Comment 2

[Dave Miller [:justdave]]

bulk removing target on WONTFIX/INVALID/WORKSFORME/DUPLICATE so they'll show up
as untriaged if they get reopened.

Comment 3

[Adam Guthrie]

*** Bug 312549 has been marked as a duplicate of this bug. ***

Comment 6

[timeless]

kiko: i feel you're misinterpreting the request, however I'm willing to add a badge next to the DUPL text which is also linked to indicate that it is not going to the same place. In fact, I'll probably just make the badge link to the bug, because I'm trying to change buglists to be more like drill down, in which case most fields actually don't link to the bug.

Comment 7

[Eyal Rozenberg]

My suggestion in the dupe bug 312549 is have the word 'DUPE', rather than the bug number, link to the real bug. That doesn't seem to violate anything and doesn't require another column (the text might also be extended to say 'dupe of bug XXXXXX', without creating another column but at the cost of expanding the status column).

Comment 8

[David D. Kilzer (ddk)]

I think This bug depends on Bug 68611 getting fixed first per Comment #0.

Comment 9

[Mark Clements]

(In reply to Eyal Rozenberg from comment #7)

My suggestion in the dupe bug 312549 is have the word 'DUPE', rather than
the bug number, link to the real bug. That doesn't seem to violate anything

It violates the principal of least surprise. A bug number must always link to the bug it refers to.

I would perhaps support the introduction of a quick way of linking from a duped bug to the bug that it is a dupe of, so long as it doesn't conflict with expected use. This also applies going forward so, for example, if it was decided that 'DUPE' would link to the bug it was a duplicate of, it would mean that we couldn't ever make the resolution column clickable for other reasons (e.g. to filter the list by resolution) as that would mean the behaviour of that link would change depending on the bug.

A better solution would be to include the duped bug number in the table and make this number a clickable link, in the way everyone would expect it to be. Whether this is a separate column or appended to an existing column (e.g. DUPE of [bug xxx]), I don't know. Just off the top of my head, how about a 'related bugs' column that also includes direct links to blockers/dependencies?

On a personal note, I can't see myself using this feature - I don't recall ever needing to jump to the parent bug, rather than see the details of the bug I'm looking at (though I might click through from the bug page, if relevant). Is there any evidence of this being a desirable feature? What use-cases does it solve (i.e. in what situations will you have navigate to a bug list and then want a direct link to bypass the duped bug)? In my case, bug lists are either work lists (e.g. sprints) where we would want to know the detail of why the bug was duped (i.e. not link to the related bug), lists of open bugs (which would, by definition, not include any duped items) or search results, where I would expect both bugs to show up.

Comment 10

[Eyal Rozenberg]

It violates the principal of least surprise. A bug number must always link to the bug it refers to.

I think you may have misread my comment; but I also misspoke, so let me clarify. I'm not suggesting the bug number link to the dupe, I suggest the bug list's 'Resolution' column link to it. That is, a duplicate bug in the list has the word "DUPL" in the resolution column, and it's currently not a link anywhere. Nor is the Resolution value a link for other kinds of resolutions. I suggest we linkify it to be a link to the non-dupe.

Comment 11

[Mark Clements]

(In reply to Eyal Rozenberg from comment #10)

It violates the principal of least surprise. A bug number must always link to the bug it refers to.

I think you may have misread my comment; but I also misspoke, so let me
clarify.

Thanks for the clarification. I understood 'rather than' to mean 'instead of'.

I suggest the bug list's 'Resolution' column link to it. That is, a duplicate bug in the
list has the word "DUPL" in the resolution column, and it's currently not a
link anywhere. Nor is the Resolution value a link for other kinds of
resolutions. I suggest we linkify it to be a link to the non-dupe.

This won't work if bug 390831 is implemented.

Comment 12

[Eyal Rozenberg]

(In reply to comment #11)

Thanks for the clarification. I understood 'rather than' to mean 'instead of'.
Ok, and, are you in favor or against this?

This won't work if bug 390831 is implemented.

That bug has not seen any work in 12 years. But if and when that is implemented, there are at least two workarounds:

1. The resolution column can be extended to say "DUPL of bug 12345"; clicking the DUPL or the column overall would result in drill-down, but clicking the non-dupe bug number will lead you there.
2. The resolution column can be extended to say DUPL with drill-down, but hovering or clicking near the edge of a column cell will bring up the longer form with the original bug name, which will be linkified.

Thus for now it shouldn't concern us, and if it does get implemented, work on this bug can be salvaged.

Comment 13

[Mark Clements]

As I said in comment 9, I can't see myself using this feature, but I'm not opposed to it if there is a genuine use-case for it and the implementation doesn't break user expectation or conflict with any current or planned feature.

Bug 390831 was recently updated to be dependent on bug 1529362. I misread that as being made a blocker, and that it was going to be worked on imminently. If that's not the case, then maybe it's less relevant. However, I would still recommend that whatever solution is implemented bears that use-case in mind.

Your suggestion #1 is one of the implementations I suggested in my penultimate paragraph of comment 9, and would probably work OK.

Your suggestion #2 is a bit too 'magic hidden interface' for me.

I also suggested a 'related bugs' column, which should perhaps be explored in conjunction with bug 1207291 (and which would also included blockers/dependencies). May be overkill, but equally might be a neat way of solving a couple of different issues. As these fields are not sortable, there would be no disadvantage to combining them, that I can see.

Comment 14

[Eyal Rozenberg]

If the dupe was in the related bugs, that would be a passable, though suboptimal solution. It would be better if, in that case, it would be styled differently and/or had a link alt-text indication saying it's the real/original/non-dupe/anti-dupe of the current bug.