Best way would be to use xml-rpc. But unless I misunderstood documentation ( http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html ), we cannot do much on group with the API.

Another way is to *khof* edit the database directly. Quite fragile, hackish, etc. But maybe our best bet even if I think we should avoid that as much as possible.

Third way, use some www::mechanize stuff to log on bugzilla and change the group member ship. This would be as fragile as the 2nd way, but in a different manner.

CC: (none) => misc

Ok i guess I was wrong : http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/Group.html
But the interface do not fullfill our needs so far ( and that's for 4.1.1 ).

I think maybe we can take a look at the merge-users.pl script.

It seems to be around the user_group_map table.

Bugzilla::WebService::Group is not what you want. This module is to interact with groups directly (creation/editing/deletion), not with group membership. We first have to implement User.update, which is currently in progress, see https://bugzilla.mozilla.org/show_bug.cgi?id=416137. Once that's done, editing group membership will be implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=469196.

If the LDAP server is on the same server as Bugzilla, it's easy to interact with Bugzilla directly, without using the non-existent XML-RPC methods, and without interacting with the DB directly.

See Also: (none) => https://bugzilla.mozilla.org/show_bug.cgi?id=469196

I also found /usr/share/bugzilla/bin/bugzilla_ldapsync.rb and /usr/share/bugzilla/bin/syncLDAP.pl

Ok so here is a proposal, in pseudo code :

connect_to_ldap()
@list_of_admin = get_list_of_admin_email()
foreach my $admin (@list_of_admin ) {
   $bz_user = get_user($admin->email);
   $bz_user->set('groups','admin');
   $bz_user->update();
}

and redo for security ?

I guess that would be like half a day of work ( provided someone is not interrupted ).

I didn't found much example of bugzilla API usage, but according to the documentation, this can be done, so if we just add a cron job, this would be good.

to #4, Ldap is on a different server, but we can access it remotely ( obviously ), so I do not see that's a issue. So you would recommend creating a script using Bugzilla API ?

If we write it, would it be interesting to add it upstream somewhere ?

In fact, we could even make sure that users in identity are created in bz with such script.

This way we would solve the issue of packagers hat never connected to bugzilla.

Here is a quick script to get information from bugzilla : 
# cat test.pl 
use lib "/usr/share/bugzilla/lib/";
use Bugzilla;
use Bugzilla::User;
my $user = new Bugzilla::User( Bugzilla::User::login_to_id($ARGV[0]));
print "Id : ". $user->id . "\n";
print "Name : " . $user->name . "\n";

I guess this should demonstrate how to do the rest for a volunteer perl coder.

/me wonders why I only get half of the comments by email for this bug.

As contrib/syncLDAP.pl already exists, all you would need to do is to reuse it to suit your needs. I just looked at the script, and I see that it doesn't use existing methods to edit user membership, which is bad (but this is not surprising as this script hasn't be touched for the last 3 years). But you could easily fix that, as you suggested with your pseudo-code in comment 5.

In comment 6, if you mean to take upstream a patch for syncLDAP.pl which would update user membership in Bugzilla based on LDAP groups, then yes, that's certainly something we would take.

In fact, I did some scripting, and I do not see how to change the group of a user using the API ( ie, using ->set() :

use strict;
use warnings;
use lib "/usr/share/bugzilla/lib/";
use Bugzilla;
use Bugzilla::User;
use Bugzilla::Group;
my $user = new Bugzilla::User( Bugzilla::User::login_to_id($ARGV[0]));
print "Id : ". $user->id . "\n";
print "Name : " . $user->name . "\n";
for my $g ( @{$user->groups()} ) {
        print "Group : " . $g->name . "\n";
}
my $admin_group = Bugzilla::Group->match( { 'name' => 'admin' })->[0];

push(@{$user->{'groups'}}, $admin_group);
print Data::Dumper::Dumper($user);
print "$user \n";
$user->update();

I guess for group manipulation, it doesn't work with our version without fiddling with sql directly.

Ok, after checking on bugzilla trunk, either I am blind/dumb, or there is no obvious way to modify group membership using the API ( the fact that i didn't found how it is done by the web interface would make me think that I am blind/dumb ).

You are neither blind nor dumb. I thought we had methods to edit user membership, but we haven't yet. I will implement them upstream (I just assigned https://bugzilla.mozilla.org/show_bug.cgi?id=442013 to me).

See Also: (none) => https://bugzilla.mozilla.org/show_bug.cgi?id=442013

If too complicate to do it now, maybe we can update bugzilla groups manually, until the methods to edit user membership are available.

(In reply to comment #11)
>  I thought we had methods to edit user
> membership, but we haven't yet. I will implement them upstream (I just assigned
> https://bugzilla.mozilla.org/show_bug.cgi?id=442013 to me).

Wow, that's the true spirit! Great, Frédéric!
Hope you find/found enough time to work on it. Can you give any feedback?

CC: (none) => marja11

I'm focused on bugs blocking the release of Bugzilla 4.2. So I didn't start implementing it yet.

(In reply to Marja van Waes from comment #13)
> Hope you find/found enough time to work on it. Can you give any feedback?

This feature is available in Bugzilla 5.0. You should upgrade! ;)

(In reply to Frédéric Buclin from comment #15)
> (In reply to Marja van Waes from comment #13)
> > Hope you find/found enough time to work on it. Can you give any feedback?
> 
> This feature is available in Bugzilla 5.0. You should upgrade! ;)

Great :-)

An upgrade is certainly planned, after our servers are updated.

The status of this bug was set to assigned by boklm, who joined the mageia-alumni group since then, so changing it back to NEW

Status: ASSIGNED => NEW
CC: misc => mageia

Fixed: http://gitweb.mageia.org/web/bugs/commit/?id=ceefacd41

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED