You are on page 1of 14

Oracle White Paper

Updated, August 2012


Function Security in Oracle Project
Management


Function Security White Paper
Disclaimer
The following is intended to outline our general product direction. It is intended for information
purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any
material, code, or functionality, and should not be relied upon in making purchasing decisions. The
development, release, and timing of any features or functionality described for Oracles products
remains at the sole discretion of Oracle.

Function Security in Oracle Projects


Executive Overview ........................................................................... 2
Introduction ....................................................................................... 2
Glossary ............................................................................................ 3
Function Security ........................................................................... 3
Menus ........................................................................................... 3
Responsibility-Based Security ....................................................... 3
Project Security ............................................................................. 3
Organization Authority ................................................................... 4
Cross Project Access .................................................................... 4
Roles ............................................................................................. 4
Role Controls ................................................................................. 4
Using Function Security ..................................................................... 5
Access Levels ................................................................................... 6
Using Role Based Security ................................................................ 6
Granting Organizational Authority ...................................................... 7
Recommended Practice for Role Based Security on a Project .......... 8
Security Checking ............................................................................. 9
Troubleshooting ............................................................................... 11
Function Security in Oracle Projects

2
Executive Overview
Oracle Project Management is an effective and comprehensive set of tools used by customers
around the world to manage medium to large-scale projects. Securing user access to project
information and the ability to perform project activities is a critical step in your implementation.
When deploying Oracle Project Management (Oracle Projects or OP), you can restrict users
from performing selected functions based on their system responsibility, their project role or
their role or responsibility in your organization. Seeded roles and responsibilities make it easy
for you to setup new responsibilities and roles that you can assign to new users.
This whitepaper is intended to help you determine the best way to setup and use OP security
functions and describe how they are used to define access for responsibilities and roles. You
can also find useful information describing how to setup and use OP in the standard User and
Implementation Guides.
Introduction
In addition to the standard eBusiness Suite responsibility based security model, Oracle
Projects provides a role based security model to help you define user access to organizations,
projects and resource information and to perform project related activities. These definitions
are based on the configuration of function security menus that you assign to a role or
responsibility. Security functions can be assigned at the following levels:
Operating Unit; based on user responsibility
Project; based on project role
Organization; based on organization authority rules
Before you set up your security definitions, consider the types of users who will access your
system, the data they need access to and the project activities for which they are responsible.
Function Security in Oracle Projects

3
Glossary
Function Security
Security definitions in Oracle Projects are based upon secured functions. Responsibility-based
security, project security, and organization security all determine the sets of functions that are
available to users. Function security controls which of those functions the users can perform.
Menus
A menu defines the list of functions that are available for a responsibility or role. Use menus to
assign groups of functions to a system responsibility or project role. Menus can include
submenus to organize large groups of functions.
Unless you implement role-based project security based upon project status, you can only
assign one menu to a responsibility or role. When you use role-based security by project
status, you create separate menus for each project status and then assign each of these
menus to a project role.
Responsibility-Based Security
Responsibility-based security applies at the operating unit level and can provide access across
suite-wide products or projects. The responsibility tied to a users log in determines the menu
that is available to the user and thereby which functions the user can perform. Each
responsibility limits user access to information within the operating unit(s) with which it is
associated by setting either the MO: Operating Unit profile option or the MO: Security Profile
profile option. When you set the MO: Security Profile option you can enter and process
transactions in two or more operating units without changing responsibilities. You assign
functions to menus and the menus to responsibilities. Therefore, the responsibility of a user
determines what functions the user can perform.
Project Security
You can use project security to expand a users access based upon a users project role and
access level. Project security does not replace or override any values defined for a
responsibility. 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
Function Security in Oracle Projects

4
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.
Organization Authority
Organization authority enables you to specify security access for users at an organizational
level when their position requires them to oversee all of the projects or resources within one or
more organizations. You do not have to assign roles to users with organizational authority. You
can grant view or update access based to a user and then assign the appropriate menu. The
user will have view or update access to all projects in the organization for the functions
assigned in the selected menu. Organization authority does not acknowledge organizational
hierarchies and you must specify each organization over which the user has authority
regardless of where the organization is in hierarchy.
Cross Project Access
When a user needs to have full access to all projects for viewing or updating, you can grant
them Cross Project Access. By setting the profiles PA: Cross Project User View or PA:
Cross Project User Update you can grant access to projects without having direct
relationship with any project or organization. This enables the users to view or update all
projects information across all the operating units.
Roles
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.
Role Controls
You setup role controls to determine how the role can be used to control security. The
following predefined controls are available:
Allow as Project Member: This option enables the role to be used to define a project
member. You can select this role at the time of adding key members and team
members to a project.
Function Security in Oracle Projects

5
Allow as Task Member: This option enables the role to be used to define a task
member. You can select this role at the time of adding key members and team
members to a project. You must set the profile option PA: Task Managers must be
Project Members to Yes in order to enable this option.
Allow as Contract Member: This role option is enabled if you have licensed Oracle
Project Contracts. For more information, see Oracle Project Contracts Implementation
Guide.
Allow Scheduling: This option enables the role to be used for scheduling resource
assignments on projects.
Allow Labor Cost Query: This option enables the role to view the raw labor cost details
in project expenditure inquiries.

You can enable more than one control to a role. 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.
Using Function Security
Function security controls the activities users can perform on a project. The functions are
organized into menus and you associate menus to responsibilities, roles or you grant them to a
user when assigning Organizational Authority. By associating a responsibility and a role to a
user or granting them Organizational Authority, you grant the activities or privileges of the
functions in the menu to the user.
The security functions are organized by functional areas. Some of these functions include:
Budgeting and forecasting
Costing
Financial structure
Page layout
Project
Workplan
Function Security in Oracle Projects

6
Refer to the Oracle Projects Implementation Guide, Function Security, Appendix A for full list of
functions that you can control using function security.
Access Levels
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:
PA: Cross Project User View
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 users responsibility. All
functions assigned to the menu associated to a users login responsibility can be performed on
projects associated to the operating unit. This access cannot be restricted by the users 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.
The lowest level of access is based on the role the user performs for a specific project. When
you assign a role based security menu, users must have a role on a specific project to perform
the assigned functions . You can also assign menus based on project status, so users can only
perform the functions in the menu based on the projects status.
Using Role Based Security
User responsibilities control access at the application or site level and you manage
responsibilities using the standard Oracle security model. Responsibilities 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.
Function Security in Oracle Projects

7
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.
For example, you assign a user a Project Lead role for Project A where they perform a variety
of functions that only the Project Lead can perform. You also assign the same user as a
Consultant on Project B. The user will not be able to perform the Project Lead functions for
Project B.
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.
Granting Organizational Authority
Organization Authority is similar to role based security access at the organization level. It can
provide access to all projects, resources, and utilization information for the specified
Function Security in Oracle Projects

8
organization. You must specify each organization for which a user has authority and then
specify what type of authority the user has for those organizations. You use the Organization
Authority page to grant authority to a user and assign a menu to define the approved functions.
Oracle Projects provides three types of Organization Authority:
Project Authority This type of authority enables a user to perform functions on all
projects in an organization, such as project definition, staffing, workplan creations, and
financial planning. By default, the function security menu for Project Authority is the
same as the function security menu for the Project Manager role, but the menu can be
modified.
Resource Authority Enables a user to view and update information for all resources
in an organization. For example, with resource authority you can assign resources to
any project in an organization.
Utilization Authority - Enables a user to calculate and view utilization for all of the
resources in the organization.
Recommended Practice for Role Based Security on a Project
You should only provide Organization Authority or Cross Project Access to users when their
role requires them to perform functions across all projects in an organization or all projects in
your system.
Otherwise, when you setup responsibilities, you should only grant security functions that all
users with that responsibility can perform. Then use the role-based security definition to give
additional access to users based on their project role.
For example, you may decide that the Project Manager, John Smith, regardless of which
project he is assigned, should have the following functions (included in the Project Functions
area in the Function Security List from the Oracle Projects Implementation Guide, Appendix A):
Mass Update Batches Projects: Page Layout List
Project Creation Projects: Project Overview Function
Projects: Enter and Maintain Projects Projects: Project Request List
Projects: Edit Attachments Projects: Project Search
Projects: Add Attachments Projects: Relationships
Function Security in Oracle Projects

9
Projects: View Attachments Project Sets: Create and Delete
Project Retention Inquiry Projects: Project Sets: Update All
Project Home Tab Projects: Project Sets: Set as Shared
Project List Button Projects: Set Project Access Levels
Project List: View Summarization Columns

So, in the responsibility for Project Manager assigned to John Smith, you would create a menu
including these functions. When John Smith signs in as Project Manager, he would be able to
perform any of these functions for any project in his operating unit.
However, you may not want to grant John Smith the ability to view billing information or
approve project billing invoices for all projects, so you would not include the following functions
(from the Project Functions area) in the Project Manager responsibility menu:
Project: Financial: Billing
Project: Financial: Billing Approve Invoice
Project Funding Inquiry Query project funding and billing activity

For Project A, John Smith requires the ability to review and approve invoices and view funding
activity in addition to the standard Project Manager functions, but he does not require this
ability for Project B. So, you would create two separate team roles:
Project Manager with Billing Authority which would have the role-based menu
assigned that includes the 3 functions listed above
Project Manager with No Billing Authority which would have the role-based
menu assigned that does NOT include the 3 functions listed above.

Then you would assign John Smith to Project A with the role Project Manager with Billing
Authority and to Project B with the role Project Manager with No Billing Authority. Based upon
his responsibility, Project Manager, and his team role on Project A, Project Manager with
Billing Authority, John Smith would be able to work on a project and also view and approve
invoices. For project B, he would only have the functions granted by his responsibility, Project
Manager.
Security Checking
Function Security in Oracle Projects

10
Oracle Projects calls a security check process when a user attempts to perform an action. This
process searches for the appropriate permissions to allow the user to perform the requested
action.
The process chart below describes how the security functions are used to determine user
access. Refer to the Oracle Projects Fundamentals User Guide, Section 13 for more
information and a description of how each step is evaluated.

Security Check Process



Function Security in Oracle Projects

11
Troubleshooting
Question: Why cant my project manager access a project workplan?
Answer: If the project manager is not granted the security function for viewing a workplan in the menu
associated to his or her login responsibility, then the security function must be granted through the
users role menu and the user must be setup in that role on the project.
Question: Why does the unlock structure function not worked for budgeting when assigned to a user.
Answer: After the function PA_UNLOCK_ANY_STRUCTURE is assigned to a user, that user can now
unlock budget versions locked by other users.
Question: The project manager was able to change the project status even though the Grant check
box was disabled on the security function.
Answer: Disabling the Grant checkbox does not restrict the function on the users security menu. To
restrict the function, it must be deleted or removed from the menu.
Question: Why is role-based security not reflected when using Microsoft Project Integration?
Answer: Role-based security was enhanced to use with MSP Integration for the function Projects: View
Labor Cost Rates by modifying the security check for function PA_LABOR_COST_RATES_VIEW. See
Bug 6135219.
Question: Why doesnt role-based security apply on the Resource Summary page under the Reporting
tab?
Answer: Role-based security was corrected in Resource Summary page after fixing bug 7192736 to
check security in the view_labor_costs_new in PA_SECURITY package.
Question: Copy plan version not working for project role-based security.
Answer: When using project role-based security the copy plan version amounts in the financial plans
should populate the plan types list of values after code added to check the user privilege is called after
getting the project id. See Bug 10635040.
Question: Role-based security not working when checking the Grant flag.
Answer: For role-based security, the Grant option has no effect or functionality.










\
Function Security in Oracle Project Management
August 2012

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright 2012, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the
contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchant ability or
fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
means, electronic or mechanical, for any purpose, without our prior written permission.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. Intel
and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are
trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open
Company, Ltd. 0410