The most important concept behind Project Server permissions is that they have three potential value states: allowed, not allowed, or denied. This is an important construct in Project Server. When you encounter permissions in the Admin interface, each of the 58 (57 that apply to enterprise configurations) individual permissions has two check boxes associated with it, one for Allow and another for Deny. You may choose to check either Allow or Deny to explicitly assign either value, or you may check neither of them to indicate an implicit state of not allowed.
The difference between not allowed and denied is that when the former is the state for a user by virtue of membership in a group or category, it doesn’t preclude being granted permission in another group or category. On the other hand, when a user is denied in any one group or category, the value inherited by any other group or category relationship is moot.
In other words, there’s precedence to these values as follows, in order from strongest to weakest:
Denied (the Deny check box is selected)
Allowed (the Allow check box is selected)
Not allowed (no check box is selected)
The two explicit states override the implicit not allowed (absence of the selection of the Allow and Deny check boxes) state. For instance, if a user is a member of group 1 and group 2, with group 1 containing a not allowed state and group 2 containing an allowed state, the user is allowed to perform the activity. Denied trumps allowed in all cases. If a user belongs to two groups, and in one group a specific permission is allowed and in the other it’s denied, the user doesn’t have permission.
The fact that permissions are cumulative gives you a lot of flexibility in taking a layered approach to granting permissions. Every bit of time you spend designing your security approach will yield manifold maintenance benefits in managing your system.