[rt-users] Special Projects Queue

[Yan Seiner]

That's what I normall do...

This is a special case.  We have a project that will run several years,
and involve several consultants, and probalby spawn a few hundred (or
more) tickets.  I may need to give some people permissions to see some
tickets nad not others.  I thought I had it figured out with this, but I
obviously don't.

I'm struggling with how to integrate people from outside the organization
into a coherent team using RT...

I'm not as familiar with permissions as I should be.  I'm getting better,
but still....

:-)

On Thu, July 14, 2011 9:29 am, Kenneth Crocker wrote:
> Yan,
>
> My personal preference is to put any group of ticket owners, team members,
> those with similar permission needs, etc. into a User-defined group per
> Queue. They can have all of the permissions you could grant a role. The
> main
> reason I like that is because when it comes to emails, I really like to
> differentiate between "Groups of Ticket Owners, team members, etc." and
> the
> REAL Admin person that may want to see some emails, just not all of them.
> By
> putting all these members into the AdminCc role, it promts the question of
> "where do you put the REAL AdminCc"? I have many situations where the
> Admin
> of a support group doesn't want all the notices, but they want the team
> members to be aware, etc. It's just a way for me to look down the line in
> the future and say "What if I have to differentiate these people"? By
> doing
> it the way I do, I CAN differentiate when I need to. I already have them
> separated by Group/role rather than clumping them together. This might
> allow
> you to debug your current situation as well, especially if you granted
> some
> of these "AdminCc" roles GLOBAL rights.
>
> Just a thought. Hope it helps.
>
> Kenn
> LBNL
>
> On Thu, Jul 14, 2011 at 8:34 AM, Yan Seiner <yan at seiner.com> wrote:
>
>> I am setting up a special projects queue.  We have several "special
>> projects" which involve a team of about 8-10 people from both inside and
>> outside the company.  The basic idea is that each project gets a root
>> ticket in the queue, with the team members set up as adminCCs.  The
>> adminCCs have a broad range of rights on the tickets, including setting
>> watchers, modifyihg the ticket, etc.
>>
>> The idea is that each special project uses the root ticket and creats
>> child tickets under it.  This works pretty well, except....
>>
>> Once the root ticket is set up with the correct adminCCs, creating a
>> child
>> ticket should mean tha the adminCCs are inherited.  For some
>> unfathomable
>> reason, it seems that only some of the adminCCs are being inherited; the
>> rest get a "•Couldn't set AdminCc watcher: Permission Denied" error.  I
>> have been all through the users and there doesn't seem to be any
>> difference in any of the users or the permissions.  All priveledged
>> users
>> have "watch" and "watch as adminCC" rights.
>>
>> I don't understand why only some of the users are being denied.  Is
>> there
>> a way to get a more verbose error?
>>
>>
>> --------
>> 2011 Training: http://bestpractical.com/services/training.html
>
>
> !DSPAM:4e1f19a5320121480513369!
>
> --------
> 2011 Training: http://bestpractical.com/services/training.html
>
> !DSPAM:4e1f19a5320121480513369!
>


-- 
My daughter is racing a triathlon to raise money for her swim club.  Want
to help?

http://akari.seiner.com