View source for Rights

This article describes RT security management aspects.

= Introduction =

== Groups ==

RT has different types of [[Group]]s that identify specific groups of system users. For security management, the public (user-defined) groups are the most important.

== Objects ==

RT manipulates different objects: [[Ticket]]s, [[Queue]]s, [[Scrip]]s, [[Template]]s, [[CustomField]]s, Users, [[Group]]s, etc. Each object takes a different place in the object tree. For example, scrips can either be global- or queue-specific, but tickets are always associated with a queue. Each object has a set of defined rights. To perform a particular action on an object, a user must have the appropriate rights. For example, if you want to create a ticket in queue A, you should have the [[CreateTicket]] right on queue A (or on all queues). Other types of rights, such as [[AdminGroup]], are not queue-specific.

In general, it is possible to grant each user rights on each small object like a scrip named 'foo' or a Template named 'bar.' But, such a setup would be difficult to maintain, and would require an overly-complex user interface. Instead, the RT user interface gives access to rights that are '''system-wide''', rights that can be assigned on a '''group by group''' basis, and other rights that can be assigned on a '''queue by queue''' basis. All objects have a context. For example, if Scrip A is a global scrip (system-wide), you can grant users rights on this object in the global context. Each right can be tied to more then one context and the interpretation of the right can be different in the different contexts. For example, the [[AdminQueue]] right in two different queues can be given to different groups of users.

'''Note''': I forgot about rights that change behavior in different contexts when I started all this. Maybe I'll recheck this all. Feel free to change descriptions if you <u>know</u> the real situation. --Ruslan

= Descriptions =

* [[QueueSpecificRights]]
* [[GroupSpecificRights]]
* [[GlobalRights]](with full index)

= Working schemas =

This chapter introduces several working schemas which can be used as template in different situations.

== Public support queue ==

Let start from the beginning. We have recently created queue 'support' that is for our public queue and group 'SupportTeam' of which members support our customers. Goto 'Configuration' tab -&gt; '[[Queue]]s' -&gt; 'support' -&gt; '[[Group]] rights' - it's the place where we'll do all the things that are described below. Then follow the step by step descriptions:

* We should grant all users with [[CreateTicket]] on queue 'support'.
* '''Important:''' It's a public queue and users often use different email addresses to reply to same ticket, so if you don't grant [[Everyone]] with [[ReplyToTicket]] right then your users would have problems in such a case.
* You don't need to grant other system [[Group]]s with same rights because [[Everyone]] includes all users.
* If some of your internal groups shouldn't have [[ReplyToTicket]] right, then you can assign it to [[Unprivileged]] and some internal groups.

* If you wish to allow public access to the Web UI([[SelfService]]) then you will also want the following rights to be granted to [[Everyone]] [[Group]]:
*# [[SeeQueue]] that allows them to see queue 'support' in select boxes('create ticket in' box, 'search criteria' box and etc).
*# [[ShowTicket]], without this right users can't see tickets in Web UI, but can reply with email. Below we'll see when we don't need this right granted to [[Everyone]].

* Your customers are [[Requestor]]s so grant requestor role with rights:
*# [[ReplyToTicket]]
*# [[ShowTicket]], it's an overhead grant but if we revoke this right from [[Everyone]] some day then requestors still would have ability to see tickets which they had request. Now, with one right([[ShowTicket]] for [[Group]] [[Everyone]]) you can control requestor's ability to see other's requests.

* Scroll to group 'SupportTeam' and grant the following rights:
*# [[SeeQueue]], [[ShowTicket]] same reasons as for group [[Everyone]].
*# [[OwnTicket]], each support team member works only on their own tickets. It's an advantage that RT has over IMAP folders used for public support. Your workers don't spend their time answering the same ticket.
*# [[TakeTicket]], allows group members to take ticket from nobody.
*# [[DeleteTicket]], your public support queue can't live without it in most cases because of spam.

* Now we can use Roles to grant owners with remaining rights. Scroll to Owner role and grant:
*# [[ModifyTicket]], this allows much, see right description, but you need this for ticket status change.

=== Trick with comments ===

RT has comments which allow internal teams disscussion inlined into ticket's body. Grant rights [[ShowTicketComments]] and [[CommentOnTicket]] to 'SupportTeam' [[Group]] and to other groups who can help support team in different cases(for eg 'DevelopmentTeam').

=== Tricks with [CC]s/[AdminCC]s ===

Sometimes it's necessary to watch others' tickets. For example there is now discussion on a problem in some ticket and a worker has their own requests with similar problem then it would be good to watch on that ticket and do other job until it is resolved. Grant support team with [[Watch]] right.

Also you can consider next schema with watchers: Customer sends request. Supporter can't resolve problem(unknown yet) on his own. He does standard things(request for more info, report with spec tool and so on from user), when supporter thinks that user has provided all needed info, he comments on ticket and at the same time adds developer as [[CC]].

Special [[CustomField]] where supporter can setup value which means "awaiting reply from developer" helps a lot too, because developer can search all tickets where he is watcher and ticket wait for his reply/comment. This CF can be filled with other useful ticket states.

[[AdminCC]]s can have more rights, for example reply directly to user with correspondence or modify ticket. It can be other teams who know standard reply forms and can solve particular problems or this role can be given to support department managers. If necessary grant [[Group]]s with [[WatchAsAdminCc]] right.

== Departments of a company as groups ==

[[Group]]s page describe simple example of using groups to manage rights of the stuffs who work in different departments in your company. Let's build more complex and universal variant.

Split your privileged users with top level groups: one for your full time staffs, one for part time and on for privileged clients. '''Don't skip this step''' even if you think all your clients would be unprivileged, once when you will need this it would be able to do in one or two clicks instead of refactoring whole rights schema. This groups could be:

* Team
* External team(part time)
* Clients
* ...add your own

When you have created top level groups you can add groups and users to it, but don't hurry to add users, read more and you will understand that it's better to add user to one particular group. Create group for each department, may be you don't have "strict" departments in your company, but anyway usually people do different tasks: managers, developers, support, sales, PR... This people should see only that info that does make sense for them and helps them do thier job effectively, they shouldn't fill special search conditions to hide tickets that they don't ever want to see. This groups could be:

* DevelopmentTeam
* SupportTeam
* SalesTeam
* ...add your own

Department groups should be member of the "Team" top-level group. This allow you to grant all in your team with particular set of rights. If you don't add department group to the top-level group, then you have to add your new users into two groups at least to mark that user is a team member and works in specific department.

For example RT can be used as mailing list, you just create "internal" queue and use it as internal discussions forum. In this situation "team" group will help you to grant rights on the queue easy. You can use RT-Action-[[NotifyGroup]] module to make this queue looks more like mailing list, you should setup scrip that will notify group 'Team' on any transaction(or some particular transactions if you want).

Department managers usually should be able to do more with department's tickets than other members. Create new groups for managers as members of the departments groups, so your managers would be able to do everything other in department could do, but also you'd be able to grant them additional rights. Additional group for manager(s) allow you to change managers easy, for example if you change manager in XX department then you just disable old manager account or move it to other group and add another user into group and this is all you need to do, you don't need to assign any rights or revoke.

You can notify managers about special events with RT-Action-[[NotifyGroup]] module. For example you can build next workflow: if owner of the ticket is member of the "[[SupportTeam]]" and transaction is correspond notify members of the "[[SupportManagers]]" with template "reply for managers", this template could collect additional info like time gone since last user message, manager(s) get such messages and could control that support team reply to all customers in 48 hours period(or whatever period you use).

Grant your managers with [[DelegateRights]] and [[AdminOwnPersonalGroups]] right, this will allow them to delegate their responsibilities to other users when it's required.

To summarize all thoughts here is example of the groups tree:

* [[Everyone]]
** [[Unprivileged]]
** [[Privileged]]
*** Team(group)
**** SupportTeam(group)
***** team member(user)
***** team member(user)
***** team member(user)
***** ...
***** SupportManagers(group)
****** manager(user)
****** manager(user)
****** ...
**** DevelopmentTeam(group)
***** team member(user)
***** team member(user)
***** team member(user)
***** ...
***** DevelopmentManagers(group)
****** manager(user)
****** manager(user)
****** ...
*** ExternalTeam
*** Clients

= Appendix =

== Glossary ==

Some terms and acronyms which you could meet in this and other articles you can find descriptions for them in [[RTGlossary]]

== Contributors ==

* [[RobHooft]] - cleanups, corrector, original [[SeeQueue]] right description
* Imak - minor spelling cleanup
* [[RuslanZakirov]]

== Epilogue ==

We hope this small article can help you understand concepts which are used in RT to manage user's rights. Feel free to fix spelling, grammar and other glitches and of course add your own solutions and ideas. Good luck.