The example below shows how you might set up privileges for creating, updating, and deleting projects:
Bill, the Administrator, is a member of the ADMIN group. The ADMIN group have the privilege Manage Privileges explicitly assigned, therefore he can assign privileges to other users.
He logs into the Administration Console and selects Users and Roles | Privilege Assignments.
He selects Product Level Privileges | Project/Stream | Create Project.
He sets the privilege rules:
User has any role on the initial lifecycle state transition
Explicit Grant/Deny Rules: ADMIN
User has one of the following roles on the product: TEAM LEADER
He then selects the privileges Delete Project and Update, and sets the same privilege rules for those privileges.
Ted the Team lead, has the role of TEAM LEADER for the product QLARIUS. He logs into the desktop client and creates a new project PROJA.
Some months later, development work in PROJA is complete, and it is no longer needed. Ted, however, has left the company.
Bill deletes the project PROJA, as the privilege to do this is specifically assigned to the ADMIN group.
Privileges, along with lifecycles, roles, and design parts, manage your organization’s process control. Tighter process control can be achieved with the use of CM rules.
When considering the level of process control that you wish to implement you should consider the following guidelines:
The general grant rules should be sufficient to implement process control for most users.
Although it is possible to grant or deny privileges to specific users, it is better for administrative and maintenance purposes, to grant the privilege to a group and include the user in that group.
NOTE The more rules you enforce the more checks will be needed and this may impact your system’s performance.
There may be times when you need to correct or undo an action just taken. For such occurrences you could create a group to perform such semi-administrative tasks, for example, product level item privileges:
Move item to another design part
Action to any state
Revise item content
For example, a user has actioned an item revision to the next normal state but wishes to return the item revision to the previous state.
The ability to deliver item revisions into a project/stream is a key action and the privilege to do so needs careful consideration. Dimensions can be configured, using privileges, to enforce varying degrees of restriction. These range from the very restrictive "Object is in the user's inbox or user has current role", to the unrestrictive, just get it done, "Grant to all users".
The options are:
Object is in the user's inbox or user has current role
User is the originator of the object
User has any role on the initial lifecycle state transition
User has any role on object lifecycle
User holds any role on the product owning the object
User holds any role on any product
Grant to all users
Qlarius, who have small development teams, have decided that their project/stream can be delivered to by users with any role on the initial lifecycle state transition. To achieve this general grant rules for the Project/Stream privilege Deliver file into Project/Stream have been enabled:
Object is in the user's inbox or user has current role
User is the originator of the object
User has any role on the initial lifecycle state transition
In this example, the "Deliver Files into Project/Stream" privilege is checked against the project/stream into which you are delivering so it checks if:
The project/stream is in the users inbox or the user has a current role on the project/stream lifecycle, or
They are the originator of the project/stream, or
They hold any role on the product owning the project/stream
Also, by default, this privilege is enabled for anyone in the ADMIN group.
Related Topics