Open Bug 504164 Opened 15 years ago Updated 1 month ago

Display the status, resolution and bug summary of external bugs in the "see also" field

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

enhancement
Not set
normal

Tracking

()

People

(Reporter: LpSolit, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

Bugzilla 3.6 currently supports the see_also feature, which lets you point to bugs being in other installations. It would be really helpful if hovering them would also display the status and resolution of these external bugs, and also display the bug summary if they are public.

(Note that you can always get the status and resolution, e.g. thanks to page.cgi?id=linkify.html, but there should be a cleaner way to get these information)
Here is the kind of implementation we could have to collect and display the data. In this proof of concept, the remote bug data is not stored locally so we have to request it every time someone views the bug, which is not ideal as it slows down the display of the page. I think we should have a cron job (maybe collectstats.pl, or a separate .pl script, or add a timestamp to the DB and only re-request the data every X hours) to update the data. Also, I use LWP::UserAgent and XML::Twig (which we already request to get notifications when a new Bugzilla version is available) to get and parse the remote data. Your opinion on this?
Cool, thanks for the PoC.

I ideally want Bugzillas to only use XML-RPC/JSON-RPC to access each other, but I don't know how realistic that is. The advantage of just using the XML is that we gain compatibility with older Bugzilla implementations.

As far as storing remote data goes, if we store it, we should be storing it in the bug_see_also table. And yeah, we should have a timestamp and only be re-fetching things later.

However, we should be doing this all after the bug is displayed--display of the bug should not have to wait on fetching data from another Bugzilla. In particular, we should be fetching the data when we hover over the link. (If there are 50 links on the bug, we should not be making 50 requests when we open the page. ) That will also allow us to re-use the current user's browser cookies to authorize them in another Bugzilla. Unfortunately, this means that we may not have the opportunity to store the data (and in fact, that we shouldn't, given possible security restrictions). We may be able to store information about the remote *installation*, however, such as whether it supports XML-RPC or not (given its config.cgi version).
(In reply to comment #2)
> That will also allow us to re-use the current user's browser
> cookies to authorize them in another Bugzilla. Unfortunately, this means that
> we may not have the opportunity to store the data (and in fact, that we
> shouldn't, given possible security restrictions).

I think we should store the data in the DB. LWP::UserAgent->get() will query the remote installation as a logged out user, so if it can get the data, it's safe to store it and display it locally to our users, as they could follow the links and see the remote bugs themselves, independently of their privs.

If the remote bug becomes restricted after the data has already been fetched, well, this is not a real data leak as the data was accessible to everybody in the past.
Well, I don't think there's any need to handle a performance problem before we actually can see that there is one. Let's not worry about storing it in the DB before we actually run into a serious real-world problem that would require that (and then maybe there will be some other solution there).

Anyhow, we can't use LWP::UserAgent in the browser, and we can't currently update anything from the browser over JSON-RPC, so let's not worry about that all for now.
We no longer accept new features for Bugzilla 3.6. Retargetting to 3.8.
Target Milestone: Bugzilla 3.6 → Bugzilla 3.8
Target Milestone: Bugzilla 4.0 → Bugzilla 5.0
Depends on: 609968
timello, do you want to work on this? :-) This is the next big piece of bz-seealso.
Assignee: create-and-change → timello
(In reply to comment #7)
> timello, do you want to work on this? :-) This is the next big piece of
> bz-seealso.

Well, I thought dkl did that already, didn't he?

At least we are using FILTER bug_link in the fields.html.tmpl template.
(In reply to comment #8)
> At least we are using FILTER bug_link in the fields.html.tmpl template.

This only works for bugs in the same Bugzilla installation, not for external bugs. This bug is about external bugs.
Summary: Display the status, resolution and bug summary of bugs in the "see also" field → Display the status, resolution and bug summary of external bugs in the "see also" field
YUI 3 has a JSONP module, which doesn't exist in YUI 2. We could then call Bug.get when hovering links pointing to other Bugzilla installations.
Depends on: 453268
In adding this feature, would there be some way to turn this functionality off on the remote Bugzilla installation, lest people (intentionally or unintentionally) cause too many automated queries to a remote Bugzilla install?  Would there be any need to add that?

(For example, in case of a DoS attack or a benign case where a large Bugzilla install frequently references a smaller one, overwhelming its limited server resources.)
(In reply to Tanner M. Young [:tmyoung] from comment #11)
> unintentionally) cause too many automated queries to a remote Bugzilla
> install?

No, we finally won't implement it this way. We will only get the data when the user hovers the links.
(In reply to Frédéric Buclin from comment #12)
> No, we finally won't implement it this way. We will only get the data when
> the user hovers the links.

  Although for bugs that are public in the remote installation, we may cache this information for some period of time locally. It's something to think about during implementation or afterward when we see actual usage; it's not something we should be worrying about quite *yet*.
We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.
Target Milestone: Bugzilla 4.4 → Bugzilla 5.0
Target Milestone: Bugzilla 5.0 → ---
Assignee: timello → create-and-change
Attachment #9385860 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: