Set user rights with scrip?

RT Users
1

RT is so cool.

From the wiki;
"A ScripAction can access and change the current instance of the following
objects:

Scrip
Ticket
Transaction
Template "

I need to be able to affect a user’s access rights with a scrip.

Scenario:
I want to allow anyone to send requests into Support
Like most you, I get lots of messages offering me PE patches, Viagra, and
partnerships with African ex-dignitaries
I need an easy way to manage and reduce spam without missing that possible
“We love your product and have $1M to spend.”

Solution:
Have SpamAssasin insert Possible SPAM into the Subject line of suspected
spam (working)
Have RT check the Subject line and if ‘Possible SPAM’ is present, move the
ticket to the ‘Trash’ queue while also bypassing the AutoReply and Notify
scrips (working)

At some pre-defined schedule, have a human look at the Trash queue, use
Update multiple tickets, check all and set Status to ‘deleted.’

One very cool thing I’ve discovered is that if a user exists in RT, and you
uncheck “Let this user access RT”, the next time that same user attempts to
send a message, RT will reject it, not create the ticket, and send the user
a terse note explaining that they do not have create ticket rights. That
would enable me to prevent any more spam from that same user, and save my
ticket numbers in the process.

So I want to create a script that does -

Condition: Status eq ‘deleted’ and Queue eq ‘Trash’
Action: $RequestorObj->SetRights(“Access”,0)

Or similar. Is it possible? Right now I can accomplish this manually, but
mass updates are so much better.

Thanks in advance!

Bill

2

RT is so cool.

From the wiki;
"A ScripAction can access and change the current instance of the following
objects:

Scrip
Ticket
Transaction
Template "

I need to be able to affect a user’s access rights with a scrip.

Scenario:
I want to allow anyone to send requests into Support
Like most you, I get lots of messages offering me PE patches, Viagra, and
partnerships with African ex-dignitaries
I need an easy way to manage and reduce spam without missing that possible
“We love your product and have $1M to spend.”

Solution:
Have SpamAssasin insert Possible SPAM into the Subject line of suspected
spam (working)
Have RT check the Subject line and if ‘Possible SPAM’ is present, move the
ticket to the ‘Trash’ queue while also bypassing the AutoReply and Notify
scrips (working)

At some pre-defined schedule, have a human look at the Trash queue, use
Update multiple tickets, check all and set Status to ‘deleted.’

One very cool thing I’ve discovered is that if a user exists in RT, and you
uncheck “Let this user access RT”, the next time that same user attempts to
send a message, RT will reject it, not create the ticket, and send the user
a terse note explaining that they do not have create ticket rights. That
would enable me to prevent any more spam from that same user, and save my
ticket numbers in the process.

So I want to create a script that does -

Condition: Status eq ‘deleted’ and Queue eq ‘Trash’
Action: $RequestorObj->SetRights(“Access”,0)

Or similar. Is it possible? Right now I can accomplish this manually, but
mass updates are so much better.

Yes, this can be done. Create a scrip on the Trash queue. Custom condition
of $self->TransactionObj->Type eq ‘Status’ and $self->TicketObj->Status
eq ‘deleted’.

$self->TicketObj->Requestors will give an RT::Group of
requestors. For each requestor you can get the RT:User
object at call $UserObj->SetPrivileged(0).

-Todd

3

Todd,

That’s great and thanks for the quick reply. Excuse my ignorance, but how
do I get from the Requestors RT Group to the UserObj? In this case, I’m
assuming only one Requestor.

$self->TicketObj->Requestors->< missing this >$UserObj->SetPrivileged(0);
return 1;

Bill-----Original Message-----
From: Todd Chapman [mailto:todd@chaka.net]
Sent: Monday, June 19, 2006 10:23 AM
To: Bill Chever
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Set user rights with scrip?

On Mon, Jun 19, 2006 at 10:01:31AM -0700, Bill Chever wrote:

RT is so cool.

From the wiki;
"A ScripAction can access and change the current instance of the
following
objects:

Scrip
Ticket
Transaction
Template "

I need to be able to affect a user’s access rights with a scrip.

Scenario:
I want to allow anyone to send requests into Support Like most you, I
get lots of messages offering me PE patches, Viagra, and partnerships
with African ex-dignitaries I need an easy way to manage and reduce
spam without missing that possible “We love your product and have $1M
to spend.”

Solution:
Have SpamAssasin insert Possible SPAM into the Subject line of
suspected spam (working) Have RT check the Subject line and if
‘Possible SPAM’ is present, move the ticket to the ‘Trash’ queue while
also bypassing the AutoReply and Notify scrips (working)

At some pre-defined schedule, have a human look at the Trash queue,
use Update multiple tickets, check all and set Status to ‘deleted.’

One very cool thing I’ve discovered is that if a user exists in RT,
and you uncheck “Let this user access RT”, the next time that same
user attempts to send a message, RT will reject it, not create the
ticket, and send the user a terse note explaining that they do not
have create ticket rights. That would enable me to prevent any more
spam from that same user, and save my ticket numbers in the process.

So I want to create a script that does -

Condition: Status eq ‘deleted’ and Queue eq ‘Trash’
Action: $RequestorObj->SetRights(“Access”,0)

Or similar. Is it possible? Right now I can accomplish this
manually, but mass updates are so much better.

Yes, this can be done. Create a scrip on the Trash queue. Custom condition
of $self->TransactionObj->Type eq ‘Status’ and $self->TicketObj->Status eq
‘deleted’.

$self->TicketObj->Requestors will give an RT::Group of requestors. For each
requestor you can get the RT:User object at call $UserObj->SetPrivileged(0).

-Todd

4

At Monday 6/19/2006 02:14 PM, Bill Chever wrote:

Todd,

That’s great and thanks for the quick reply. Excuse my ignorance, but how
do I get from the Requestors RT Group to the UserObj? In this case, I’m
assuming only one Requestor.

$self->TicketObj->Requestors->< missing this >$UserObj->SetPrivileged(0);
return 1;

Bill

Bill,

A ticket can have more than one requestor, so you can’t do what you
want in one line. $self->TicketObj->Requestors returns a Group
object, so you’ll have to work with that object to pull out the
individual requestors.

Steve

5

Steve,

Thanks, but “so you’ll have to work with that object to pull out the
individual requestors.” is exactly what I am having trouble tracking down.
How do I “work with the Group object” and where would it be documented as to
what objects are actually available to me?

Thanks for the answer!

Bill

6

At Monday 6/19/2006 03:46 PM, Bill Chever wrote:

Steve,

Thanks, but “so you’ll have to work with that object to pull out the
individual requestors.” is exactly what I am having trouble tracking down.
How do I “work with the Group object” and where would it be documented as to
what objects are actually available to me?

Thanks for the answer!

Bill

You can see the perl API docs with perldoc - assuming the $RTHOME/lib
directory is in your perl library path, do:

perldoc RT::Ticket_Overlay

to see the methods in the Ticket object.

This should get you the Group’s members in an RT::GroupMembers
collection object:

my $requestors = $self->TicketObj->Requestors->MembersObj

Then to work with each requestor,

while (my $req = $requestors->Next) {
my $req_principal = $req->MemberObj;
if ($req_principal->IsUser) {
$req_principal->Object->SetPrivileged(0);
}
}

The variables above represent these kind of objects:

$requestors - RT::GroupMembers
$req - RT::GroupMember
$req_principal - RT::Principal

This seems cumbersome, and maybe there’s a more streamlined way, but
it should do what you want. The if statement may be unnecessary ( I
think requestors are always users, not groups) but it doesn’t hurt.

Steve

7

Alrighty then!

This is great information, Stephen. Thanks!

Only one problem - The right I want to revoke is the “Let this user access
RT” right, not “Let this user be granted rights” which is what gets changed
by the SetPrivileged. Is there a SetAccess equivalent?

BillFrom: Stephen Turner [mailto:sturner@MIT.EDU]
Sent: Monday, June 19, 2006 1:29 PM
To: Bill Chever
Cc: rt-users@lists.bestpractical.com
Subject: RE: [rt-users] Set user rights with scrip?

At Monday 6/19/2006 03:46 PM, Bill Chever wrote:

Steve,

Thanks, but “so you’ll have to work with that object to pull out the
individual requestors.” is exactly what I am having trouble tracking down.
How do I “work with the Group object” and where would it be documented
as to what objects are actually available to me?

Thanks for the answer!

Bill

You can see the perl API docs with perldoc - assuming the $RTHOME/lib
directory is in your perl library path, do:

perldoc RT::Ticket_Overlay

to see the methods in the Ticket object.

This should get you the Group’s members in an RT::GroupMembers collection
object:

my $requestors = $self->TicketObj->Requestors->MembersObj

Then to work with each requestor,

while (my $req = $requestors->Next) {
my $req_principal = $req->MemberObj;
if ($req_principal->IsUser) {
$req_principal->Object->SetPrivileged(0);
}
}

The variables above represent these kind of objects:

$requestors - RT::GroupMembers
$req - RT::GroupMember
$req_principal - RT::Principal

This seems cumbersome, and maybe there’s a more streamlined way, but it
should do what you want. The if statement may be unnecessary ( I think
requestors are always users, not groups) but it doesn’t hurt.

Steve

8

$req_principal->Object->PrincipalObj->SetDisabled(1);

When You revoke “Let this user access RT” in effect you are disabling
the user’s
principal object.

Quoting Bill Chever wchever@terracottatech.com:

9

At Monday 6/19/2006 05:37 PM, Bill Chever wrote:

Alrighty then!

This is great information, Stephen. Thanks!

Only one problem - The right I want to revoke is the “Let this user access
RT” right, not “Let this user be granted rights” which is what gets changed
by the SetPrivileged. Is there a SetAccess equivalent?

Bill

Hi Bill,

You can track this down by starting at the Mason component for the
User “Basics” screen (share/html/Admin/Users/Modify.html). The
checkbox element is called Enabled, and in the Mason file’s INIT
section, this is used to set the user’s Disabled attribute
(UserObj->SetDisabled).

Steve

10

there a SetAccess equivalent?

Bill

Hi Bill,

You can track this down by starting at the Mason component for the User
“Basics” screen
(share/html/Admin/Users/Modify.html). The checkbox element is called
Enabled, and in
the Mason file’s INIT section, this is used to set the user’s Disabled
attribute (UserObj->SetDisabled).

Steve

Hi Steve,

Wow! I want to thank you for the help with this problem, but mainly for
pointing me to perldoc. Between that and the codebase listing on page 148
of RT Essentials, I now have more information than I know what to do with!
The product’s great, the help from the list is great, and now I have great
docs as well. Thanks again!

Bill