IBM Rational Synergy User Roles & Security

Technote (FAQ)


Question

IBM Rational Synergy User Roles & Security

Answer

Overview

The role a user assumes during a Rational Synergy session, as well as security rules, together determine what operations can be performed. Some operations require being in a particular role while other operations require the ability to assume a particular role. This Technical Bulletin defines the various Rational Synergy and Rational Change roles and describes what operations can be successfully completed under that role.

Details

A Rational Synergy user always operates under an assigned role. This role determines his/her ability to perform various Rational Synergy functions. The set of roles that a particular user can assume is set up by the CM Administrator at the database level. This information is stored in the users attribute on the base model object, ( base/model/base/1 ). The users attribute is a text attribute that defines the users that are recognized by Rational Synergy, and the roles they are allowed to assume. The syntax for each user's definition is:

user user_name = role1 role2 role3;

user_name is the user ID used to login. Before new users can start Rational Synergy sessions, their user names must be added to the users attribute, and they must be assigned one or more roles. Roles are used to group users for the purpose of security.

An example of the users attribute syntax is as follows:

user ccm_root = developer;
user bill            = developer build_mgr;
user sue           = writer tester;
user bob          = ccm_admin;

Note: The user name ccm_root and role ccm_admin are built into Rational Synergy so do not have to be defined in the users attribute.

Any role may be given to any user but care should be taken to provide each user with just enough access to get his/her job done and to restrict each user where necessary to maintain your process and security requirements. A user may only operate in one role at a time during a Rational Synergy session.

Adding/Modifying Users & Roles

To add or modify the users and roles in the users attribute run "ccm users" at the command line. Only users in the ccm_admin role may modify the users attribute.

Definition of Roles

The roles that are supported in the base model include:

developer: This role is provided for users who are developing and testing programs or other types of objects. Users in the developer role are allowed to create and check-out objects, modify attributes on working or visible objects that are owned by them, and reconfigure and build their working or shared projects.

writer: The writer role is used for the same activities as the developer role, and no differences in security exist between these two roles. The writer role is appropriate for those developing documentation projects.

build_mgr: The build_mgr role is provided for the users who are responsible for configuring and building the product for testing and release purposes. The build_mgr has write access to projects in the prep state, and can check-in objects from integrate to test and from sqa to released. (In order to check-in prep projects the build_mgr users must be in the ccm_root group.)

tester: The tester role is not allowed to create or check-out objects but can check-in integrate objects to the sqa state. The tester works together with the build_mgr to configure the projects that build the product to be tested.

dcm_mgr: This role is required for the following operations:

  • Defining destination databases
  • Defining transfer sets
  • Adding objects to transfer sets
  • Generating a transfer package


component_developer: This role is the same as developer but with additional permissions. The component_developer can check in products and projects to the integrate state.

group_mgr: This is a role for users who want to be able to modify the groups used with Group Security.

ccm_admin: Only responsible CM administrators should be given the ccm_admin role and its use should be limited to only when necessary. Users in the ccm_admin role are permitted to do almost any operation on almost any object within a CM interface. The ccm_admin role is provided because it may be necessary to modify a static object or make a model change (e.g. add new users to the database).

Note: Only an owner of a working project can change his project although a ccm_admin can delete another user's object or project under certain conditions (where it has no predecessor, and is not used in multiple projects); ccm_admin can not change a working project (except in the case of the workarea path).

type_developer: Users in the type_developer role are permitted to use the Type Definition facility to create new types or modify existing types in the current database.

manager: The manager role is not listed in the security rules table. A user in the manager role cannot create or derive any objects but can view projects without modifying them. The name of this role is insignificant and can be changed to any name not already being used as a role. This is the method to create a "view only" role. Note: If a user doesn't have a developer role, then a line must be added to the user's ccm.ini file under the [Options] section (or set from the command prompt) to give users with a "view only" role defined the ability to start up a CM session, for example:

 

set inital_role = manager

 

Security Rules

Security rules restrict the ability to perform certain operations based on the role of the current user and the state and/or ownership of the object version being operated on. The security rules are stored in the security_root attribute of the base model object ( base/model/base/1 ).

The following is a listing of actions that can be performed by each role.

Role
Action ccm_admin build_mgr developer type_developer tester
Change delimiter
Y
N
N
N
N
Migrate Facility
Y
Y
Y
N
N
Typedef Facility
N*
N*
N*
Y
N*


* If the user has the type_developer role (but is not currently in this role) and clicks on Admin -> Type Definition, he/she will be prompted to automatically change to the type_developer role. Upon exit of Type Definition, the user is prompted to go back to their previous role.

Role
Action ccm_admin build_mgr developer type_developer tester
Create object
Y
Y
Y
N
N
Checkout object
Y
Y
Y
Y
N
Edit source*
Y
Y
Y
Y
N
Change Properties**
Y
Y
Y
Y
N


*Must have write permission on object.
**Must be writeable by user. Only the build_mgr can modify the attributes of a prep project.

Role
Action ccm_admin build_mgr developer type_developer tester
Check in Source
Y
Y
Y
Y
Y
Check in Project
Y
Y
N
N
N
Checkpoint Project*
Y
Y
Y
Y
N
Collapse versions*
Y
Y
Y
N
N
Delete object**
Y
Y
Y
N
N


*Must be the owner.
**Developers can delete objects in the working, public, checkpoint, visible, and shared states that they have write access to. Build_mgr can delete objects in the prep state.

Role
Action ccm_admin build_mgr developer type_developer tester
Reconfigure*
Y
Y
Y
Y
Check in Controlled Products
N
Y
Y**
N
Y
Modify Release Table
Y
Y
N
N
N


*No role can reconfigure a project that is in a static state. Only a build_mgr can reconfigure a prep project. Developers can reconfigure their own working projects.
**Developers can check in their working controlled products to checkpoint state only.

Additional Rational Change Roles

In Rational Change, roles are defined in the lifecycle, and controlled by security settings in the transition and state dialogs. Rational Change roles are mapped to Rational Synergy roles (also called privileges in the Rational Change documentation).

pt_admin: The pt_admin (Change Synergy Administrator) can perform any action in the Change Synergy system and like the ccm_admin role, this role should be tightly controlled. Only the pt_admin can modify information in a view for a state through which a problem has already transitioned.

For example: in the dev_process package:

resolver: Resolver is a role used for a "resolved" state and for transitions to this "resolved" state.

sqe: This role is specific to the dev_process package (or packages derived from it). This role is bound to the following attributes: approved_by_sqe and approver_sqe .

In the dev_process we defined roles which were previously used in PT. You can create new roles for your own problem states and your own lifecycles. In that case, these roles and their functionality will depend on the security you will set when defining the lifecycle. More detailed information on role customization in Rational Change may be found in the online Product documentation .


Cross Reference information
Segment Product Component Platform Version Edition
Software Development Rational Change General Information AIX, Linux, Solaris, Windows 5.1, 5.0, 4.7, 4.6.1, 4.6
Software Development Rational Change General Information AIX, HP-UX, Linux, Solaris, Windows 5.2

Historical Number

KB1660

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Rational Synergy
General Information

Software version:

6.3, 6.4, 6.5a, 6.5, 6.6a, 7.0, 7.1

Operating system(s):

AIX, Linux, Solaris, Windows

Reference #:

1325177

Modified date:

2007-12-04

Translate my page

Machine Translation

Content navigation