[rt-users] Cannot assign ticket

Tue May 9 12:44:29 EDT 2006

Kenn, 

Thanks for the details.  Unfortunately, it doesn't work for me.  What
version of RT are you running?

Bill

-----Original Message-----
From: Kenneth Crocker [mailto:KFCrocker at lbl.gov] 
Sent: Monday, May 08, 2006 8:56 PM
To: William Catlan
Cc: Ruslan Zakirov; rt-users at lists.bestpractical.com
Subject: Re: [rt-users] Cannot assign ticket

William Catlan wrote:
> Kenn,
>
> I appreciate the confirmation that the feature works.  I have tried a
> number of different ways, including the more granular use of
permissions
> at the queue level.
>
> Can you share the exact permissions you give to a group to allow them
to
> assign an owner to a ticket using People -> Owner driop down, as well
as
> the exact permissions you give to a group to allow them  to be
assigned
> a ticket?
>
> I think I've tried all reasonable configurations, and it is not
working
> for me. My version of RT is 3.4.5 ... what version are you running?
>
> Thanks,
>
> Bill
>   
>
> -----Original Message-----
> From: Kenneth Crocker [mailto:KFCrocker at lbl.gov] 
> Sent: Friday, May 05, 2006 2:21 PM
> To: William Catlan
> Cc: Ruslan Zakirov; rt-users at lists.bestpractical.com
> Subject: Re: [rt-users] Cannot assign ticket
>
> William Catlan wrote:
>   
>>> 3.6. Assigning a Ticket
>>>
>>> Tickets can have an owner-the user responsible for working on the
>>>     
>>>       
>> ticket or
>>   
>>     
>>> for coordinating the work. To assign a ticket to someone, go to the
>>>     
>>>       
>> People
>>   
>>     
>>> form from the ticket display page, and select the user from the
Owner
>>> drop-down list, as shown in Figure 3-7. This list contains the
>>>     
>>>       
>> usernames of
>>   
>>     
>>> all the users allowed to own tickets in the ticket's current queue.
>>>
>>> I try this, and only "Nobody" appears as an option.
>>>     
>>>       
>> Grant right OwnTicket to groups/users who should be able to
OwnTicket.
>> http://wiki.bestpractical.com/?OwnTicket
>>
>> Thanks Ruslan.  Of course, I did grant that right to a group, at both
>> the Queue and Global levels, along with SeeQueue, but I still could
>>     
> not
>   
>> assign a ticket to someone in the group.
>>
>> I am hoping that someone will confirm this is a bug, or show me
>> something I missed.
>>
>> Bill
>> _______________________________________________
>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>
>> Community help: http://wiki.bestpractical.com
>> Commercial support: sales at bestpractical.com
>>
>>
>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
>> Buy a copy at http://rtbook.bestpractical.com
>>
>>
>> We're hiring! Come hack Perl for Best Practical:
>>     
> http://bestpractical.com/about/jobs.html
>   
>>   
>>     
> Bill,
>
>         If you already have a group with the correct permissions to
see 
> a ticket (seeQueue, SeeTicket, etc.) for a specific Queue, why in the 
> world do you also grant any global rights at all? The whole point of 
> making a Queue have group specific rights allows much more specific 
> de-bugging when it comes to problems like this,. I think too many
users 
> of RT use the "shotgun" approach to granting rights and privileges. 
> GLobal stuff just might be negateing any Queue specific group rights. 
> It's almost like a programmer who isnb't sure he checked for something

> in his code so he puts the same code that does the checking all over
the
>
> progrm. It's redundant and makes everything much more difficult to 
> debug. I think you need to go back to the drawing board on rights and 
> decide how to tighten up the rights by being specific, not global and 
> then see what you get and debug from there. That is how ours is set up

> and we have 23 Queues (for individual IT software support groups ) and

> more than twice than many groups (1 group for technical support of an 
> application and 1 group for the user - who get less rights). Plus, we 
> have created an approval workflow that allows for a specific Queue to 
> hande the review/approval/rejection process for several other Queues
and
>
> ALL work and documentation stays with the original ticket number, even

> though the original ticket make be moved to different Queues. This 
> cannot be done when you have a bunch of shotgun/global rights floating

> around. Hopes this concept helps.
>
> Kenn
>
>   
Will,

    This will take a bit of time to walk thru but, here goes. First, we 
create a Queue (meaningful name - of course). Someone who is a superuser

must do this. Then we set up globally (for each person assigned as the 
AdminCC of said Queue) one roght only "SeeConfigTab". This allows the 
AdminCc to administrate his own Queue. We also set up globally for 
"everyone" all the CreateSavedSearch, EditSavedSearch, etc proviliges.).

For global stuff, that's it. Now, create a group and name it for it's 
function pertaining to the Queue your going to give it rights to, ie. 
Queuename-Technicians, or Queuename-Support, Queuename-users. By 
creating groups, you save yourself the redundant effort of setting up 
individuals with the same rights to the same Queues. So. create a group.

Then add some members. Remember, you can have any number of groups with 
different or the same rights to a Queue. Once you have created the group

and populated it, give each group it's own set of priviliges as pertains

to A single Queue. So you go into Configuration (the same superuser is 
doing this), then Queue, pick the Queue, then slip down to group rights 
(on the lefthand side of the screen) and click that. These rights all 
pertain to the Queue level only so we give everyone the right to see 
outgoing mail. Sometimes, depending on the group, we give privilidged 
user the right to create tickets (most of our Queue administrators don't

want that. They want only specific groups to have that right). We don't 
allow unprivileged users anything. At the Role level (think of a role as

a psuedo group) CC's are watchers (we give them seeQueue, seeTicket,  
ReplyToTicket, and Watch). Requestors  are creators of tickets (we give 
them CreateTicket, if that hasn't been given to all privileged users, 
all of the CC stuff and maybe let them make or see comments, depending 
on if they are users or supporter or technicians). AdminCc gets it all 
except we don't let them create script or templates (we reserve that 
right for the System Administrator - keeps redundant scripts and stuff 
off the system). Then there are owners. We consider them the technicians

or supports of a Queue so they get more rights as pertains their work 
(Comment on a ticket, create ticket, delete a ticket, own ticket, modify

ticket, take a ticket and all the right given a requestor). Then, we 
grant a mix of rights to whatever groups we have created that will 
pertain to the Queue, just like we did with the roles (except, of 
course, the AdminCc). You can get a list of the rights and stuff on 
Wiki. I hope this help you figure it out. OH. Also, at the Queue level, 
we NEVER grant an individual ANY rights. Period.  See ya.

Kenn