RightsCN

This article describes RT security management aspects.

Introduction

Groups

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

Objects

RT manipulates different objects: Tickets, Queues, Scrips, Templates, CustomFields, Users, Groups, etc. Each object takes a different place in the object tree. For example, scripts 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 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 know 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 -> 'Queues' -> 'support' -> '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 grant other system Groups 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:
  1. SeeQueue that allows them to see queue 'support' in select boxes('create ticket in' box, 'search criteria' box and etc).
  2. 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 Requestors so grant requestor role with rights:
  1. ReplyToTicket
  2. 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:
  1. SeeQueue, ShowTicket same reasons as for group Everyone.
  2. 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.
  3. TakeTicket, allows group members to take ticket from nobody.
  4. 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:
  1. 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.

AdminCCs 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 Groups with WatchAsAdminCc right.

Departments of a company as groups

Groups 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.