In this article we will be looking at various levels of security in Oracle Projects module.
In Oracle Projects, we can restrict the access to certain functions of a project based on Project Role an employee plays in that project. This is additional level of control imposed on top of the standard responsibility level security.
In a typical implementation, we create custom responsibilities based on the seeded responsibility menus and functions. In a similar way we can create custom roles based on the seeded roles provided by Oracle.
The security functions are organized by functional areas. Some of these functions include:
a) Budgeting and forecasting
c) Financial structure
d) Page layout
In addition to controlling access to functions, you also control the level at which a user can access the projects in your organization.
If you grant a user Cross Project Access, the user has the highest access level and can view or update all projects in all operating units. You can grant view access, update access or both by setting one or both of the following profile options:
a) PA: Cross Project User – View
b) PA: Cross Project User – Update
The next level of authority is Organization Authority. If you grant a user the Project Authority type of Organization Authority, the user has access to all projects in the specified organization for the functions assigned to the menu selected (by default the Project Manager menu is assigned). You do not have to assign roles to users with organizational authority.
The third level of access is based on the menu you assign to the user’s responsibility. All functions assigned to the menu associated to a user’s login responsibility can be performed on projects associated to the operating unit. This access cannot be restricted by the user’s role on the project, so you should only grant responsibility access for the common functions to be performed by any user with the selected responsibility.
Role-based security provides you the ability to refine your security definitions beyond the security defined by a responsibility because it is project-specific. Because you can define a role for a user that is specific to a project, the function access granted to the user can be different for each project.
Roles can be secured or unsecured. Roles with assigned menus are considered secured roles since the menu determines the activities the user can perform on the projects to which they are assigned. Unsecured roles are simply roles you use to describe the project team. Unsecured roles are not associated with a menu and the security function menu is derived only from their system responsibility.
Role based menus cannot be used to generate the actual user interface page/tab structure. The interface page/tab structure is always and only controlled by menus attached to the users’ responsibility.
Role-based security definitions have precedence over responsibility-based security definitions for granting access to individual users. The system applies responsibility-based security to users that have not been assigned project roles, as well as to users that have project roles without corresponding function menu assignations.
However, role-based security definitions do not restrict access to the security function menu assigned through the responsibility. Role-based security definitions can only broaden the menu of security functions for a user with the defined role.
For example, if the Project Team Member responsibility is given access only to view the workplan in the security function menu but the Team Member role is given both view and update workplan security functions in the Team Member menu the user will have the ability to update the workplan.
If the Project Team Member responsibility is given access to both view and update security functions, but the Team Member role is only given view access, the user will be able to update the workplan since the privilege is granted to their responsibility.