Last Comment Bug 231429 - (bz-seealso) offer an easy way to refer to a bug in another bugzilla (See Also)
(bz-seealso)
: offer an easy way to refer to a bug in another bugzilla (See Also)
Status: NEW
[roadmap: 4.0][3.6 Focus]
: meta
Product: Bugzilla
Classification: Server Software
Component: User Interface (show other bugs)
: unspecified
: All All
: P1 enhancement with 1 vote (vote)
: ---
Assigned To: Tiago Mello [:timello]
: default-qa
Mentors:
Depends on: 475057 475059 504164 577847 472872 474249 474902 513212 549586 553932 560003 577835 593539 594083 620827 621122 821410
Blocks: 123130 532350 533121 543667 558784 571740 617802 704999 735196 752871
  Show dependency treegraph
 
Reported: 2004-01-18 22:51 PST by Jungshik Shin
Modified: 2014-09-15 07:37 PDT (History)
18 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Jungshik Shin 2004-01-18 22:51:54 PST
With bugzilla widely deployed for a number of projects, there is a growing need
to refer to bugs in bugzillas for related projects. For instance, I have to
refer to freedesktop bugzilla (http://bugzilla.freedesktop.org), gnome bugzilla
(http://bugzilla.gnome.org), XFree86 bugzilla (http://bugs.xfree86.org) and
RedHat Linux bugzilla (https://bugzilla.redhat.com). It'd be nice if bugzilla
offers a short-cut to refer to bugs in other bugzillas. Currently, bugzilla
'html'izes 'bug #?[1-9][0-9]* [comment #? [0-9]+]'. I'm suggesting that that
would be extended to htmlize 'freedesktop:bug 12345 comment 23' for a set of
pre-defined (admin-configurable) bugzillas for related projects.
Comment 1 Dave Miller [:justdave] (justdave@bugzilla.org) 2004-01-18 23:02:54 PST
see also bug 134294 for inter-bugzilla dependencies (related, not a dupe)
Comment 2 Dave Miller [:justdave] (justdave@bugzilla.org) 2004-09-18 18:19:55 PDT
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Comment 3 Max Kanat-Alexander 2008-12-16 19:21:36 PST
I think that I want to implement this *instead* of cross-installation dependencies. We can eventually make it a two-way automatically-mutual relationship, and I don't think the "dependency tree" aspect is all that important for cross-installation bug reference.

I wrote out a spec for this feature for a client, and it will involve several steps, which we can implement in several bugs. But I wanted to record the full spec here:

1. Bugzilla bugs should be able to link to bugs in other Bugzillas. The basic element of this requirement is to be able to paste a link to a Bugzilla bug into a field and have that link stored, and then display the current status and summary of that bug when you hover over it. Retrieving the status and summary should be done by JavaScript, so that it re-uses the cookies and permissions of the currently-logged-in Bugzilla user.

If the link does not point to a valid Bugzilla installation, it should be rejected. Note that it can point to a hidden Bugzilla bug, or a bug on a requirelogin installation that's fine.

Permissions to set this field should be identical to permissions for setting the “Depends On” or “Blocks” fields.


2. This relationship should be two-way. Setting a link in this bug on this Bugzilla should also set a link to this bug on that bug in that Bugzilla. Likewise, removing a link on one Bugzilla should remove the link from the other Bugzilla. This link-setting is done via WebServices. If that Bugzilla does not support WebServices, then the linking is not done. This Bugzilla should keep track of whether or not the link was accepted and done on the other side.


3. Setting a link does not require a login, but it does require that you prove that you are the Bugzilla you say you are. This is done by passing a token as an argument when setting a link, and then this Bugzilla will call a WebServices function on that Bugzilla to verify that the token is valid.

4. Bugzilla administrators should be able to block certain IP addresses or Bugzillas from setting links in this Bugzilla. This is done with a comma-separated list in a parameter called “inter_tracker_acl”. Domains with URL paths are interpreted as Bugzilla installations. Otherwise, IPv4 or IPv6 addresses are accepted.

If an IP address is specified, we check against the actual IP that the connection is coming from. If a URL path is specified, we check against the “url” argument passed to the set_link WebService function. (These arguments and functions may actually end up with different names, these are just examples to explain the system.)

This does not block users of this Bugzilla from setting links on this Bugzilla to that Bugzilla. It only blocks that Bugzilla from modifying bugs on this Bugzilla.

5. There should be a parameter called “inter_tracker_acl_type” that changes the “block list” from the previous requirement into an “allow list”, so that administrators for certain installations can specify that only certain other Bugzillas can set links in this Bugzilla. This list should default to a block list, though, not an allow list.


Basically, each one of those steps is a separate bug.
Comment 4 Roland 2008-12-18 02:50:23 PST
I like this - it's elegant, it's simple (sort of) and it's exactly what is needed.

Some ideas:
I think that if implemented we should look at the web standards space and maybe use OAuth for authentication of bugzilla interlinking.
Comment 5 Max Kanat-Alexander 2008-12-18 05:19:44 PST
(In reply to comment #4)
> I think that if implemented we should look at the web standards space and maybe
> use OAuth for authentication of bugzilla interlinking.

  That's a good idea, I'll see if OAuth could be used for this situation.
Comment 6 Max Kanat-Alexander 2009-01-07 18:43:15 PST
Okay, so this is going to become a meta-bug for tracking all the necessary tasks here. Canonical is funding some development on this.
Comment 7 Olivier Berger 2009-08-04 08:17:45 PDT
Hasn't this been implemented in Bugzilla 3.4 ? : http://www.bugzilla.org/releases/3.4/release-notes.html#v34_feat_see ?
Comment 8 Matt McHenry 2009-08-04 13:08:26 PDT
The feature as it stands in 3.4 only covers three of the four blockers of this bug.
Comment 9 Frédéric Buclin 2012-08-25 02:57:25 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.