Project security

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:

1. Create users and groups. Existing Compass deployments already have users and groups established. For new Compass deployments see the Compass Administrator user assistance for creating users and groups.
2. Create security policies. A security policy defines which users have access to the project. If you are a Compass administrator, you can add one or more Compass groups to a security policy record.
3. 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.
4. 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.
5. 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.