Yan,<br><br>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.<br>
<br>Just a thought. Hope it helps.<br><br>Kenn<br>LBNL<br><br><div class="gmail_quote">On Thu, Jul 14, 2011 at 8:34 AM, Yan Seiner <span dir="ltr"><<a href="mailto:yan@seiner.com">yan@seiner.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I am setting up a special projects queue.  We have several "special<br>
projects" which involve a team of about 8-10 people from both inside and<br>
outside the company.  The basic idea is that each project gets a root<br>
ticket in the queue, with the team members set up as adminCCs.  The<br>
adminCCs have a broad range of rights on the tickets, including setting<br>
watchers, modifyihg the ticket, etc.<br>
<br>
The idea is that each special project uses the root ticket and creats<br>
child tickets under it.  This works pretty well, except....<br>
<br>
Once the root ticket is set up with the correct adminCCs, creating a child<br>
ticket should mean tha the adminCCs are inherited.  For some unfathomable<br>
reason, it seems that only some of the adminCCs are being inherited; the<br>
rest get a "•Couldn't set AdminCc watcher: Permission Denied" error.  I<br>
have been all through the users and there doesn't seem to be any<br>
difference in any of the users or the permissions.  All priveledged users<br>
have "watch" and "watch as adminCC" rights.<br>
<br>
I don't understand why only some of the users are being denied.  Is there<br>
a way to get a more verbose error?<br>
<br>
<br>
--------<br>
2011 Training: <a href="http://bestpractical.com/services/training.html" target="_blank">http://bestpractical.com/services/training.html</a></blockquote></div><br>