231429 - (bz-seealso) offer an easy way to refer to a bug in another bugzilla (See Also)

Status: NEW

(Bugzilla :: User Interface, enhancement, P1)

Description

[Jungshik Shin]

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]]

see also bug 134294 for inter-bugzilla dependencies (related, not a dupe)

Comment 2

[Dave Miller [:justdave]]

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]

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]

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]

(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]

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

[u336811]

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]

The feature as it stands in 3.4 only covers three of the four blockers of this bug.

Comment 9

[Frédéric Buclin]

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.

Comment 10

[Kohei Yoshino]

The See Also field is already on BMO and will be shipping with Bugzilla 6.0.