1338520 - Link to dependency tree only shows if a bug has at least two blocked and/or depends

Status: RESOLVED DUPLICATE of bug 1546774

(bugzilla.mozilla.org :: User Interface, defect, P5)

Description

[Axel Hecht [:Pike]]

In BugModal display, the link to the dependency tree only shows if the bug has both blocked and dependent bugs.

I wonder if https://github.com/mozilla-bteam/bmo/blob/master/extensions/BugModal/template/en/default/bug_modal/edit.html.tmpl#L885 is the culprit. I forgot all the perl that I ever new, but if either doesn't have a .size?

Comment 1

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

It shows for me on bug 1337488. Looking at that line of code, you need at least two bugs in either field to see the graph/tree links. I'd think the links would be useful with the sum being greater or equal to 1, rather than just greater than 1, personally.

Comment 2

[Axel Hecht [:Pike]]

Right, adusting summary.

Comment 4

[Dylan Hardison [:dylan] (he/him)]

yeah, I suspect >= 1 would be correct. Or stating what we really mean, which is
blocks > 0 OR deps > 0.

Comment 5

[David Lawrence [:dkl]]

I would prefer that we make it where (blocks >= 1 && depends >= 1). For me if only one of depends or blocks has a dependency, it is more useful to click on the bug id directly bringing up the bug detail page for the dependent bug than to go to a screen with a single entry with very limited information. Now I will agree where if both have at least one (2 or greater), it would be fine.

dkl

Comment 6

[Axel Hecht [:Pike]]

Here's how I found this: I had a bug open, and I knew it was part of a rather complex dependency hierarchy, so I wanted actually even the graph of it, to find the bug that would best describe the next part I intended to work on.

If we had access here to all blocked and dependent bugs across hiearchy, I'd agree that showing the link isn't necessary. Not sure that we do, though.

Comment 7

[David Lawrence [:dkl]]

(In reply to David Lawrence [:dkl] from comment #5)
> I would prefer that we make it where (blocks >= 1 && depends >= 1). For me
> if only one of depends or blocks has a dependency, it is more useful to
> click on the bug id directly bringing up the bug detail page for the
> dependent bug than to go to a screen with a single entry with very limited
> information. Now I will agree where if both have at least one (2 or
> greater), it would be fine.

Actually that is already current behavior (sorry didnt read the code before).

  [% IF bug.dependson.size + bug.blocked.size > 1 %]

So if my logic is agreeable we can close this. Otherwise I would like to see more on the argument that we should bring up the dependency tree page for only a single bug.

dkl

Comment 8

[David Lawrence [:dkl]]

(In reply to Axel Hecht [:Pike] from comment #6)
> Here's how I found this: I had a bug open, and I knew it was part of a
> rather complex dependency hierarchy, so I wanted actually even the graph of
> it, to find the bug that would best describe the next part I intended to
> work on.
> 
> If we had access here to all blocked and dependent bugs across hiearchy, I'd
> agree that showing the link isn't necessary. Not sure that we do, though.

Ah I see. well we could look at the dependent bug's dependency list to see how many it has but wouldn't want to go further than that due to performance issues.

So Maybe if the bug that we block or depend on has 1 or more dependencies that are not the bug we are looking at?

dkl

Comment 9

[Axel Hecht [:Pike]]

Yeah.

Comment 10

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Resetting assignee since dkl not available for this.

Comment 11

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Should this be something for a patch from community?

Comment 12

[Dylan Hardison [:dylan] (he/him)]

There is currently not an efficient way of doing this; building the bug tree is very expensive.
If building the dependency tree was efficient it would be a trivial thing to do...
I imagine solving *that* problem might be interesting enough if we had someone that likes algorithms. :)

Comment 13

[Kohei]

I missed this bug. This has been solved in Bug 1546774.