Process permissions lookup in Rational Team Concert 1.0
Summary
This article provides an overview of Process permissions lookup.
Whenever a user performs a process-enabled operation, we must determine whether they are permitted to perform the actions they’re attempting. Jazz users who are familiar with Process know that permissions are computed based on the user’s assigned roles, the team area which governs the operation, and the point in time that the operation is being run. But exactly how do these factors combine to determine whether a user has the required permissions?
First, a quick refresher (or introduction) on permissions: All roles have only the permissions that are granted to them. If permissions to run an operation are granted to a role in one place, they can be effectively removed in another place by explicitly granting zero permissions for that operation (in terms of the XML, this means an operation block with no nested “action” elements). So when the runtime is checking permissions, it is basically just looking up the XML element which lists which permissions the user has and comparing this to the list of actions that the user is trying to perform.
The lookup of process permissions is nearly identical to the Process Behavior Lookup. Once you understand how behavior is looked up, you almost understand the permission lookup. The key difference between permission lookup and behavior lookup is that behavior chooses a single “operation behavior configuration” from the XML, but permissions potentially choose multiple “operation permission configuration”, one for each of a user’s roles. In this way, a user retains the permissions granted for each of their roles.
Consider the following scenario as an example: A team configures an operation so that only users with role 1 can perform action A and only users with role 2 can perform action B. If a user who is assigned roles 1 and 2 tries to perform actions A and B, this will be allowed because the runtime will first retrieve the configuration for role 1 (which grants action A) and will then retrieve the configuration for role 2 (which grants action B). Taking both of these actions into account, the runtime will allow the operation to be executed.
© Copyright 2008 IBM