Is the long-standing bug with the CLI and groups fixed in 3.6.1? I’m planning to upgrade from 3.6.0 anyhow; if this is fixed I’ll reprioritize the upgrade.
If not, is there any way (from the command line) to manipulate a user’s “privileged” status? I have a metric buttload of users to enable, and I have no wish to click through each one successively just to change one freakin’ checkbox.
If I’m being stupid (certainly wouldn’t be the first time) and there’s an easy way to do this without using the bin/rt tool, please feel free to ridicule me while you point out the answer. I would’ve tried it directly in MySQL, but the Privileged pseudogroup is nameless. 
Thanks,
Ole
PS. I say “long-standing” because after extensive Googling and archive spelunking, I’ve found the same question popping up several times but it’s never answered (at least, not on-list.) In 3.6.0 I get “# Unknown object type: group” from any attempt to show, list, edit, or create a group using the rt commandline tool, despite the verbiage in both the tool itself and in RT Essentials. This seems to have been a problem since at least 3.4.4.
Try the following sniplet:
#!/usr/bin/perl
use strict;
use warnings;
BEGIN { die “You must define $RT_HOME\n”
unless exists $ENV{RT_HOME} };
use lib “$ENV{RT_HOME}/lib”;
use RT;
RT::LoadConfig();
RT::Init();
use RT::Interface::CLI qw(GetCurrentUser loc);
use RT::Tickets;
my $CurrentUser = GetCurrentUser();
die loc(“No RT user found.\n”) unless ($CurrentUser->Id);
die “We need exactly 2 Arguments, Name & Email\n” unless ($#ARGV==1);
my $UserName=shift @ARGV;
my $Email=shift @ARGV;
my $User = RT::User->new($CurrentUser);
my
($id,$Message)=$User->Create(Name=>$UserName,EmailAddress=>$Email,Privileged=>1,Password=>‘changeme’);
if ($id){
print $Message.“\n”;
}
else{
print"This is a error!\n$Message\n";
}2006/8/21, Ole Craig ocraig@stillsecure.com:
Is the long-standing bug with the CLI and groups fixed in 3.6.1? I’m
planning to upgrade from 3.6.0 anyhow; if this is fixed I’ll reprioritize
the upgrade.
If not, is there any way (from the command line) to manipulate a user’s
“privileged” status? I have a metric buttload of users to enable, and I have
no wish to click through each one successively just to change one freakin’
checkbox.
If I’m being stupid (certainly wouldn’t be the first time) and there’s an
easy way to do this without using the bin/rt tool, please feel free to
ridicule me while you point out the answer. I would’ve tried it directly in
MySQL, but the Privileged pseudogroup is nameless. 
Thanks,
Ole
PS. I say “long-standing” because after extensive Googling and archive
spelunking, I’ve found the same question popping up several times but it’s
never answered (at least, not on-list.) In 3.6.0 I get “# Unknown object
type: group” from any attempt to show, list, edit, or create a group using
the rt commandline tool, despite the verbiage in both the tool itself and in
RT Essentials. This seems to have been a problem since at least 3.4.4.
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
MFG
Torsten Brumm
http://www.torsten-brumm.de
and read with this sh scrip from csv file:
#!/bin/bash
P1=/opt/rt3/local/bin/
U1=/opt/rt3/local/bin/userlist
while read zeile; do
set – $zeile
echo "Bearbeite User: "$1 $2
/usr/bin/perl ${P1}creatertuser.pl $1 $2
done<$U12006/8/22, Torsten Brumm torsten.brumm@googlemail.com:
Try the following sniplet:
#!/usr/bin/perl
use strict;
use warnings;
BEGIN { die “You must define $RT_HOME\n”
unless exists $ENV{RT_HOME} };
use lib “$ENV{RT_HOME}/lib”;
use RT;
RT::LoadConfig();
RT::Init();
use RT::Interface::CLI qw(GetCurrentUser loc);
use RT::Tickets;
my $CurrentUser = GetCurrentUser();
die loc(“No RT user found.\n”) unless ($CurrentUser->Id);
die “We need exactly 2 Arguments, Name & Email\n” unless ($#ARGV==1);
my $UserName=shift @ARGV;
my $Email=shift @ARGV;
my $User = RT::User->new($CurrentUser);
my
($id,$Message)=$User->Create(Name=>$UserName,EmailAddress=>$Email,Privileged=>1,Password=>‘changeme’);
if ($id){
print $Message.“\n”;
}
else{
print"This is a error!\n$Message\n";
}
2006/8/21, Ole Craig < ocraig@stillsecure.com>:
Is the long-standing bug with the CLI and groups fixed in 3.6.1? I’m
planning to upgrade from 3.6.0 anyhow; if this is fixed I’ll
reprioritize the upgrade.
If not, is there any way (from the command line) to manipulate a user’s
“privileged” status? I have a metric buttload of users to enable, and I have
no wish to click through each one successively just to change one freakin’
checkbox.
If I’m being stupid (certainly wouldn’t be the first time) and there’s
an easy way to do this without using the bin/rt tool, please feel free to
ridicule me while you point out the answer. I would’ve tried it directly in
MySQL, but the Privileged pseudogroup is nameless.
Thanks,
Ole
PS. I say “long-standing” because after extensive Googling and archive
spelunking, I’ve found the same question popping up several times but it’s
never answered (at least, not on-list.) In 3.6.0 I get “# Unknown object
type: group” from any attempt to show, list, edit, or create a group using
the rt commandline tool, despite the verbiage in both the tool itself and in
RT Essentials. This seems to have been a problem since at least 3.4.4.
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
–
MFG
Torsten Brumm
http://www.torsten-brumm.de
MFG
Torsten Brumm
http://www.torsten-brumm.de
and read with this sh scrip from csv file:
[…]
Try the following sniplet:
[…]
Torsten -
Thanks muchly! I’ll give it a whirl tonight. Looks like this
creates the user and sets privileged at the same time? Or does
$User->Create()
allow modification of existing users as well as creation of new ones?
Thanks again,
Ole
/Ole Craig
Security Engineer
303-381-3802 (main support hotline)
303-381-3824 (my direct line)
303-381-3801 (fax)
www.stillsecure.com
. . .
-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf
Of Ole Craig
Sent: Wednesday, August 23, 2006 11:36 AM
To: Torsten Brumm
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] CLI: manipulating “privileged” status
and read with this sh scrip from csv file:
[…]
Try the following sniplet:
[…]
Torsten -
Thanks muchly! I’ll give it a whirl tonight. Looks like this
creates the user and sets privileged at the same time? Or does
$User->Create()
allow modification of existing users as well as creation of new ones?
I’ve always used:
create as a new user, putting the first address in a few places for easy
recognition
my %UserDetails = (
‘Name’ => $user,
‘EmailAddress’ => $user,
‘ExternalContactInfoId’ => $uid,
‘Comments’ => “Auto-created upon user creation”,
‘Gecos’ => substr($uid, 0, index($uid, ‘@’))
);
my ($status, $msg) = $User->Create(%UserDetails);
if ($status) {
print “Done.\n”;
} else {
printf(“Failed (%s).\n”, $msg);
exit(1);
}
}
If we still don’t have a User ID, die off
unless ($User->id) {
printf("Whoa, something really odd happened! User should have been
created (%s)!\n", $user);
exit(2);
};
Make sure the user can take privileges. Do this here instead of upon
creation, as the user might already exist
printf("Found user (%s::%d). Checking privileges setting: ", $user,
$User->id);
if ($User->Privileged()) {
print “Yes.\n”;
} else {
print "No. Granting… ";
They didn’t have privs. Give them to the user
if ($User->SetPrivileged(1)) {
print "Done.\n";
} else {
print "Failed.\n";
exit(1);
}
}
It only creates new users, if a unprivileged already exsists, it does
nothing, only put out a message
Mit freundlichen Gruessen / With kindest regards
Torsten Brumm
Kuehne + Nagel
Ferdinand Strasse 29-33
20095 Hamburg
Germany
Tel: +49 40 329 15 199
Fax: +49 40 329 15 500
Www: www.kuehne-nagel.com