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.
see also bug 134294 for inter-bugzilla dependencies (related, not a dupe)
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.
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:
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.
I like this - it's elegant, it's simple (sort of) and it's exactly what is needed.
I think that if implemented we should look at the web standards space and maybe use OAuth for authentication of bugzilla interlinking.
(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.
Okay, so this is going to become a meta-bug for tracking all the necessary tasks here. Canonical is funding some development on this.
Hasn't this been implemented in Bugzilla 3.4 ? : http://www.bugzilla.org/releases/3.4/release-notes.html#v34_feat_see ?
The feature as it stands in 3.4 only covers three of the four blockers of this bug.
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.