127875 - redirect moved bugs to new installation

Status: NEW

(Bugzilla :: Bug Import/Export & Moving, enhancement, P4)

Description

[Myk Melez [:myk] [@mykmelez]]

When a bug has been moved to another Bugzilla installation, hitting the bug on
the old installation should issue a permanent redirect to the bug on the new
installation.  A URL parameter such as "redirect=no" could be used to allow the
user to see the old bug report on the rare occasion they needed it.

Comment 1

[Jacob Steenhagen]

This would require the old installation to know the bug number (in addition to
the urlbase) of the new installation.  AFAIK, this information is not currently
passed back (athough I could be wrong as I've never really used moving).

Comment 2

[Myk Melez [:myk] [@mykmelez]]

>This would require the old installation to know the bug number (in addition to
>the urlbase) of the new installation.  AFAIK, this information is not currently
>passed back (athough I could be wrong as I've never really used moving).

The URL base is easy; it can be part of the new installation configuration in
bug 127871.  Getting the new bug number back to the old installation is harder,
and may require a new messaging method like XML-RPC.

Comment 3

[Bradley Baetz (:bbaetz)]

You can't use xmlrpc, because then bugscape bugs couldn't be moved to bugzilla,
since bugzilla can't access the bugscape machine behind the ns firewall.

Comment 4

[Andreas Franke (gone)]

I thought Myk was suggesting to do the actual move via xml-rpc; the return value
would then be the new bug number in the new installation, or a fault if
something went wrong. This would require the target bugzilla to be reachable via
HTTP from the source bugzilla. So the problem would be moving bugs from bugzilla
to bugscape.

Comment 5

[Dave Miller [:justdave]]

dkl may have some insight here...  he's done some RPC stuff on RedHat's bugzilla
already (he converted bzbot to use RPC for getting bug data when he converted it
for RedHat's use)

Comment 6

[Guzmán Brasó]

What happened to this?

Comment 7

[Guzmán Brasó]

Hi!

I'm willing to take care of proovide this functionality for 3.2.

The patch for Webservice::Bug to know id of bugs on the target installation it's already done but waiting for 3.2, see bug 369275 .

I've a couple of propposals:

- Only affect movers or defined group.
Or we allow this functionality for the 'movers' users, or we ask as param in "Bug Moving" section for the groupname that is allow to use/see this functionality. 
The reason for this is that I usually move bugs between Bz's on Internet as source and BZ's on VPNs as target. So if the user on the Internet installation see the bug I don't want him to proovide any functionality regarding my bz in the vpn as I will not proovide him with access to the VPN. However is a safe bet movers have access to the vpn and are connected to it while working.

- Dont permanent redirect, just proovide a link.
I'm against a permanent redirect. In my case source/public installations are used for the sheeps and the internal/in_the_vpn installation are used by developers. So movers besides move the bug to internal installation need to reply questions to users of the external installation, while developers work on it in the internal one. So for my movers a permanent redirect will be a real problem.
I'm for a link next to the bug id on the show_bug.cgi like this: 
Current: Bug 127875 (Remote id XXXXXX) – redirect moved bugs ... (edit) 
Propposal: Bug 127875 (Remote id XXXXXX) – redirect moved bugs ... (edit)

Well that's my both proppsals. By the way thinking more about it, if you guys agree on my way to put the link... maybe we can even better just show:
Bug 127875 (Get Remote Id) – redirect moved bugs ... (edit)
And when clicked on Get Remote Id we query through js xmlrpc the WebServices at the target DB and change "Get Remote Id" by "Remote Id XXXXXX" and be a link to go for it inside. Or even proovide both: "Remote Id: Get/Go", if click on Get, change as described before and that "Remote Id XXXXX" be al ink to the bug. If clicked on Go, just get the id and go to the remote installation show_bug for that bug.

Any comments? We have two weeks before 3.2 is ready to accept development and I'm intrested in submit it as soon as possible as I guess in a month my freetime will be gone.

Comment 8

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 9

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

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.