Bug 231429 (bz-seealso)

offer an easy way to refer to a bug in another bugzilla (See Also)

NEW
Assigned to

Status

()

Bugzilla
User Interface
P1
enhancement
14 years ago
3 years ago

People

(Reporter: Jungshik Shin, Assigned: timello)

Tracking

(Depends on: 4 bugs, Blocks: 1 bug, {meta})

Details

(Whiteboard: [roadmap: 4.0][3.6 Focus])

(Reporter)

Description

14 years ago
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)
Summary: offers an easy way to refer to a bug in other bugzillas → offers an easy way to refer to a bug in other bugzillas
Summary: offers an easy way to refer to a bug in other bugzillas → offer an easy way to refer to a bug in another bugzilla

Updated

13 years ago
Target Milestone: --- → Bugzilla 2.20
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22

Updated

12 years ago
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Bugzilla 2.22 → ---

Updated

11 years ago
Assignee: myk → ui

Updated

10 years ago
Blocks: 123130
Summary: offer an easy way to refer to a bug in another bugzilla → offer an easy way to refer to a bug in another bugzilla (See Also)

Comment 3

9 years ago
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.
Assignee: ui → mkanat
Priority: -- → P1
Whiteboard: [roadmap: 4.0]
Target Milestone: --- → Bugzilla 4.0

Comment 4

9 years ago
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

9 years ago
(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

8 years ago
Okay, so this is going to become a meta-bug for tracking all the necessary tasks here. Canonical is funding some development on this.
Keywords: meta

Updated

8 years ago
Alias: bz-seealso

Updated

8 years ago
Depends on: 472872

Updated

8 years ago
Depends on: 474249

Updated

8 years ago
Depends on: 474902

Updated

8 years ago
Whiteboard: [roadmap: 4.0] → [roadmap: 4.0][3.6 Focus]

Updated

8 years ago
Depends on: 504164

Comment 7

8 years ago
Hasn't this been implemented in Bugzilla 3.4 ? : http://www.bugzilla.org/releases/3.4/release-notes.html#v34_feat_see ?

Comment 8

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

Updated

8 years ago
Depends on: 475059

Updated

8 years ago
Depends on: 475057

Updated

8 years ago
Blocks: 532350

Updated

8 years ago
Blocks: 533121
Blocks: 543667

Updated

7 years ago
Depends on: 549586
Blocks: 558784
Depends on: 571740
Depends on: 553932
Depends on: 513212
Depends on: 577835
See Also: → bug 537749
Blocks: 571740
No longer depends on: 571740
Depends on: 577847, 560003

Updated

7 years ago
Depends on: 593539
Depends on: 594083

Updated

7 years ago
Assignee: mkanat → timello
(Assignee)

Updated

6 years ago
Depends on: 620827
Depends on: 621122
Blocks: 704999, 617802, 661533

Updated

5 years ago
No longer blocks: 661533
Blocks: 735196
Blocks: 752871

Comment 9

5 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

4 years ago
Depends on: 821410

Updated

3 years ago
Target Milestone: Bugzilla 5.0 → ---
You need to log in before you can comment on or make changes to this bug.