- Request Tracker (RT) on help.mit.edu
- RT queue administration
Watchers are individuals or groups with special roles on a queue or a ticket in Request Tracker. Watchers come in four different types, Cc, AdminCc, Consultants, and Admins. Exactly what rights a given type watcher has is determined by a queue's configuration and the way the queue administrators have decided to manage permissions and notifications. This article covers the common case, which is usually the way queues on MIT's central RT instance are set up when they are created.
|Watcher Type||Default Use for Notifications||Default Use for Permissions|
|Cc||Receives copies of correspondence and reply transactions, similar to the Requestor on a ticket||By default not used for permissions|
|AdminCc||Receives copies of correspondence/reply and comment transactions, and receives notification when new tickets are created||By default not used for permissions|
|Consultant||By default not set up for any notifications||By default not used for permissions|
|Admin||By default not set up for any notifications||By default not used for permissions|
Groups in RT are similar to groups in Moira or Active Directory. They contain a list of users or other groups, and can be assigned permissions on a queue, made watchers on a queue or ticket, used to share saved searches, and used to share team dashboards. If an RT group's name is identical to a group in MIT's Moira and Active Directory services, then membership will be automatically synchronized from Active Directory to RT in a nightly update.
Groups are the default (and common) way queue administrators assign and manage permissions on RT queues in MIT's RT instance. By default, both a "staff" and "admin" group are created, or re-used if they already exist prior to the time a queue is set up, and assigned full staff and admin permissions on the queue, respectively.
Queue permissions are assigned on the Group Rights and User Rights tabs of a queue's configuration screens.
User Rights are rarely used at MIT but can be used to assign specific rights to individual users. Rights must be maintained through RT and are not synchronized with any external group or authorization management systems.
Group Rights are the common method used to grant access to queues at MIT. Once properly set up, users can be added to a Moira group and RT will automatically update its internal memberships based on the Moira changes.
The Group Rights tab can also be used to grant permissions on a queue to Watchers. Watchers appear as virtual groups on the Group Rights tab, and as a queue admin you can assign them permissions just as you would to actual groups. This can provide increased flexibility and sophistication.
For example, if you always add new staff as AdminCc Watchers and add them to the staff group that has permissions on your queue, you could grant staff permissions to the AdminCc "group" instead, and simply add them as AdminCc watchers, which will then give them permissions automatically.
Note that the reverse is also true. You could make your staff group an AdminCc watcher rather than adding individual watchers. You can then simply add new staff to the group and they will become watchers automatically. The two methods are almost equivalent, and which one you choose will depend on whether you prefer to manage permissions inside RT, or using external Moira lists.
The one area where granting permissions to Watchers provides increased flexibility is for ticket-level Watchers. Watchers can be added to individual tickets, not just entire queues. Permissions you grant to Watchers on your queue apply to both queue-level Watchers and ticket-level Watchers. This can be useful if you sometimes need to grant individuals outside your area permissions to work on specific tickets. With this setup you can make them AdminCc watchers on a ticket, which will grant them access to that ticket, not just send them notifications.