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 [:kohei]]

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

Comment 11

[Prestige Park Grove]

Next week, we will be branching for Bugzilla 4.4, and we have determined that this particular bug is too risky or invasive to be included in that release. So, we've decided to make 5.0, which is our upcoming major release, the target milestone for this bug.

We kindly ask that you reassign this bug to the default assignee if you, as the assignee, do not intend to work on it anytime soon. Everyone will understand more clearly as a result of this that this bug must be fixed in order for the 5.0 release to take place. Thank you for your assistance. https://www.prestigeparksgrove.ind.in/

Comment 12

[Prestige Serenity Shores]

Prestige Serenity Shores is considered an unmatched residential property located in Whitefield, Bangalore. Whitefield is a highly sought-after area in Bangalore, known for its excellent infrastructure, connectivity, and vibrant residential communities.

Prestige Serenity Shores stands out among the residential properties in the area due to its exceptional design, quality construction, and range of amenities. The property offers a blend of comfort, convenience, and luxury, making it a desirable choice for homebuyers.

Visits: https://www.prestigeserenityshore.in

Comment 13

[prestigeparkgrove0]

Prestige Park Grove by Prestige Group, is an apartments project. Whitefield is a real estate hub in the city of Bangalore. Projects located in this area offer amenities like easy metro and rail connectivity, and proximity to offices and business centers, among others. Prestige Park grove will offer the above-mentioned amenities along with some additional facilities like a badminton court, a swimming pool, a gymnasium, an aerobics room, and a recreational hall.
https://www.prestigesparkgrove.in/
https://www.prestigesparkgrove.in/amenities.html

Comment 14

[Prestige Park Ridge]

I developed a specification for this feature for a customer, and it will need various processes, which we may implement in multiple bugs. https://www.prestigeparkridge.net.in

Comment 15

[David]

I have encountered the same issue described by the original reporter on Firefox 95 (Windows 10). The JavaScript code provided triggers an unexpected behavior that results in incorrect parsing of certain expressions. This behavior is consistent across multiple test cases. https://www.providentecopoliten.net.in

Comment 16

[Alucas Varen]

On Windows 10 and Firefox 95, I've encountered the same issue that the original user reported. When using the provided JavaScript code, some expressions are incorrectly parsed, which is an unexpected problem. In numerous test cases, this problem is repeatedly reproduced.
https://www.godrejsplendour.net.in