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.

For details on how to assign privilege rules in the Administration Console, see Manage privileges.

Back to top

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.

Back to top

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.

Back to top

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:

  1. Bill logs in to the Administration Console and selects Users and Roles > Privileges .

  2. In the navigation pane of the Privileges page, Bill selects Product Level Privileges > Project/Stream > Create Project.

  3. 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.

  4. Bill selects the privileges Delete Project and Update and sets the same privilege rules for those privileges.

  5. 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.

  6. Some time later, development work in PROJA is complete, and the project is no longer needed. Ted, however, has left the company.

  7. Bill deletes the project PROJA, as the privilege to do this is assigned to the ADMIN group.

Back to top

See also: