For example, Tom has the privileges of a Team Leader (submitter, assigner, reviewer) when working on SystemA CRs, but only Contributor privileges (submitter) for SystemB CRs. Depending on the project he is working on, Tom has different privileges. The databases that the CRs are in does not matter. What matters is their project membership. Projects, which establish a context and the privileges, make this possible.
People often play different roles within an organization. In the previous example, Tom is a Team Leader on one project, but only a Contributor on another. Traditional database security is limited to a single set of privileges per database. You must separate your projects into different databases to ensure the appropriate level of access. Or you must grant unwarranted privileges to the project where lesser access is wanted. Neither solution is ideal.
User management is split among products. Accounts are managed through IBM Rational Directory Server, but privileges are assigned in Rational Change. Furthermore, there is no way to distribute user administration without giving people full administrative access.
Logically related privileges can be grouped into roles, which simplify administration.
Adding a Rational Change user becomes as easy as assigning the user the appropriate groups in Rational Directory Server. Roles and privileges are granted automatically in Rational Change through project definitions.
Administration of each project can be delegated to the appropriate person.
The ease of user administration that project security affords is more fully realized in central mode than in stand-alone mode. Rational Change users do not need to be defined in ccm users through Rational Synergy. Database access is governed entirely from Rational Change privileges. In stand-alone mode, a user must be defined in the database to access its CRs, unless a database has been specially designated.
Project security works with the security rules and privileges defined in the Managing change request processes (lifecycle security). These rules govern transitions and how individual attributes can be modified. In contrast, read/write security (through access control lists, or ACLs) governs whether the CR as a whole is visible or modifiable. If a CR can be modified through read/write security, then its transitions and individual attributes are governed by lifecycle and project security.
Privileges are used in the CR process so that attributes can be modified and transitions are allowed. Roles are a set of privileges.
Any number of projects can be defined, and it is possible to create subprojects. A subproject is derived from an existing project but is more specific in scope.