Security is an important aspect of all project-based work.
In an ALM schema project security is defined by who has access to the project,
and what they can do. A security policy determines access, and roles determine
what are the allowed actions for a user. The record types for defining the
security-policy and roles for a project are:
- Project
- Role
- User and Group
- Security-policy
- Role Label

You define project security by following these steps:
- Create users and groups. Existing ClearQuest® deployments already have
users and groups established. For new ClearQuest deployments see the ClearQuest Administrator
user assistance for creating users and groups.
- Create security policies. A security policy defines which users have access
to the project. If you are a ClearQuest administrator, you can add one or more ClearQuest groups
to a security policy record.
- Choose a security policy. When creating a project, if you have more than
one security policy defined, you can select a security policy from a drop-down
list. Administrators can define security policies and allow project managers
to choose a policy that best applies to their project. A security policy can
be used by one or more projects. Security is set on a project by project basis
and is inherited by all other records related to that project.
- Create role labels. Roles are used to define which users or groups can
perform which actions for a project. Many times an organization has a set
list of role names, such as Analyst, Developer, Architect, Tester. You define
your roles by creating an ALMRoleLabel record for each role.
- Create roles. While role names may be shared across an enterprise, the
role definitions may change from project to project. Each project determines
which roles are included, and which users perform each role, as well as the
allowed actions for each role. You define a new role for the project by creating
a ALMRole record.