I am trying to set up a group in a queue that has the ability to change the status but not the owner; i.e. can’t steal/take it (a different group is assigning tickets to them and they’re not allowed to get out of it) but they need to be able to resolve their own tickets.
It seems to me that Steal and Take are subsets of ModifyTicket (i.e, if you have ModifyTicket you implicitly have Steal and Take) but I can’t figure out how to separate ownership changes from status changes. Is this possible?
Thanks -
Jon Baker
Systems Administrator
Church on the Move
1003 N 129th E Ave
Tulsa OK 74116
(918) 234-5656
CONFIDENTIALITY NOTICE: This transmission may be confidential and subject to legal privilege. If you are not the intended recipient of this message, you may not review, disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law.
Jon,
Remove the right to “OwnTicket” as well as “Steal” and “Take”. You can grant
the “ModifyTicket” to that group as well as “ShowTicket” and that way they
can See tickets in a Queue, Modify them, but not Own them.
Kenn
LBNLOn Wed, Feb 16, 2011 at 3:24 PM, Jon Baker jbaker@wgm.us wrote:
I am trying to set up a group in a queue that has the ability to change the
status but not the owner; i.e. can’t steal/take it (a different group is
assigning tickets to them and they’re not allowed to get out of it) but they
need to be able to resolve their own tickets.
It seems to me that Steal and Take are subsets of ModifyTicket (i.e, if you
have ModifyTicket you implicitly have Steal and Take) but I can’t figure out
how to separate ownership changes from status changes. Is this possible?
Thanks -
Jon Baker
Systems Administrator
Church on the Move
1003 N 129th E Ave
Tulsa OK 74116
(918) 234-5656
CONFIDENTIALITY NOTICE: This transmission may be confidential and subject
to legal privilege. If you are not the intended recipient of this message,
you may not review, disclose, print, copy or disseminate this information.
If you have received this in error, please reply and notify the sender
(only) and delete the message. Unauthorized interception of this e-mail is a
violation of federal criminal law.
Thanks for the reply, Kenn - I want the users to be able to be assigned the ticket by the admin, but I don’t want them to be able to change any ticket assignments themselves. So Joe is in the Users group, and Sam is in the Admin group. Sam needs to be able to assign ownership of a ticket to Joe. Joe needs to be able to resolve tickets. But Joe should not be able to assign the ticket to anyone else, nor should he be able to steal or take a ticket.
I’m going to see if I can figure out a way to do this with a Scrip unless there’s some permission voodoo that i’m missing.On Feb 16, 2011, at 8:10 PM, rt-users-request@lists.bestpractical.com wrote:
Jon,
Remove the right to “OwnTicket” as well as “Steal” and “Take”. You can grant
the “ModifyTicket” to that group as well as “ShowTicket” and that way they
can See tickets in a Queue, Modify them, but not Own them.
Kenn
LBNL
Jon Baker
Systems Administrator
Church on the Move
1003 N 129th E Ave
Tulsa OK 74116
(918) 234-5656
CONFIDENTIALITY NOTICE: This transmission may be confidential and subject to legal privilege. If you are not the intended recipient of this message, you may not review, disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law.
Thanks for the reply, Kenn - I want the users to be able to be
assigned the ticket by the admin, but I don’t want them to be able
to change any ticket assignments themselves. So Joe is in the Users
group, and Sam is in the Admin group. Sam needs to be able to
assign ownership of a ticket to Joe. Joe needs to be able to
resolve tickets. But Joe should not be able to assign the ticket to
anyone else, nor should he be able to steal or take a ticket.
I’m going to see if I can figure out a way to do this with a Scrip unless there’s some permission voodoo that i’m missing.
ModifyTicket implies being able to change the owner, so you’ll need to
enforce your no-changes rule elsewhere
-kevin> On Feb 16, 2011, at 8:10 PM, rt-users-request@lists.bestpractical.com wrote:
Jon,
Remove the right to “OwnTicket” as well as “Steal” and “Take”. You can grant
the “ModifyTicket” to that group as well as “ShowTicket” and that way they
can See tickets in a Queue, Modify them, but not Own them.
Kenn
LBNL
–
Jon Baker
Systems Administrator
Church on the Move
1003 N 129th E Ave
Tulsa OK 74116
(918) 234-5656
CONFIDENTIALITY NOTICE: This transmission may be confidential and subject to legal privilege. If you are not the intended recipient of this message, you may not review, disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law.
Jon,
Well, here’s a thought.
- For each Queue you want this type of situation, either make the
“assigner” the AdminCc, or create a group for just those users allowed to
assign tickets.
- Then create scrip for that Queue that is conditioned by “ChangeOwner” and
in the action section, check to see that the actor of this transaction is in
that “Assigner” group or that they are the AdminCc. If they are, allow the
change. If not, change the owner back.
That might work.
Kenn
LBNLOn Thu, Feb 17, 2011 at 8:26 AM, Kevin Falcone falcone@bestpractical.comwrote:
On Thu, Feb 17, 2011 at 08:06:03AM -0600, Jon Baker wrote:
Thanks for the reply, Kenn - I want the users to be able to be
assigned the ticket by the admin, but I don’t want them to be able
to change any ticket assignments themselves. So Joe is in the Users
group, and Sam is in the Admin group. Sam needs to be able to
assign ownership of a ticket to Joe. Joe needs to be able to
resolve tickets. But Joe should not be able to assign the ticket to
anyone else, nor should he be able to steal or take a ticket.
I’m going to see if I can figure out a way to do this with a Scrip unless
there’s some permission voodoo that i’m missing.
ModifyTicket implies being able to change the owner, so you’ll need to
enforce your no-changes rule elsewhere
-kevin
On Feb 16, 2011, at 8:10 PM, rt-users-request@lists.bestpractical.comwrote:
Jon,
Remove the right to “OwnTicket” as well as “Steal” and “Take”. You can
grant
the “ModifyTicket” to that group as well as “ShowTicket” and that way
they
can See tickets in a Queue, Modify them, but not Own them.
Kenn
LBNL
–
Jon Baker
Systems Administrator
Church on the Move
1003 N 129th E Ave
Tulsa OK 74116
(918) 234-5656
CONFIDENTIALITY NOTICE: This transmission may be confidential and subject
to legal privilege. If you are not the intended recipient of this message,
you may not review, disclose, print, copy or disseminate this information.
If you have received this in error, please reply and notify the sender
(only) and delete the message. Unauthorized interception of this e-mail is a
violation of federal criminal law.
I was able to sort of hack it into resetting the ownership if someone outside of the group attempts to change it. I created a scrip on “Owner Change” with the following custom action:
my $GroupObj = RT::Group->new( $RT::SystemUser );
$GroupObj->LoadUserDefinedGroup( ‘IT Admin’ );
my $PrincipalObj = RT::Principal->new( $RT::SystemUser );
$PrincipalObj->Load( $self->TransactionObj->Creator );
if($GroupObj->HasMemberRecursively($PrincipalObj)) {
IT Admin is allowed to change the owner.
return;
} else {
if ($self->TransactionObj->Creator != 1) {
# User 1 is the RT system, if we’ve recursed into here we don’t want to do it again
$self->TicketObj->SetOwner($self->TransactionObj->OldValue,‘Force’);
}
}
Looks like that is doing the job.
I am trying to set up a group in a queue that has the ability to change the status but not the owner; i.e. can’t steal/take it (a different group is assigning tickets to them and they’re not allowed to get out of it) but they need to be able to resolve their own tickets.
It seems to me that Steal and Take are subsets of ModifyTicket (i.e, if you have ModifyTicket you implicitly have Steal and Take) but I can’t figure out how to separate ownership changes from status changes. Is this possible?
Thanks -
Jon Baker
Systems Administrator
Church on the Move
1003 N 129th E Ave
Tulsa OK 74116
(918) 234-5656
CONFIDENTIALITY NOTICE: This transmission may be confidential and subject to legal privilege. If you are not the intended recipient of this message, you may not review, disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law.
That’s what I ended up doing and it looks like it’s working great. Here’s the scrip action that I ended up using in case anyone else is looking for the solution:
my $GroupObj = RT::Group->new( $RT::SystemUser );
$GroupObj->LoadUserDefinedGroup( ‘IT Admin’ );
my $PrincipalObj = RT::Principal->new( $RT::SystemUser );
$PrincipalObj->Load( $self->TransactionObj->Creator );
if($GroupObj->HasMemberRecursively($PrincipalObj)) {
IT Admin is allowed to change the owner.
return;
} else {
if ($self->TransactionObj->Creator != 1) {
User 1 is the RT system, if we’ve recursed into here we don’t want to do it again
$self->TicketObj->SetOwner($self->TransactionObj->OldValue,‘Force’);
}
}On Feb 17, 2011, at 12:13 PM, rt-users-request@lists.bestpractical.com wrote:
Jon,
Well, here’s a thought.
- For each Queue you want this type of situation, either make the
“assigner” the AdminCc, or create a group for just those users allowed to
assign tickets.
- Then create scrip for that Queue that is conditioned by “ChangeOwner” and
in the action section, check to see that the actor of this transaction is in
that “Assigner” group or that they are the AdminCc. If they are, allow the
change. If not, change the owner back.
That might work.
Kenn
LBNL
Jon Baker
Systems Administrator
Church on the Move
1003 N 129th E Ave
Tulsa OK 74116
(918) 234-5656
CONFIDENTIALITY NOTICE: This transmission may be confidential and subject to legal privilege. If you are not the intended recipient of this message, you may not review, disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law.
Jon:
Another way to achieve what you want and eliminate having to set owner then revoke it via the script is by modifying
/Elements/SelectOwner
Just get it to return the owner name as a string if the $session{‘CurrentUser’} is not a member of the IT Admin group.
Else If CurrentUser IT Admin then display the Owners dropdown.
The only reason I am suggesting this, is because many times my users do not realise an action have been rolled back automatically via the system.
Regards;
Roy
I’m a little hesitant to change the source code just because I know I’ll forget I did it when I install the next update - also, this is only affecting one queue. I’m also not too concerned as it is the IT Staff group that is being assigned the tickets, and they are told not to change the ownership. If it was something for the general user base I could definitely see the possibility for confusion.
I wonder, is there a way in the scrip to push to the message stack that displays at the top after the transaction has happened?On Feb 17, 2011, at 12:40 PM, Raed El-Hames wrote:
Jon:
Another way to achieve what you want and eliminate having to set owner then revoke it via the script is by modifying
/Elements/SelectOwner
Just get it to return the owner name as a string if the $session{‘CurrentUser’} is not a member of the IT Admin group.
Else If CurrentUser IT Admin then display the Owners dropdown.
The only reason I am suggesting this, is because many times my users do not realise an action have been rolled back automatically via the system.
Regards;
Roy
Jon Baker
Systems Administrator
Church on the Move
1003 N 129th E Ave
Tulsa OK 74116
(918) 234-5656
CONFIDENTIALITY NOTICE: This transmission may be confidential and subject to legal privilege. If you are not the intended recipient of this message, you may not review, disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law.