On Tue, 20 Apr 2004, joe ritter wrote:
> I am new to RT and have question of the role of Privileged users. How is this role intended to be used exactly? <
All your staff should be privileged; some staff can be more privileged than other staff.
If you configure customers with "let this user access RT: yes" and "let this user be granted privileges: no" and grant them proper rights (CommentOnTicket, CreateTicket, ReplyToTicket, SeeQueue) to the Everyone group (global->system), they will be able to use the Self'Service' interface and see their own tickets. Related groups are Requestor, CC.
There are at least three dimensions of permissions in RT:
The permission itself: things like SeeQueue, CreateTicket, ReplyToTicket, CommentOnTicket, ShowTicket, ShowTicketComments, etc.
Who the permission is assigned to: an individual user, a locally-defined group (like "sales staff", "support staff", "all staff", "customer X"), a system-defined group that applies equally to all tickets (like Everyone or Privileged users), or a system-defined pseudo-group (such as Requestor, CC or Owner) for which every ticket has different members.
Whether it's a global or a per-queue permission.
If you define a user as Privileged, then that user is made a member of the Privileged group in addition to the Everyone group. Only privileged users can be added to locally-defined groups, and be assigned permissions directly. However, unprivileged users can still inherit any permissions that you assign to pseudo-groups like Requestor or CC in addition to the Everyone group.
To grant all staff the right to see all tickets in all queues, define an "all staff" group and assign ShowTicket permission at the global level.
If you want to give everyone the right to see their own tickets in all queues (even in queues that they would normally not be allowed to use), assign Owner and Requestor the ShowTicket permission at the global level.
RT permissions are very flexible, and you may have to experiment before you find settings that work for you.
--apb (Alan Barrett)
-- edited 06/25/2004 (Shane Chen)
This answer states that "Only privileged users can be added to locally-defined groups, and be assigned permissions directly." This is incorrect. I am able to add unprivileged users to both local and global groups. It's not clear to me if they then inherit the permissions of that group.
I did look into changing an unprivileged user's permissions via the Global Users page. It appears that you can change an unprivileged user's permission settings from this page but the user will not actually have those permissions until they become privileged. (The UI is not at all clear that this is what's happening. It tells you rights have been changed, but not whose rights. The unprivileged user is not added to the page, but if you then go and make the user privileged, they appear automatically on the page with the rights you set previously.)
In what circumstances can an unprivileged user's privileges be changed?
My limited explorations suggest the following:
- Rights changes made to the System Group "Everyone" will affect unprivileged users. (One could even make all unprivileged users SuperUsers via this method since both Staff and Admin privileges are able to be set on the Global Group Rights page.)
- Rights changes made to the System Group "Unprivileged Users" will affect unprivileged users (obviously). (One could also make all unprivileged users SuperUsers via this method as above.)
- What happens when an unprivileged user is added to a group that has additional privileges? Do the group rights supersede the unprivileged user's rights? Or does the unprivileged user not obtain those rights until he or she becomes a privileged user, at which point they gain those rights automatically?
If anyone can provide clarity on this, I would be very appreciative.
--added 1/23/18 jwm (Joe Mader)