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@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