Project roles are a part of the project-based security features that are used to control user access to project-level information. Project roles serve two purposes:
You use roles when you define project-based security.
You use project roles to define the relationship of users, who have been defined as project members, to projects. A project role provides a description of the user's relationship (for example, project manager) and grants view and/or update access to project information.
For more information on project-based security, please see: Security in Oracle Projects.
In Project Resource Management, you use roles to define default information about a team member role on a project, such as competencies, job information, and security. You create project roles to represent the typical team member roles needed for projects in your organization.
Oracle Projects comes seeded with a Project Manager role. To give a project Active status, you must define one team member as Project Manager on the project.
If you are using Project Resource Management, project roles are the templates for creating resource requirements. For each project role, you enter the default for competencies and job information for resource requirements created based on the role. Competencies and job levels are used for requirements search, and job groups and jobs drive forecasting.
Navigate to the Roles window.
Enter the information shown on the following table.
Note: If you change processing from single business group access to cross business group access, you must recreate the job defaults for each role so that the roles can be used in each business group and will have appropriate default values for job information by business group and job group. See: HR: Cross Business Group, Oracle Projects Implementation Guide.
| Field | Description |
|---|---|
| Role Lists | The role lists to which you want the role assigned |
| Access Menu | A security menu that the role can perform on a project |
| Default Competencies | All default competencies required for the role. These competencies are used for requirement definition. |
| Default Job and Job Group | The default job and job group for the role. Calculations for costing, billing, and transfer pricing use the default job to forecast project resource requirements. The default job can be overridden by a Project Cost Job, Project Billing, and Project Transfer Price Job. If you are using Cross Business Group Access, you can use job mapping logic to map the default job of the role to the master job if they are in different job groups. |
| Default Minimum and Maximum Job Levels | The minimum and maximum job levels for the role. The job levels of a requirement are compared to these levels when you perform resource searches. |
| Effective Dates | The date range the specified role is effective. In some cases, you may not know the ending effective date because it has not been determined. Therefore, only a start date is required. |
| Role Controls | You use role controls to define an additional dimension of security layering. Role controls determine how you (or other users) can use the role. You must assign the role control Allow as a Project Member. |
You can also assign role controls to a role. You use role controls to define an additional dimension of security layering.
You can assign as many role controls to roles as necessary. For example, the control Allow as Scheduled Member indicates that you can schedule any person assigned to the role as their availability permits. You assign this control to any role that should be available for scheduling resources on projects. Because role assignments occur at the project level, you must, at a minimum, assign the role control Allow as Project Member to each role.
You use project roles to grant team members view access to project labor cost details. By default, a project team member can access all project-level information with the exception of labor cost details. To grant view access to labor cost details, you must select the Allow Labor Cost Query role control.