Understanding Project Security
At the project level, you can define security in Project Costing as:
Tree-based security that grants access to projects based on the project tree hierarchy.
List-based security that grants access to individual projects, regardless of their positions on a tree.
Team-based security that grants access to projects based on an employee's membership in a project team.
By combining PeopleTools and Project Costing security types, four methods for implementing project row-level security are possible. You can use only one of these methods to secure Project Costing data:
Team-based security.
User, tree-based security.
Permission list, tree-based security.
Permission list, list-based security.
Additionally, the project security profile further defines security for these four security types. The security profile is associated with a project role, and is the ultimate authority for determining access to project data. When you implement project row-level security, security profiles control read/write access to projects, activities, and transactions. Project team members with the same project security profile have access to the same data.
Two factors determine access to data in team-based security:
Membership in the project team.
Project security profile of the member.
In team-based security, access to a project is limited to people defined as project team members by the project manager or administrator. When you use team-based security, the project manager or administrator is automatically added to the team and granted access to project data.
Project managers and administrators can grant access to a project by assigning members to the project team. Being a project team member in a team-based security system, however, does not necessarily grant access to any project data. The user must be a team member and have a project role with a security profile that permits access to project data.
Viewing Security Data
There are two different views of the same security data:
The Project Definitions - Team page lists all members of a project team with each team member's project role.
The Project Security page lists all projects for which the user is a team member, and the member's security profile for each project.
Copying a Team-Based Project
You can copy team members and their security profiles when you copy projects.
Three factors determine access to data in user, tree-based security:
Access to a tree node (project).
Position of the node on the tree.
Project security profile.
You specify the project tree on the Project Security page that the system uses for controlling project security. Grant each user access to nodes on this project tree to define the projects to which the user has access. The user's security profile defines the degree and type of access that the user has to project data.
PeopleSoft delivers the PROJECT_BU tree structure for use in creating project security trees for row-level security.
Restricting and Allowing Access to Child Projects
With tree-based security, users have the same degree and type of access to the child projects of the selected project. Denying access to a project (node) on a project tree can also deny access to all of its child projects.
To restrict access to a parent project, but allow access to specific child projects:
Select a security profile that has No Access to the project for the parent project.
Select a security profile that has Read/Write or Read only access to the project for each child project.
To allow access to a parent project, but restrict access to specific child projects:
Select a security profile that has Read/Write or Read only access to the project for the parent project.
Select a security profile that has No Access to the project for each child project.
Note: The default security for new trees is No Access. To implement minimal security, grant users access to the top node on each tree so that all of the nodes below it are accessible.
Three factors determine access to data in permission list, tree-based security:
Permission list—defining access to folders and content references in portal navigation.
Tree-based—defining access to projects based on their inclusion in, and position on, a tree.
Project security profile—defining the degree of project data access and the access type.
Users with access to a permission list can access projects that belong to a tree that is attached to that permission list. All users with the same row security permission list have the same project access when you use permission list-level security. You can assign only one security profile to the permission list for each project. The degree of access to project data and the access type are defined by either the security profile that is assigned to a project on the tree, or the security profile for the parent project. You can attach a project tree to more than one permission list.
Restricting and Allowing Access to Child Projects
When security is defined for a parent project, all child projects inherit the same permission as the parent.
To restrict access to a parent project, but allow access to specific child projects:
Select a project security profile that has No Access to the project for the parent project.
Select a project security profile that has Read/Write or Read only access to the project for each child project.
To allow access to a parent project, but restrict access to specific child projects:
Select a project security profile that has Read/Write or Read only access to the project for the parent project.
Select a project security profile that has No Access to the project for each child project.
Note: The default security for new trees is No Access. Therefore, you must set up project tree security to provide access to any trees. To implement minimal security, grant access to the top node on each tree that you create so that the nodes beneath it are accessible.
Three factors determine data access in permission list, list-based security:
Permission list—defining access to folders and content references in portal navigation.
List-based—defining access to individual projects selected from a list of projects, not from a tree.
Project security profile—defining the degree of project data access and the access type.
Users with access to a permission list can access projects that are attached to that permission list. Projects are selected from a list of existing projects instead of from a tree. All users with the same row security permission list have the same project access when you use permission list-level security. You can assign only one security profile to the permission list for each project. The degree of project data access and the access type are defined by the security profile for the combination of permission list and project. You can attach a project to more than one permission list.
When permission list, list-based security is defined, users:
Have access only to specific folders and content references that are defined by their permission lists.
Have access only to specific projects that are attached to their row security permission list.
Are limited to the amount of project data and type of access based on the assigned security profile for that permission list and project combination.
Viewing Security Data
If you use permission list, list-based security, the Security by Permission List page appears in the Project General component (PROJECT_GENERAL). This page shows all of the permission lists to which the project is attached, and provides the project manager or administrator with a view of all permission lists that have access to their projects.
Copying Security Definitions
Security definitions are copied when you create a new project by using the Project Copy utility. Access to the new project is restricted to the type of access allowed by the source project. Tree-based security rules are not copied.
You can decide not to implement row-level security for projects. When you select No Security on the Security Options page:
All components are accessible.
All projects are accessible from Tree Manager.
All projects appear in project prompts.
You can enforce security to restrict time and expense charges to projects even if you don't implement row-level security for projects. Select an option at the business unit or project level to enable only team members to charge time to projects and activities.
The project security profile is a subset of the project role, and is the final authority for determining access to projects, activities, and transactions. Project team members with the same project role have the same security profile and access to the same data.
The security profile defines a user's access type—no access, read-only, or read and write permission—to project data. The profile defines access to transactions based on analysis groups. After you define an access type and analysis groups for a project security profile, all users or permission lists that are attached to the profile acquire that access type.
Project security profiles are keyed by tableset ID and can be different for each business unit. For example, a security profile for business unit 1 can grant access to a greater level of data than the same security profile in business unit 2. You can also create different project security profiles for different projects.
This table lists examples of project security profiles and their typical functions:
|
Project Security Profile |
Typical Functions |
|---|---|
|
Project manager, project owner, application administrator |
Create projects and activities, budgets, cost analyses, forecasts, and status. The security profile typically provides read/write access to projects and activities for transactions in all analysis groups. |
|
Project accountant |
Generates bills, creates assets, and performs other accounting functions. May perform project manager or application administrator functions. |
|
Project team member |
Reviews project and activity status and schedules. May require read-only access to specific project components. |
|
Vice president, executive, or high-level manager |
Inquiry of overall project status such as total revenue and gross margin. |
To implement row-level security in Project Costing:
Create project security profiles on the Security Profile page.
Create project roles, and associate them with security profiles, on the Project Role page.
Define the type of security to be implemented, based on the needs of the enterprise, on the Security Options page:
Team-based security.
User, tree-based security.
Permission list, tree-based security.
Permission list, list-based security.
Implement the type of security selected.
PeopleSoft ChartField security provides a flexible, rule-based approach to administer security at a data level. ChartField security is supported in PeopleSoft Project Costing and across other PeopleSoft Financial and Supply Chain Management (FSCM) applications. The ChartField security feature prevents unauthorized employees and contractors from viewing and editing sensitive financial data by restricting access to data stored with specific ChartField values.
The primary features for ChartField security are:
Enforce security rules by user, role, or permission list.
Enable ChartField security for all products or selectively by product.
Enable or disable ChartField security selectively by component.
Define rules to accommodate end-user areas of responsibility.
Refine access rules by product feature or component.
Support super user access to minimize setup.
Define components as exceptions to override security rules.
Project Costing excludes the Project ID field from ChartField Security because it considers the Project ID to be a Project Costing identifier field and not a project ChartField. Therefore, if the Project ID field is included in ChartField Security, Project Costing behaves as though the Project ID field is not part of ChartField Security.
For more information about securing ChartFields: