369275 - Ability to get info about bugs that we moved to another installation

Status: NEW

(Bugzilla :: WebService, enhancement)

Description

[Guzmán Brasó]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5
Build Identifier: 3.0

This is an enhancement I'll take care of it. I'm filling a bug to have a central point where to share thoughts about while I work on it as this will be my first time into WebService.

What I'm going to add I'm already doing it with some hacks since 2.16.

Function: 
get_bugs_moved (EXPERIMENTAL)

Description:
Function to be executed in the destination installation of moved bugs, called by the source installation that moved the bugs to query basic info of moved bugs into it.

Params: 
  First scalar: source installation urlbase.
  Second scalar: source installation bug_id
  Any more scalars: source installation bug_ids.

Returns

A hash containing as key the id of the source installation bug_id and as value a hash with information about the bug created for the given bug_id at source installation.

Errors

In case of errors found, like user not able to get the bug information or the bug never got into the destination installation, a single XML-RPC error will be sent and in the value of that item in returned hash will be a hash with an item error with the same id of error XML-RPC sent. So the user knows which bugs called the generic errors they saw, this is useful if one installation send a request to receive info about 100 bugs where 80 are wrong. One way it raise only one "101","Invalid Bug Id" and in each hash of the 80 bugs set items error to "101". Or should I raise 80 XML-RPC  "101","invaild source bug_id #xxx" errors for each error found?.

Internally the function that will find the local bug_id, will do a query of all longdescs for each received source_bug_id looking for

thetext LIKE '%previously known as _bug_ $source_bug_id at $source_urlbase %' 
OR 
thetext LIKE '%previously known as bug $source_bug_id at $source_urlbase %'

The two options are the way bugzilla save in comments when a bug is accepted. As you may remember previous versions use to use "as bug XXXXX" and current ones use "as _bug_ XXXXX"

After the query is done, user privileges must be checked for each local bug found before puting it into the hash to be returned.
I know it's not smart to do the query before checking privileges but there is no way to know the local bug_id before the query.

Also i think the function should check first of anything if user logged in XML-RPC is in movers group.

Well... please tell me to go to hell or do it.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Guzmán Brasó]

I forgot, I think the function should go into WebService::Bug or if we are planning to development more support in WebService for moved bugs create a Move.pm  module.

Comment 2

[Max Kanat-Alexander]

Couldn't you just do this with the normal get_bugs? The mover knows where the bug went, and the receiver knows where the bug came from, yes? All you have to do is make a WebService call against xmlrpc.cgi on that urlbase.

Comment 3

[Guzmán Brasó]

No, I can't.

Follow me on my scenario:

I have three bugzillas, two which I usually use as source for moving bugs. And one bugzilla which receives the bug from the other two installations. From now on: BZ-SRC-1, BZ-SRC-2 and BZ-REC.

Let's suppouse I move bug 3220 from BZ-SRC-1 to BZ-REC. 
Bug is marked MOVED at BZ-SRC-1. 
Bug reach BZ-REC and get id 50.000

Then suppouse I move bug 3220 from BZ-SRC-2 to BZ-REC.
Bug is marked MOVED at BZ-SRC-2 
Bug reach BZ-REC and get id 50.001.

Now I want my script in BZ-SRC-1 to quiery WebServices at BZ-REC and tell me information about the bug I moved to.

What I know at BZ-SRC-1 ?
Destination urlbase and BZ-SRC-1 id of the bug, not the id assigned at BZ-REC.
AFAIK the only way to know the destination number it have is by reading your mail as mover or parsing the comments as I suggested.

I can't see where i'm wrong. But as it's late sunday here I beileve I could be totally wrong and just over excited about it :-). Please tell me what I am missing.

Comment 4

[Max Kanat-Alexander]

Oh hey, that's a good point. We should move by WebService instead of by importxml.pl, where we can. :-) That would probably help that.

Yeah, so that sounds like an acceptable function. We'd need it to create the redirects that we want to create.

The parameters should be a hash, of course. (Parameters always are, for our WebService.)

get_moved_bugs would be the name. You can call the parameters from_url and my_bug_id, I suppose, unless you have better ideas for their names.

Comment 5

[Guzmán Brasó]

Suggested names sounds perfect.

I'll have sooner than expected a propposed patch.

Comment 6

[Guzmán Brasó]

Attachment: Patch 1.0 for Bugzilla::WebService::Bug.pm

first patch, it miss documentation but proovides expected functionality.

Comment 7

[Guzmán Brasó]

Attachment: Patch 1.0 for bz_webservice_demo.pl

This patch enable bz_webservice_demo test Bugzilla::WebService::Bug::get_bugs_moved() functionality.

Comment 8

[Max Kanat-Alexander]

Comment on attachment 254016 [details] [diff] [review]
Patch 1.0 for Bugzilla::WebService::Bug.pm

>+sub get_bugs_moved {
>+    my ($self, $params) = @_;
>+
>+    Bugzilla->login(LOGIN_REQUIRED);

  Why does this require a login?

>+    # We now need to find for each comming id, the longdesc where bugzilla inserted
>+    # the message "previously known as ".
>+    my $dbh = Bugzilla->dbh;
>+    my $sth = $dbh->prepare("SELECT bug_id FROM longdescs 
>+                             WHERE thetext LIKE ? OR thetext LIKE ?"
>+              );

  Instead of this we should start to store this data in the database. That is, if a bug was moved from somewhere else, we should store where it was moved from in a database column in the bugs table, and what its old id was.

>+        # Next while it's to support multiple bugs created by same bug. 
>+        while ( my ($bug_id) = $sth->fetchrow_array()) {
>+
>+            # create hash with bug information 
>+            # more info check comments at get_bugs() above.
>+            my $bug = new Bugzilla::Bug($bug_id);

  No, just return the ID, don't return the bug data. We don't want to duplicate the get_bugs code.

Comment 9

[Guzmán Brasó]

(In reply to comment #8)

> (From update of attachment 254016 [details] [diff] [review])
> >+sub get_bugs_moved {
> >+    my ($self, $params) = @_;
> >+
> >+    Bugzilla->login(LOGIN_REQUIRED);
> 
>   Why does this require a login?
> 

Because I wanted the user logged in so later I can check if the user have access to the imported bugs and if not give an error as he don't deserve to know even the bug number the bug got when imported.

But if get_bugs will take care of reading bugs information, let's get bugs take care of that. 

Removed: Done.

> >+    my $dbh = Bugzilla->dbh;
> >+    my $sth = $dbh->prepare("SELECT bug_id FROM longdescs 
> >+                             WHERE thetext LIKE ? OR thetext LIKE ?"
> >+              );
> 
>   Instead of this we should start to store this data in the database. That is,
> if a bug was moved from somewhere else, we should store where it was moved
> from in a database column in the bugs table, and what its old id was.

Is the move of bugs so used that it worths adding a field to bugs table?.
I thought propposed way will be better because it will work with moved bugs from older and newest installations without touch the db.

Remember you are talking about saving a full urlbase on each bug on bugs table, it's that much used move functionality?.

Maybe we can create a table bugs_moved with fields like:
bug_id from_urlbase from_id exporter bug_when

But that will mean I need to upload a patch to change the db schema, checksetup, and that means that it will be a work in vain to do it now and it will be better to wait to have a working 3.1 before do more development about this enhancement or I'm wrong?

I'll leave the code in the next patch while we discuss this better.
I'll not remove it yet so we keep the patch working.

> >+        # Next while it's to support multiple bugs created by same bug. 
> >+        while ( my ($bug_id) = $sth->fetchrow_array()) {
> >+
> >+            # create hash with bug information 
> >+            # more info check comments at get_bugs() above.
> >+            my $bug = new Bugzilla::Bug($bug_id);
> 
>   No, just return the ID, don't return the bug data. We don't want to duplicate
> the get_bugs code.

Ok. Done.

Comment 10

[Guzmán Brasó]

Attachment: Patch 1.1 for bz_webservice_demo.pl

Updated bz_webservice_demo to don't use bug status information on test of get_bugs_moved as it will return only id's from now on.

Comment 11

[Guzmán Brasó]

Attachment: Patch 1.1 for Bugzilla::WebService::Bug.pm

Comment 12

[Max Kanat-Alexander]

> Because I wanted the user logged in so later I can check if the user have
> access to the imported bugs and if not give an error as he don't deserve to
> know even the bug number the bug got when imported.

  You don't have to *require* a login for that. If they're not logged in, they'll just be rejected.

> Is the move of bugs so used that it worths adding a field to bugs table?.

  Perhaps instead you can use the mechanism that we just added to the longdescs table, where there are fields that can store extra information.

> Maybe we can create a table bugs_moved with fields like:
> bug_id from_urlbase from_id exporter bug_when

  There's no reason to create a separate table.

> But that will mean I need to upload a patch to change the db schema,
> checksetup, and that means that it will be a work in vain to do it now and it
> will be better to wait to have a working 3.1 before do more development about
> this enhancement or I'm wrong?

  Just do it, if you want it done. :-) We're close to branching, anyway.

Comment 13

[Guzmán Brasó]

I didn't make it to the Bugzilla meeting and therefore installations integration was not discussed.

According to the log soon discusssion will start on developers list and as I understand from the logs a roadmap regarding this will be defined for 3.2.

So I guess best will be to wait to see what people decide regarding installation integration as the moved bug id is the main stone of that building.

So current patch it's working but it's querying bugs longdescs to get the bug id. Excepto for the way I use to get the id of the bugs, the rest of the patch it's ok?.

As soon how we will save bug id is decided I'll submit an update of the patch to reflect that.

Comment 14

[Max Kanat-Alexander]

Comment on attachment 254092 [details] [diff] [review]
Patch 1.1 for Bugzilla::WebService::Bug.pm

This needs to be implemented by adding a field instead, saying what bug it came from in the other installation. former_bug_id would be fine.

Comment 15

[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 "blocking3.2" tp "?", 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 16

[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.