You can use project security to add several layers of security to the basic responsibility-based security structure. Project security involves project roles and project access levels. Security access to project information can also be affected by issue and change management as well as project status reporting functionality.
This section provides an overview of these aspects of project security. It also explains how you can use the Project Security Extension to override project security.
Note: The elements of project security discussed in this section apply only to the portions of Oracle Projects applications that use the HTML architecture of the Oracle Applications Framework. Oracle Projects functionality using non-HTML architecture relies solely upon responsibility-based security.
Role-based security enables you to control access to functions on a project based on the role the user plays on a project team. Under role-based security, menus are assigned to roles. The access assigned to a role is available to the user for the duration of the user's role on the project.
Roles that have menus assigned to them are considered to be secured roles by the system. Unsecured roles--roles without a menu assignation--use the responsibility menu to determine their security access.
Role-based security provides more flexibility than responsibility-based security because it is project-specific. Users can play different roles on different project teams. This means that the function access granted to the user can be different for each project.
For example, you can assign a user a project lead role for Project A in the first half of the year and a consultant role on Project B for the second half of the year. Because the two roles are associated with different menus, they can have completely different role-based security access.
Responsibilities, on the other hand, control access at the application level. They give users a broad range of function access that can extend across organizations, resources, and projects. They are not designed to provide function security access at the individual project level.
Note: Role-based security overrides responsibility-based security for 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.
For more information about responsibility-based security, see Using Responsibility-Based Security.
For more information about function security and function menus, see Function Security: The Building Block of Oracle Projects Security.
A project role is a collection of default information about a team member on a project, such as competencies, job information, and security. You create project roles to represent the typical team member roles needed for projects within your organization. Examples of project roles include project manager, project administrator, database administrator, and consultant. Each role can have a different set of competencies, job information for forecasting and menu to control security access to projects.
For more information about roles, see Defining Project Roles, Oracle Projects Implementation Guide.
You use role controls to control usage of a role. Role controls can also control users' ability to view project labor costs.
The following predefined controls are available:
Allow as Project Member: enables the role to be a project member. You can select this role at the time of adding key members and team members to a project.
Allow as Task Member
Allow as Contract Member: this role is enabled if you have a license for Oracle Project Contracts. For more information, see Oracle Project Contracts Implementation Guide.
Allow Scheduling: enables users with this role to create scheduled resource assignments on projects
Allow Labor Cost Query: enables users to view the raw labor cost details
You can assign as many of these controls to a given role as necessary. Because you assign roles to users at the project level, you must, at a minimum, assign the Allow as Project Member role control to each role.
Note: The Allow as Task Member role control is not enabled.
When you set up role-based security for a role by associating it with a menu, you can optionally include an additional layer of security control based on project status. This additional security layer enables you to use the status of the project as another way of determining access to specific functions related to that project. For example, you can give project managers the ability to update assignment rate information for projects while they are in the sales pipeline with a "submitted" status, and then prevent them from updating that information after those projects are approved. Once the projects are approved, your project's financial managers should own the ability to update that information.
When you use standard role-based security, you define one security menu for each role. The security menu controls function security for all projects, regardless of their project status.
When you use role-based security by project status, you can define multiple security menus for each role: one menu for each project status value. This enables you to control function security by both role and project status. You can use either the system project status values or a set of user-defined project status values.
You are not required to define a security menu for every project status value. If a project status value does not have a menu associated with it, the system uses the security menu associated with the role.
You set up role-based security by project status at the role level, on an individual role-by-role basis. This functionality enables you to set up role-based security by project status for some roles and not others.
You can additionally use access levels to control who can search for and view projects and project templates. You set access levels for projects and project templates on the Basic Information page. If you have the appropriate authority on a project you can set one of the following access level values for it:
Secured: Indicates that the project is secured. The project can be viewed only by users with either secured or unsecured roles on the project and by users with organization authority roles. Users with responsibilities that give them view all projects or update all projects access can also access secured projects.
Enterprise: Indicates that the project can be viewed by any user in your enterprise, regardless of their role, responsibility, project assignment, or organization authority. A guest role menu determines what enterprise project information users can view. Your implementation team can modify the guest role menu to increase or decrease the amount of access users have to enterprise project functions.
You can use the UPG: Update Project Access Level concurrent program to update the access level of several projects at once.
For more information about setting up basic project information, see Project Information..
For more information about the UPG: Update Project Access Level program, see Processes.
Oracle Projects' issue management functionality and change management functionality can provide another kind of security access to functions. With issue management and change management, users with appropriate authority, such as super users, users with organization authority, and project managers can create issues and changes and designate owners for them. These owners can in turn oversee the progress, resolution, and closure of issues and changes.
For more information about issue management, see Overview of Issue Management.
For more information about change management, see Using Change Management.
The Project Security extension enables you to override the default security and implement your own business rules for project and labor cost security.
The Project Security extension only applies to the non-HTML architecture of Oracle Projects applications. It does not apply to Oracle Applications Framework functionality.
For a detailed description of the project security extension, see: Project Security Extension, Oracle Projects APIs, Client Extensions, and Open Interfaces Reference.