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)
Tracking
()
NEW
People
(Reporter: LpSolit, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
5.42 KB,
patch
|
Details | Diff | Splinter Review |
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)
Reporter | ||
Comment 1•15 years ago
|
||
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?
Comment 2•15 years ago
|
||
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).
Reporter | ||
Comment 3•15 years ago
|
||
(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.
Comment 4•15 years ago
|
||
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.
Reporter | ||
Comment 5•15 years ago
|
||
We no longer accept new features for Bugzilla 3.6. Retargetting to 3.8.
Target Milestone: Bugzilla 3.6 → Bugzilla 3.8
Updated•14 years ago
|
Target Milestone: Bugzilla 4.0 → Bugzilla 5.0
Comment 7•13 years ago
|
||
timello, do you want to work on this? :-) This is the next big piece of bz-seealso.
Assignee: create-and-change → timello
Comment 8•13 years ago
|
||
(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.
Reporter | ||
Comment 9•13 years ago
|
||
(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.
Updated•13 years ago
|
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
Reporter | ||
Comment 10•13 years ago
|
||
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
Comment 11•13 years ago
|
||
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.)
Reporter | ||
Comment 12•13 years ago
|
||
(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.
Comment 13•13 years ago
|
||
(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*.
Reporter | ||
Comment 14•12 years ago
|
||
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
Updated•10 years ago
|
Target Milestone: Bugzilla 5.0 → ---
Updated•11 months ago
|
Assignee: timello → create-and-change
Comment hidden (spam) |
Updated•1 month ago
|
Attachment #9385860 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•