[rt-users] Special Projects Queue

[Kenneth Crocker]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110714/5f90d323/attachment.htm>