Roles and objects

This topic provides an overview of how roles apply to Dimensions CM objects. Expand the examples to view sample scenarios for applying roles to objects.

Roles on design parts

When you assign users to a role on a design part, you enable them to work on all objects associated with that design part. In this way, roles promote ownership and responsibility for different functional areas of a product.

Joe and Jane are in the Maintenance group. They need control of the design part called Pensions. Jim and Mary, in the Development group, need control of the Bonus design part.

You can assign the role of DEVELOPER to both groups, each on their own design part. If the privilege rule for Update Item Content is set as "user has the DEVELOPER role on the design part", Joe and Jane can update the items for Pensions, and Jim and Mary can update items for Bonus.

If, in addition, the lifecycle for request type CR has the DEVELOPER role assigned to the ALLOCATED state, the request goes to Joe and Jane’s inboxes for Pensions, and Jim and Mary’s inboxes for Bonus.

Inheriting roles

When a user has a role on a design part, the user also inherits the role on all subordinate design parts in the design structure, unless a different user is assigned to the same role on a lower design part. In that case, the latter user assumes responsibility for that design part and any design parts below it.

John holds the AUTHOR role for design part e. John is then responsible for e and its subordinate design parts, f and g.

Note that only the hierarchical (breakdown) structure of the design parts determines role assignments. John does not inherit a role on design part d, which is in a usage relationship with design part f. If someone else is assigned the AUTHOR role for design part f, then John's responsibility is limited to e and g.

John may also create items on these design parts if AUTHOR is specified as the initial role in the lifecycle for the item types.

Back to top

Roles on design part variants

You can assign a role so that it applies to one or more variants of a design part. This enables you to assign users a role for a particular variant in the product structure, while assigning other users the same role for any remaining variants.

Consider the following assignments, where <NULL> means that the variant field is unspecified:

User Role Design part Project/stream
Will DEVELOPER APPLICATIONS USA
Sarah DEVELOPER APPLICATIONS <NULL>

In this case, Will is granted the DEVELOPER role for the USA variant of the APPLICATIONS design part. Sarah is granted the same role for all variants of the APPLICATIONS design part, except for USA.

Back to top

Roles on projects/streams

When you assign a role to a design part without specifying a project/stream, the role assignment applies to all items in that design part, except those belonging to any projects/streams to which another role has been specifically assigned.

When you make this role assignment, you have the option of additionally specifying a project/stream. In this case, it applies only to item revisions included in that project/stream.

This enables you to assign some users a role for a particular project/stream in the product structure, while assigning other users the same role for any remaining projects/streams.

Consider the following assignments, where <NULL> means that the project/stream field is unspecified:

User Role Design part Project/stream
Dinesh DEVELOPER QUOTATION PROJA
Dawn DEVELOPER QUOTATION <NULL>

  1. Dawn has the DEVELOPER role for the QUOTATION design part in every project/stream except PROJA, where Dinesh holds this role.

  2. Dawn has been assigned the DEVELOPER role for the QUOTATION design part in the PAYROLL product.

  3. Ted the Team Leader creates a new project PROJA in product QLARIUS. Dawn is able to check out file foo.java in PROJA to create a new revision, proja#1.

  4. Ted the Team Leader creates another project PROJB in product QLARIUS and has the administrator assign the DEVELOPER role for PROJB to Dinesh.

  5. Dinesh revises (updates) item foo.java in PROJB to create a new revision projb#1.

  6. When Dawn tries to check out item foo.java;B#1, she does not have the required role because this revision belongs to PROJB, and Dinesh has the DEVELOPER role for any items belonging to PROJB.

Back to top

Roles on baselines

When you assign a role to a design part, the role assignment applies to a baseline if its top design part is in that design part segment.

Example: If the role of TEAM LEADER has the privilege to create baselines, and Ted is assigned the role of TEAM LEADER for design part QUOTATION, he can create a new baseline from design part QUOTATION or one of its subordinate design parts.

Back to top

Roles on requests

Dimensions CM requests do not belong to one particular design part or segment, but they can have one or more design parts related to them.

The way the roles apply to requests is determined by the option Take roles from all affected design parts. You set this option in Administration Console > Configuration Object Management > Object Type Definitions > Requests.

The Take roles from all affected design parts option enables you to specify whether a request type should be routed to the role holders on the common ancestor of related design parts, or to the union of the role holders on all related design parts.

Consider the following design part structure:

The following table describes the behavior of the Take roles from all affected design parts option.

Setting Objects to which roles apply Example

Option is set

All related design parts in a design part segment.

John can perform a task on a request if the following is true:

  • The AUTHOR role is assigned to a task in the request's lifecycle.

  • The request is related to part e, f, or g.

  • The request is optionally related to part d, in addition to being related to e, f, or g.

Option is not set

Nearest common ancestor of all related design parts in a design part segment.

John can perform a task on a request if the following is true:

  • The AUTHOR role is assigned to a task in the request's lifecycle.

  • The request is related to part e, f, or g.

  • The request is not related to part d.

    If it is related to part d, then only Jill, who holds the role on the common ancestor, part a, can perform a task on the request.

Back to top

Roles on lifecycle transitions

Assign roles to transitions in a lifecycle to achieve the following:

  • Determine which users are can action an object type between any two specified lifecycle states.

  • Determine which attributes users can view or update at a specified lifecycle state and which attributes they are required to enter before they can action the object to the next state. For details, see Attribute update rules.

For details on how to assign roles to lifecycle transitions, see Manage transitions.

For details about roles and transitions in the Global Stage Lifecycle, see Create and manage GSL transitions.

  1. Jane, the Administrator, has defined the following normal lifecycle for the item type SRC:

    To action an item of type source from the Under Work state to Unit Tested, the role of DEVELOPER is required. To action an item from Unit Tested to Approved, the role of TEAM LEADER is required.

  2. Jane has assigned the DEVELOPER role on the PAYROLL product to Bill, and the TEAM LEADER role to Sam.

  3. Bill needs to make a change to the source file calcs.c. He checks out the file, makes his changes, and checks the file back in. This creates a new revision with a lifecycle state of Under Work. The item revision is added to his inbox, as he is the originator.

  4. After compiling and unit testing the change, Bill actions the item revision to Unit Tested. Since Sam has the TEAM LEADER role, the item is added to his inbox. Sam performs a system test on the Payroll product, which is successful. He then actions the item revision for calcs.c to APPROVED.

Pending and optional roles

Each role on a lifecycle transition can be defined as pending or non-pending.

When an object is actioned to a state in which users have a pending role to action it further, the users automatically receive the object in their inbox and receive an email notification. Users with a non-pending role do not see the object in their inboxes and do not receive a notification email, but they can work on the object and action it to the next state.

A role on a lifecycle transition can also be optional. This means that actioning an object to the transition's from state does not require there to be a user holding that role. If this option is not selected, the actioning is disallowed if there are no users holding that role.

The lifecycle for the DOC item type has the following transitions defined in the Administration Console:

From To Role Optional Pending User

Draft

Under Review

TESTER

QA

DEVELOPER

Y

N

N

Y

Y

Y

Ted

Jane

Bill

Under Review

Approved

TEAM LEADER

QA

N

Y

Y

N

Sam

Jane

  1. Bill, who holds the DEVELOPER role, updates an item of type DOC.

  2. When he has completed his changes, the new revision is at the initial state of Draft.

  3. He then actions the revision to the Under Review state.

  4. Sam the Team Leader gets an email notification, and the item is added to his inbox, because the Pending option is set.

    Jane, who has the QA role, does not receive an email, or see the item in her inbox. But she can action the item to the Approved state just as Sam can.

The lifecycle for the DOC item type has the following transitions defined in the Administration Console:

From To Role Optional Pending User

Draft

Under Review

TESTER

QA

DEVELOPER

Y

N

N

Y

Y

Y

None

Jane

Bill

Under Review

Approved

TEAM LEADER

QA

N

N

Y

N

Sam

None

  1. Bill updates an item of type DOC to create a new revision. The revision is at the initial state of Draft. Although there is no user with the TESTER role, he can do this because the role is optional.

  2. After updating the file, Bill attempts to action the revision to the Under Review state. Because there is no user holding the QA role, Bill receives a message saying that there is no user holding that role, and he is not allowed to complete the action.

Back to top

See also: