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 <[email protected]> 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 -------- 2011 Training: http://bestpractical.com/services/training.html
