From Request Tracker Wiki
Revision as of 16:11, 6 April 2016 by Admin (talk | contribs) (2 revisions imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

A group in RT is a set of users and/or other groups of the RT system that belong together. This sounds very abstract, and it is: the concept of a group in RT is only used to make the assignment of Rights easier: rather than assigning all the rights that every user needs in all different contexts, a smaller set of groups is created. Each group is assigned rights, and each user is made a member of the groups he needs to be in.

An example: In a company with a 5-man service department that run a service queue, and a 2-man IT department that run an IT queue, the 7 users could be assigned to one of two user-defined groups; an IT group and a Service group. These two groups then can be assigned the necessary rights to work in the service and/or IT queues. This could amount to granting 7 rights each to the two groups, and assigning each of the 7 users to one of the two groups. This is significantly less work, less error-prone and will require less maintenance than giving each of the 7 users the exact 7 rights they need. For bigger organisations, the advantage of a group-based system increases.

RT has different group types:

  1. System
  2. Roles
  3. RT public (User defined)
  4. Personal
  5. User equivalent

These group types are described here in order:

  • There are three system groups: Everyone, Privileged, Unprivileged. RT manages the membership of these groups automaticaly, but the rights of the groups can be customized.
    • The group Everyone always contains all users.
    • Every user is either in the Privileged group or the Unprivileged group. Users can be moved between the Privileged and Unprivileged groups by selecting or unselecting the check box 'Let this user be granted rights' on their user management page in the RT configuration area.
  • There are four role groups: Owner, Requestor, CC, Admin'CC'. Each user is automatically assigned to these groups in the context of a ticket. There is no way of assigning members to these groups. If, for example, you create a ticket then you are the requestor for this ticket and play the Requestor role until somebody removes you from the list of requestors of the ticket. RT makes it possible to grant rights to roles. This access control system is named 'Role based access control'. All users can play roles, even unprivileged users, so everyone can inherit the rights from the role. There are no rights that are specific to roles, so in this article the rights are mainly discussed in the scope of public and personal groups.
  • User defined and Personal groups. Membership of these groups can be managed by other users directly and you can grant rights these groups. RT also allows to add groups as members of other groups. Only privileged users can be members of these groups. Important rights for administration are AdminAllPersonalGroups.

Note: The term 'user defined group' can be a little confusing because any user can define his own 'personal' group so I prefer call it 'public' groups. --Ruslan

  • User equivalent group. Each user has his own group with a 1:1 mapping. These groups are only used internally in RT so that the system doesn't need to make the difference between groups and users in the rights management area. Forget about this until you want to start changing the RT codebase.