RightsQuickStart

From Request Tracker Wiki
Revision as of 15:36, 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

The way that Rights work in RT can be confusing. This document attempts to clarify that somewhat.

Some other useful pages that discuss RT Rights are:

When you create a user in RT, you have two checkboxes:

  • Let this user access RT
  • Let this user be granted Rights

These might better be labeled "Enable this user" and "This is not an auto-created and thus almost powerless user". It's not that the text is inaccurate, just that the way these two boxes relate to the RT Rights structure is a tad bit arcane.

Key concepts:

Only users who have the "Let this user be granted rights" checkbox can be granted Rights. That seems obvious to you right now, but it isn't when you're trying to do things, honest.

Only users who have the "Let this user be granted rights" checkbox appear in lists of users when you're trying to set Rights. This of course falls out of the previous item, but, again, isn't necessarily obvious.

Only users who have the "Let this user be granted rights" checkbox can be assigned to groups.

Rights to queues -- the ability to do specific things with queues -- can be assigned to users (only users who have "Let this user be granted rights" checked!) or to groups.

There are also Global Rights, which apply to all queues. These can be assigned to users or to groups.

Thus if you want to create a queue called BorgCo which is for tickets related to The Borg Company, and you want internal (Privileged) users to be able to see and tinker with BorgCo tickets AND you want to give the customer an RT ID named borgco which can create, view, and update tickets, you would:

  1. Create a queue called BorgCo
  2. Create a user called borgco
  3. IF you have NOT assigned Global Rights to the "Privileged Users" group, skip to step 8
  4. Create a group called something like (say) "Internal" or "Support" or perhaps your company name
  5. Assign all the Global Rights that Privileged Users have to that new group
  6. Add all the internal users to that group
  7. Remove the Global Rights that the Privileged Users have
  8. NOW you can assign queue-specific Rights to the borgco user

The model failure if you do not follow this sequence is that borgco will have extra Rights and you won't understand why.

Note that some of the views don't update automatically as you make these changes: that is, you may need to log out of RT and back in to see changes via the web UI -- just refreshing (say) the homepage for the borgco user may not be enough. So if you make a change, refresh the page, and it doesn't "take", try logging out and back in. (For example, if you remove SeeQueue while a user has the RT homepage up, the page seems to keep showing that queue until you log out and back in.)