A privilege rule specifies the conditions under which a user has a given privilege. Privilege rules fall into the following categories:
General Grant Rules, privilege rules that do not designate specific users or groups. The privilege applies to any user who satisfies the rule at that time. For example, a user may have the privilege to action an item if it is in their inbox.
Explicit Grant/Deny Rules, privileges that can be specifically granted or denied to one or more users or groups. For example, a member of the group TEAMLEADS can create a new project, or a member of the group QA cannot update the contents of an item. These rules take precedence over other rules that grant the same privilege. For example, a General Grant Rule may allow a user to update the attributes of a project/stream if it is in their inbox. If an explicit deny rule is set for the group QA to prevent them from updating project/stream attributes, then a user belonging to group QA would be prevented from updating the attributes of a project/stream even if it was in their inbox.
Certain privileges relating to promotion and demotion can be specified for specific projects/streams and deployment stages, and privileges for deployment and rollback can also be specified for specific areas.
Other Grant Rules, privilege rules that specify a role. For example, a user may be allowed to rename a project if they have the role PROJECT_MANAGER for any product, or a user can delete an item if they have the role DEVELOPER on the design part that owns the item.
Related Topics