Privilege rules

This topic describes the rules available for each Dimensions CM privilege. Each rule specifies the circumstances necessary to activate a privilege for a user.

About privilege rules

A privilege rule specifies the conditions under which a user has a given privilege. Privilege rules fall into the following categories:

Category	Description
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 the item 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 TEAMLEADS group can create a new project, or a member of the QA group 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 QA group to prevent them from updating project/stream attributes, then a user belonging to the QA group is 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.

Available privilege rules

The following table provides the complete set of privilege rules and their descriptions. Not all the rules are available for all the privileges.

Name	Rule ID	Description
Explicitly deny to users/groups	USER_DISABLE	The privilege is explicitly denied for the users/groups listed.
Explicitly grant to users/groups	USER_ENABLE	The privilege is explicitly granted for those users/groups listed.
Grant to all users	ANYUSER	The privilege is granted to everyone.
Object is in the user's inbox or the user has current role	OBJ_PEND	The privilege is granted if the object (a container or category) for which the general grant rule is specified is in the user's inbox or the user has a role on a state transition from the object's current state. For example, a project is in the user's inbox or the user has a role on a state transition from the project's current state. Note: When the privilege isAction to next state(for Dimensions CM requests, baselines, items, or project/streams) the or in the above rule becomes and. Regarding items and baselines and the behavior of privileges at the initial lifecycle state, the object when first created is only in the inbox of the originator. Therefore, only that user, or by default, those in the ADMIN group, can perform the operations required, such as update item, until it is actioned on.
User has any role on any product	ANYROLE_DB	The privilege is granted if the user has any role on any product in the base database.
User has any role on any transition of the whole stage lifecycle	ROLE_STAGE_LIFECYCLE	The privilege is granted if the user holds any role on any transition in the whole Global Stage Lifecycle.
User has any role on the design part owning the object	ANYROLE_PART	The privilege is granted if the user has any role on the design part that owns the object for which the general grant rule is specified.
User has any role on the initial lifecycle state transition	ROLE_INITIAL_LIFECYCLE	The privilege is granted if the user holds any role on the initial state transition in the lifecycle of the object for which the general grant rule is specified.
User has any role on the object lifecycle	ROLE_LIFECYCLE	The privilege is granted if the user holds any role on any transition in the whole lifecycle of the object for which the general grant rule is specified.
User has any role on the product owning the object	ANYROLE_PRODUCT	The privilege is granted if the user has any role on the product owning the object for which the general grant rule is specified.
User has one or more of the following roles on any product	ROLES_DB	The privilege is granted if the user holds one of the listed roles on any product in the base database.
User has any role on the transition from the current stage to the selected stage	ROLE_STAGE	The privilege is granted if the user has any role on the transition from the current stage to the selected stage.
User has any role on the transition from the current stage to the selected stage	ROLES_STAGE	The privilege is granted if the user holds one of the listed roles on any transition to the current stage in the Global Stage lifecycle.
User has one or more of the following roles on the design part	ROLES_PART	The privilege is granted if the user holds one of the listed roles on the design part owning the object for which the general grant rule is specified.
User has one or more of the following roles on the product	ROLES_PRODUCT	The privilege is granted if the user holds one of the listed roles on the product owning the object for which the general grant rule is specified.
User has one or more of the following roles on the transition from the current stage to the next stage in the stage lifecycle	ROLES_NEXT_STAGE	The privilege is granted if the user holds one of the listed roles on the transition from the current stage to the next stage in the Global Stage lifecycle.
User is the originator of the object	ORIGINATOR_OBJ	The privilege is granted if the current user is the originator/creator of the object for which the general grant rule is specified.

Caution: When you create a new base database or upgrade from earlier versions, the default grant rules for the Update Files from Project/Stream and Deliver Files into Project/Stream privileges include the rule User holds any role on the product owning the object.

As a result, certain users may have the permissions to download and upload files from any project in the product, including those to which they should not have access. To correct this, remove the rule User holds any role on the product owning the object from the grant rules for the Update Files from Project/Stream and Deliver Files into Project/Stream privileges.

Privilege rules example

In the following example, the Revise Item Content privilege has the following rules set in the Administration Console:

Rules	Description
General grant rules	Object is in the user’s inbox or user has current role. This means that a user with the necessary role to action an item from its current lifecycle state to the next one is able to change its contents. User has any role on the initial lifecycle state transition. This means, for example, that a user with the necessary role to action an item of type Document from the Draft state (the first state in its lifecycle) is able to change its contents (even when it is not currently in the Draft state).
Explicit grant/deny rules	ADMIN. A member of the ADMIN user group can change the contents of an item.
Other grant rules	User has one of the following roles on the product: DEVELOPER, PRODUCT MANAGER. This means, for example, that the user assigned the PRODUCT-MANAGER role for the product owning the item can change its contents.

Rules

Description

General grant rules

Object is in the user’s inbox or user has current role. This means that a user with the necessary role to action an item from its current lifecycle state to the next one is able to change its contents.
User has any role on the initial lifecycle state transition. This means, for example, that a user with the necessary role to action an item of type Document from the Draft state (the first state in its lifecycle) is able to change its contents (even when it is not currently in the Draft state).

Explicit grant/deny rules

ADMIN. A member of the ADMIN user group can change the contents of an item.

Other grant rules

User has one of the following roles on the product: DEVELOPER, PRODUCT MANAGER.

This means, for example, that the user assigned the PRODUCT-MANAGER role for the product owning the item can change its contents.

Privilege rules scenario

The following scenario describes how you may set up privileges for creating, updating, and deleting projects:

In this scenario, Bill is the Administrator, a member of the ADMIN group. The ADMIN group has the Manage Privileges privilege explicitly assigned.

Bill assigns privileges to other users:

Bill logs in to the Administration Console and selects Users and Roles > Privileges .
In the navigation pane of the Privileges page, Bill selects Product Level Privileges > Project/Stream > Create Project.
Bill changes the General Grant Rules to set the following privilege rules:
- User has any role on the initial lifecycle state transition.
- Explicit Grant/Deny Rules: ADMIN.
- User has one of the following roles on the product: TEAM LEADER.
Bill selects the privileges Delete Project and Update and sets the same privilege rules for those privileges.
Ted, the Team Lead, has the role of TEAM LEADER for the QLARIUS product. Ted logs in to the desktop client and creates a new project PROJA.
Some time later, development work in PROJA is complete, and the project is no longer needed. Ted, however, has left the company.
Bill deletes the project PROJA, as the privilege to do this is assigned to the ADMIN group.

Privilege rules

About privilege rules

Available privilege rules

Privilege rules example

Privilege rules scenario

Send Help Center Feedback