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:
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"
3. Unprivileged: none. This entity does not exist in our system.
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
“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.
“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:
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.
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
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.
LBNLOn 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:
User defined groups: Management
There’s also an RT-Admin group to manage users and RT configs:
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
Configuration -> Queues -> Telecom -> Watchers:
Configuration -> Queues -> Telecom -> Group Rights:
User defined groups: Telecom
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