[rt-users] Rights, rights, rights...

[Kenneth Crocker]

Jean-Sebastien,


	It looks better, that's for sure. Let me show what I have, with an 
explanation for why, and you can take it from there, Obviously, every 
installation will have it's different infrastructure needs, but on the 
whole, what I'm doing and (more importantly) WHY will provide more 
instruction and understanding of how these rights work. I'm absolutely 
sure that anyone who has used RT with more than 10 queues (especially 
for technical support) for more than a couple years would be able to 
show you the same stuff as I'm about to. Here we go:

Global Rights:
	1. Everyone: none. We only allow privileged users to use our system and 
anyone with an LDAP userID and password can sign on and become one.
	2. Privileged: "CreateSavedSearch", "EditSavedSearch", 
LoadSavedSearch", "ShowSavedSearch", and "ModifySelf". With the 
exception of "ModifySelf", these rights get (to use your term) INHERITED 
the moment a user has the rights to see tickets in a queue. Rather than 
setting up these rights at the queue level for specific groups or roles, 
I did it once at the Global level because without the rights to see 
tickets at the queue level, they are meaningless. That way, I can focus 
on ticket rights at the queue level without adding search rights. 
"ModifySelf" is required for us because we want people (LDAP) to be able 
to sign-in themselves and this right allows that within our "AutoCreate" 
set up.
	3. Unprivileged: none. This entity does not exist in our system.

Roles:
	1. AdminCc: We use the AdminCc as a "Queue Manager". So there are some 
rights we grant globally because it would be redundant at the queue 
level and some at the queue level for security reasons. For example, if 
we granted "ModifyTicket" for the AdminCc at the Global level, then this 
person could modify a ticket in a queue they do NOT manage.
	"AdminGroupMembership" - we allow our Queue managers to add users to 
any group they see fit. It's based on their own need and that way I 
don't have to go around adding users to groups all the time. Let them do 
the work.
	"AssighCustomFields" - we grant this right because we don't want Tom, 
Dick, and Harry creating a bunch of misnamed, misused, redundant Custom 
Fields and then have to undo the mess. This allows the AdminCc to see 
any and all Custom Fields and use what they need for their queue.
	"DelegateRights" - we grant this right because it allows the AdminCc to 
"grant" rights (up to and only those granted TO the AdminCc) to groups 
that will be accessing that particular queue.
	"ModifyACL" - This allows the AdminCc to modify any ACL (Access Control 
List) that they create.
	"ModifyOwnMembership" - allows modification of membership of any group.
	"SeeGroup" - We want all Queue managers/AdminCc's to see all groups. 
They may need to give one rights to their queue and I don't want to have 
to do it.
	"ShowConfigTab" - AHA! This is the right that saves me time as it 
allows our Queue Managers to do some of this work (i.e. 
AdminGroupMembership).
	"ShowScrips" - We want our Queue Managers to know what's scrips are 
blobal and that way they can use them as examples for any "queue-level" 
scrip they want to add to their own queue.
	"ShowTemplate" - same as above.
	"WatchAsAdminCc" - This gives the right to add oneself as an "AdminCc" 
of any ticket and therefore receive any correspondence that is normally 
sent to AdminCc's due to scrips for tickets in that queue. Although this 
seems like it should be at the queue level, we grant the AdminCc a 
certain amount of freedom. Let's say they are interested in a ticket 
they depend on, but is NOT in their queue. They may want to see the 
correspondence going on for that ticket.
	2. CC: For us, a CC is an "interested" party that wants to receive 
communication of what's going on in a queue.
	"ReplyToTicket" - this allows all CC's for all queues to reply to any 
correspondence that is sent to them, regardless of queue. Usually, they 
only get the correspondence for the queue they are listed as CC for, so 
there's no problem. However, if they are listed as a CC on a ticket in a 
different queue and received email from a ticket, they could now reply.
	"SeeQueue" - the CC can look at what tickets are in the queue via 
WebUI. By making this right global, it is "inherited" by the CC listed 
as a CC watcher for a queue.
	"ShowTicket" - the CC can look at each individual ticket in that queue. 
By making this right global, it is "inherited" by the CC listed as a CC 
watcher for a queue.
	"Watch" - the CC can add themselves as the CC on any ticket they might 
be interested in.
	3. Owner: For us, this is the person that works on the request ticket. 
Makes modifications to the ticket to show progress, change status, 
dates, etc. "THERE CAN BE ONLY ONE!". For you "highlander" fans, we feel 
that the only person who should have complete modification rights to a 
ticket is the owner (and maybe the Queue manager/AdminCc). Therefore, we 
grant this right globally to save us the queue level maintenance. When 
we create a new queue for a new software application, we DON'T have to 
grant this right.
	4. Requestor: For us, this is the person making the request/sending in 
a email ticket. We want certain rights to be inherited at the queue 
level for all requestors, regardless of queue.
	"ReplyToTicket" - the ability to correspond about their OWN ticket.
	"SeeQueue" - the ability to see their ticket in the queue it was sent to.
	"ShowTicket" - the ability to "see" their ticket, depending on what 
rights are granted to the requestor at the queue level. For example, one 
Queue Manager/AdminCc may grant the right to "ShowTicketComments" and 
another may not. So this global right will not grant them the right to 
see comments or outgoing email or to comment on a ticket, etc.
	"Watch" - As the requestor of "their" ticket, we want them to inherit 
the ability to add an interested party as a "cc" on "their" ticket.


Queue-Level Rights: On a queue by queue basis, we let the Queue 
Manager/AdminCc grant/modify/remove certain rights for System level 
users, Roles, and user-defined groups. An example of these rights follows:

System Groups:
	1. Everyone: none.
	2. Privileged: "CreateTicket". This right is not granted on the global 
level because there are some queues that do NOT WANT to get tickets from 
just anyone. So we let them decide. If they do, they grant that 
privilege here. If not, they grant it to certain user-defined groups.
	3. UnPrivileged: none.

Roles:
	1. AdminCc; Again, for us, the AdminCc is the "BOSS" of a queue. They 
create, assign, delete tickets. We grant these rights at the queue level 
because it might cause trouble at the global level (or already HAS):
	"CreateTicket" - the AdminCc of a queue should be able to create ticket 
for their own support team/group.
	"DeleteTicket" - same as above.
	"ModifyACL" -  Same as global right but at queue-level. This keeps 
AdminCc's of other queues from messing with the rights in other queues.
	"ModifyQueueWatchers" - again, for THIS queue, we want the AdminCc to 
decide who can use "their" queue.
	"ModifyTickets" - This allows the queue manager to override dates, etc. 
on a ticket in the queue they manage, not just the owner.
	"ShowACL" - let's the boss see what's up in "their" queue.
	"StealTicket" - the boss can also "re-assign" a ticket to a different 
team/group member.
	2. CC; usually none. We do have a few queues where the AdminCc wants 
the CC to see any correspondence they get so they grant "WatchAsAdminCc".
	3. Owner; Maybe "DeleteTicket". It depends on how the AdminCc wants to 
manage the tickets. Sometimes only the AdminCc can delete a ticket.
	4. Requestor; In addition to the global rights they inherit, the 
AdminCc may allow them to:
	"CommentOnTicket" - this let's the requestor add their own comments to 
a ticket without letting them "Modify" a ticket in other areas.
	"ShowOutgoingEmail" - this allows the requestor to see the 
correspondence on a ticket. Some queue managers may NOT want that.
	"ShowTicketComments" - this allows the requestor to see the comments 
made on a ticket. Some queue managers may NOT want that (nasty comments 
about the IQ of the requestor) so it isn't granted at all.

User-Defined Groups: For each queue (1 queue per application software), 
there is (usually) 1 or more user groups that can send/create tickets. 
There is only 1 group that is allowed to do the technical support. So, 
the rights granted a specific to queue/function.
	1. User (requeator) group: these are the users that the queue manager 
allows to create request tickets. Their rights are:
	"CommentOnTicket" - well, maybe. Depends on the boss.
	"CreateTicket" - well, duh. that's the whole point here.
	"ReplyToTIcket" - this may seem redundant to the same right for 
requestors. NOT. It allows OTHER members of the requestor users group to 
respond to ticket correspondence on ticket they did NOT send/create. If 
the ticket is part of a project that has bunchs of children and 
dependencies, I may want all members ot that request "group" to 
participate at this level.
	"SeeQueue" - allows all members of the group (not just the requestor) 
to see what's in the queue.
	"ShowOutgoingEmail" - this allows the group to see the correspondence 
on a ticket. Some queue managers may NOT want that.
	"ShowTicket" - this allows the group to see any ticket in the queue. 
Some queue managers may NOT want that.
	"ShowTicketComments" - this allows the group to see the comments made 
on a ticket. Some queue managers may NOT want that (nasty comments about 
the IQ of the requestor) so it isn't granted at all.
	"Watch" - same as global right but just for this queue/group.

	2.Support group (usually technical support): we have only one of these 
per queue. We don't want others fooling around and messing with tickets 
they are not supporting.
	"CommentOnTicket" - everyone in the group can add their comments to any 
ticket in the queue. Support on a project level may easily need this.
	"CreateTicket" love those children.
	"OwnTicket" - obvious.
	"ReplyToTicket", "SeeQueue", "ShowOutGoingEmail", "ShowTicket", 
"ShowTicketCOmments", "StealTicket" (maybe. if the boss allows), 
"TakeTicket", "Watch" - these are all pretty self explanatory and we 
want our support team to be able to have them.

	Anyway, after reading this you should be able to evaluate your needs 
(in terms of rights) a little better. Hope it helps.


Kenn
LBNL



On 2/7/2008 7:09 AM, Jean-Sebastien Morisset wrote:
> On Wed, Feb 06, 2008 at 11:19:48AM -0800, Kenneth Crocker wrote:
>> 	Whew! You have really given alot of people alot of rights.
> 
> Kenneth and Ruslan,
> 
> Thanks for your feedback! I did a lot of testing, and wasn't sure if you
> inherited rights or not, so many of the basic rights were duplicated.
> Thanks for explaining that bit. :-)
> 
> Ok, so a brief description of our processes is in order... It's very
> simple really... Anyone can open a ticket. Requestors should be able to
> view and reply to their own ticket. Anyone else should be able to view
> all tickets, add themselves as CC, but not modify tickets that aren't
> theirs. We have 3-4 queues, and most of the requests will be coming in
> by e-mail, sorted (by procmail), and a ticket opened in the appropriate
> queue. Specific groups, like "Telecom" for example, have priviledges to
> work on tickets in their own queue (also called "Telecom"). They should
> also be able to transfer tickets to other queues in case someone sent
> their e-mail to the wrong queue. The "Management" group should have the
> ability to modify any ticket in any queue.
> 
> So, in a nutshell, that's about it.
> 
> After your comments, I made the following adjustments:
> 
> Configuration -> Global -> Group Rights:
> 
> Everyone   
>     CreateTicket
>     SeeCustomField
>     
> Privileged	
>     CreateSavedSearch
>     CreateTicket
>     EditSavedSearches
>     LoadSavedSearch
>     ModifySelf
>     SeeCustomField
>     SeeGroup
>     SeeQueue
>     ShowSavedSearches
>     ShowTicket
>     Watch
> 
> User defined groups: Management
>     ModifyQueueWatchers
>     ModifyTicket
>     OwnTicket
>     ReplyToTicket
>     ShowACL
>     ShowOutgoingEmail
>     ShowScrips
>     ShowTemplate
>     ShowTicketComments
>     StealTicket
>     TakeTicket
>     WatchAsAdminCc
> 
> There's also an RT-Admin group to manage users and RT configs:
> 
> RT-Admin   
>     AdminAllPersonalGroups
>     AdminCustomField
>     AdminGroup
>     AdminGroupMembership
>     AdminOwnPersonalGroups
>     AdminQueue
>     AdminUsers
>     AssignCustomFields
>     ModifyACL
>     ModifyCustomField
>     ModifyOwnMembership
>     ModifyQueueWatchers
>     ModifyScrips
>     ModifyTemplate
>     ModifyTicket
>     ShowACL
>     ShowConfigTab
>     ShowOutgoingEmail
>     ShowSavedSearches
>     ShowScrips
>     ShowTemplate
>     ShowTicket
>     ShowTicketComments
> 
> For each Queue ("Telecom" in this example), I have additional rights for
> the associated group. I've specified some AdminCCs by default because
> we're transitioning from an e-mail based process. Eventually I'll remove
> the AdminCCs and create a Scrip/Template to e-mail the group members
> when a ticket is created in their queue. After that it'll be up to them
> to decide if they want to own the ticket or add themselves as Ccs or
> AdminCcs.
> 
> Configuration -> Queues -> Telecom -> Watchers:
> 
> Administrative Cc:
>     Telecom
>     Management 
> 
> Configuration -> Queues -> Telecom -> Group Rights:
> 
> User defined groups: Telecom
>     CommentOnTicket
>     ModifyTicket
>     OwnTicket
>     ReplyToTicket
>     ShowOutgoingEmail
>     ShowTicketComments
>     StealTicket
>     TakeTicket
>     WatchAsAdminCc
> 
> BTW, I appreciate your time with this. The faster I can tweak this
> config, the better chance it'll be adopted. Our current e-mail based
> process has to go... :-)
> 
> I should also mention that I've configured the ___Approval queue. For
> some reason it's showing up on the user's home page. I thought the
> ___Approval queue would be hidden... Should it be?
> 
> I'm still tweaking the approval process. There's some conflicts between
> the global scrips and the approval queue scrips. For example, the global
> scrip "On Create Notify AdminCcs with template Transaction" and the
> ___Approval queue scrip "On Create Notify AdminCcs with template New
> Pending Approval". It looks like I'll have to move that global scrip
> into each queue instead to avoid duplicate e-mails with the ___Approval
> queue.
> 
> Thanks!
> js.