Include status and summary for bugs listed in `depends_on` and `blocks` fields

RESOLVED FIXED

Status

()

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: erik.bryn, Assigned: dkl)

Tracking

Development

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
I'd like to be able to provide a similar experience to the existing Bugzilla UI. Bug summaries are visible upon hovering over a bug link and if the bug is resolved it gets crossed out.
(Assignee)

Updated

5 years ago
Assignee: nobody → dkl
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Assignee)

Comment 1

5 years ago
Created attachment 812667 [details] [diff] [review]
921219_1.patch
Attachment #812667 - Flags: review?(glob)
Comment on attachment 812667 [details] [diff] [review]
921219_1.patch

r=glob

erik, be aware there's a performance cost for this request, especially for tracking bugs which have large numbers of dependencies.
Attachment #812667 - Flags: review?(glob) → review+
(Assignee)

Comment 3

5 years ago
Committing to: bzr+ssh://dlawrence%40mozilla.com@bzr.mozilla.org/bmo/4.2
modified extensions/Ember/lib/WebService.pm
Committed revision 9123.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Reporter)

Comment 4

5 years ago
Has this been deployed? I'm curious what the performance cost is of adding this. Since we've started loading data separately, I might end up wanting to load this information separately if it add a significant cost.
Flags: needinfo?(dkl)
(Assignee)

Comment 5

5 years ago
(In reply to Erik Bryn from comment #4)
> Has this been deployed? I'm curious what the performance cost is of adding
> this. Since we've started loading data separately, I might end up wanting to
> load this information separately if it add a significant cost.

Not to production. I am working on syncing bugzilla-dev with the production tree right now which will bring this change in. It will not be on production until the next code push next week.

dkl
Flags: needinfo?(dkl)
(Assignee)

Comment 6

5 years ago
(In reply to David Lawrence [:dkl] from comment #5)
> (In reply to Erik Bryn from comment #4)
> > Has this been deployed? I'm curious what the performance cost is of adding
> > this. Since we've started loading data separately, I might end up wanting to
> > load this information separately if it add a significant cost.
> 
> Not to production. I am working on syncing bugzilla-dev with the production
> tree right now which will bring this change in. It will not be on production
> until the next code push next week.
> 
> dkl

The dependency changes should be on bugzilla-dev now for your testing.

dkl
(Reporter)

Comment 7

5 years ago
The response contains two sets of the `blocks` and `depends_on` fields. Here's an example response: https://bugzilla-dev.allizom.org/rest/ember/show/856410. The prior field data is outputted after, so that overrides the new field data, which keeps me from using it now.

Is it possible for you to do a quick and dirty assessment of the performance cost of this change? I'm wondering if we should bother with it or not. Bugzilla-dev seems to have been reverted back to embedding attachments/comments so I can't really assess it myself now.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 8

5 years ago
(In reply to Erik Bryn from comment #7)
> The response contains two sets of the `blocks` and `depends_on` fields.
> Here's an example response:
> https://bugzilla-dev.allizom.org/rest/ember/show/856410. The prior field
> data is outputted after, so that overrides the new field data, which keeps
> me from using it now.

Investigating now.

> Is it possible for you to do a quick and dirty assessment of the performance
> cost of this change? I'm wondering if we should bother with it or not.
> Bugzilla-dev seems to have been reverted back to embedding
> attachments/comments so I can't really assess it myself now.

May be related to a recent merge cleanup I had to do when merging from bmo/4.2. Will look into that as well.

dkl
(Assignee)

Comment 9

5 years ago
(In reply to David Lawrence [:dkl] from comment #8)
> (In reply to Erik Bryn from comment #7)
> > The response contains two sets of the `blocks` and `depends_on` fields.
> > Here's an example response:
> > https://bugzilla-dev.allizom.org/rest/ember/show/856410. The prior field
> > data is outputted after, so that overrides the new field data, which keeps
> > me from using it now.
> 
> Investigating now.

Fixed extra blocks/depends_on entries.

Committing to: bzr+ssh://dlawrence%40mozilla.com@bzr.mozilla.org/bmo/4.2
modified extensions/Ember/lib/WebService.pm
Committed revision 9137.

> > Is it possible for you to do a quick and dirty assessment of the performance
> > cost of this change? I'm wondering if we should bother with it or not.
> > Bugzilla-dev seems to have been reverted back to embedding
> > attachments/comments so I can't really assess it myself now.
> 
> May be related to a recent merge cleanup I had to do when merging from
> bmo/4.2. Will look into that as well.

I think this should be tracked in bug 928989. 

dkl
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.