Hi Tomas,

For security purposes and to prevent possible spams, if the the user is not
logged in and they call getCompInfo then they only get realnames, however logged
in users will get email addresses returned fine.

Cheers,
Noura

(In reply to comment #1)
> however logged in users will get email addresses returned fine.

I came across following case then it breaks:

- calling bugzilla.getCompInfo for component bash without username+password
returns names without emails
- calling with username+password returns error:
  Sorry, entering a bug into the product Red Hat Public Beta has been disabled.

Same script works fine against old BZ.

(In reply to comment #2)
> (In reply to comment #1)
> > however logged in users will get email addresses returned fine.
> 
> I came across following case then it breaks:
> 
> - calling bugzilla.getCompInfo for component bash without username+password
> returns names without emails

This is correct behaviour.

> - calling with username+password returns error:
>   Sorry, entering a bug into the product Red Hat Public Beta has been disabled.
> 

This is also correct behaviour currently as the product is closed. Of course we
could change it to return the component list even if the product is closed. But
that would be a RFE.

(In reply to comment #3)
> > - calling with username+password returns error:
> >   Sorry, entering a bug into the product Red Hat Public Beta has been
> >   disabled.
> 
> This is also correct behaviour currently as the product is closed. Of course
> we could change it to return the component list even if the product is
> closed. But that would be a RFE.

I'm *not* trying to file a bug, all I'm asking for is component information. 
When I call getCompInfo with component name, it is expected to return a hash
containing a component description for all products (though I believe not
getting info about closed/disabled product should not be an issue).

So if I'm using getCompInfo in an incorrect way, what is the correct way?  All I
expect from it is to get owner / initialcc email addresses for given component
across all products.  I can't do that when accessing BZ anonymously (because of
the spam concerns described above) and getCompInfo does not return any useful
information, if request is authenticated and is for the component, that ever
appeared in any product that is now disabled.

I'm trying to see if I can get comparable functionality using new API.  Do you
have any working examples of Component.get usage you can share?  Based on
example in Component.pm, this should work:

$rpc->call('Component.get', {
    names => [
        { 'product' => 'Fedora', 'component' => 'bash' }
    ]});

But all I get is:

Can't call method "login_exempt" on an undefined value at
/var/www/html/bugzilla/Bugzilla/WebService.pm line 50.

I wonder if I messed my authentication part...

> Can't call method "login_exempt" on an undefined value at
> /var/www/html/bugzilla/Bugzilla/WebService.pm line 50.
> 
This is actually a bug, a fix has been committed to cvs to solve that should
work fine in the next beta release.

and here is an example of how to call that function :

use strict;
use warnings;

use XMLRPC::Lite;
use Data::Dumper;
use HTTP::Cookies;

my $username   = '';
my $password   = '';
my $xmlrpc_url = 'https://partner-bugzilla.redhat.com/xmlrpc.cgi';


my $cookie_jar = new HTTP::Cookies();

my $rpc = new XMLRPC::Lite;
$rpc->proxy($xmlrpc_url);
$rpc->transport->cookie_jar($cookie_jar);



my $call = $rpc->call( 'User.login',
    { login => $username, password => $password } );


$call = $rpc->call('Component.get', {names => [{ 'product' => 'fedora',
'component' => 'bash'}]});

my  $result = "";
if ( $call->faultstring ) {
    print $call->faultstring . "\n";
    exit;
}
else {
    $result = $call->result;
}

print "Data: " . Dumper($result) . "\n";

(In reply to comment #6)
> This is actually a bug, a fix has been committed to cvs to solve that should
> work fine in the next beta release.

Ah, thank you, Noura!

> and here is an example of how to call that function :

Right, very similar to what I was using.  Good to know the problem is not on my
side in this case ;).

Created attachment 311362 [details]
v1 patch to filter out closed products from getCompInfo 

Thinking about the error thrown from bugzilla.getCompInfo when the product is
closed as in the example that Thomas mentioned, I think that throwing an error
for the closed products prevents returning info for similar components but for
other opened products, for example the component bash can be found in more than
one product but because one of them is closed we just get an error and no info
is returned for the component in the open products like fedora for example ..
IMO a better behavior would be to filter out those closed products from the
return and just get the info for components of open products, this can be done
by omitting the THROW_ERROR param which gets passed to can_enter_product and
also it is actually an optional param. patch is attached for that.
what do you think Dave?

Noura

Thanks Noura!  That's likely a root cause of the problem I tried to describe in
comment #4.

Comment on attachment 311362 [details]
v1 patch to filter out closed products from getCompInfo 

Noura, change looks good to me. It should address the issue thoger is having. I
also agree just dropping the closed products from the results is the right
thing as we do this in the enter_bug.cgi product list as well.
Feel free to check this in. 

thoger, do we need to do a patch for 2.18 as well or can this wait til after
Aug 2nd when we upgrade to 3.2? 

Dave

No need to patch 2.18, as there's no problem there, as far as I can tell.  I can
get required information over anonymous or authenticated session.  For
authenticated session, I get bit more info (some non-public products as well),
but it does not choke on closed products.  Migration to new BZ was my concern.

2.18 works well, let it die peacefully. ;)

Thanks for reporting this issue Tomas and for testing :), The fix has been
committed to cvs should be there with the next partner-bugzilla package updates'
push.

Noura

bugzilla.getCompInfo now works with current partner-bugzilla (as of 2008-07-29)
and it does no longer choke on disabled products, so I presume "next
patner-bugzilla package updates" already happened.  Moving bug to verified, feel
free to close it.

Thanks for the verification.