Setting Up and Assigning Tree-Based Data Permission
To set up and use tree-based data permission, use the Tree Manager component (PSTREEMGR), Security Tree Audit Report component (RUNCTL_PER506), Security by Dept Tree component (SCRTY_DATA), and Refresh SJT_CLASS_ALL component (SCRTY_OPR_RC).
These topics provide an overview of the data permission security by department security trees and discuss how to manage tree-based data permission.
Note: After you assign a row security permission list to a user, you must run the Refresh SJT_OPR_CLS process.
|
Page Name |
Definition Name |
Usage |
|---|---|---|
|
Tree Manager Page |
PSTREEMGR |
Set up or modify department security trees. You must run the Refresh SJT_CLASS_ALL process whenever you set up or modify a tree. |
|
RUNCTL_PER506 |
Create a list of discrepancies between the data you've entered in the Departments component and the departments you've added to the current security tree. |
|
|
SCRTY_TABL_DEPT |
Grant tree-based department data access to row security permission lists. |
|
|
SCRTY_OPR_RC |
Run the Refresh SJT_CLASS_ALL process when you create or modify a security tree or when you create or modify a row security permission list to update SJT_CLASS_ALL with the user security data. |
Each security set has a tree-based security access type. Tree-based security access types use department security trees to set up a hierarchy of your departments and enable you to use this hierarchy to simplify data assignment.
You use PeopleSoft Tree Manager to build a hierarchy of department security for an organization. A security tree provides a graphic means to grant and restrict access to data. The security tree doesn't have to represent your organization's hierarchy exactly, although it is usually very close.
To grant a row security permission list access to a group of departments, you grant access to the department to which all of those departments report. You can restrict access to individual departments or to a group of departments if you need to. This is an example of a department security tree for the SHARE set ID:
Image: Portion of the SHARE department security tree
This example illustrates a portion of the SHARE department security tree.
Using this security tree you could, for example, grant a row security permission list access to department 13000 and the system includes department 13000 and all the departments that report to it, giving the permission list access to everyone in all fourteen finance departments.
You can also restrict access to one of the branch entities. For example, if a row security permission list needs access to everyone in Finance except for Business Services, grant access to department 13000, but restrict access to department 15000, giving access to departments 13000, 20000, 22000, 25000, 27000, and 31000.
Note: You can only grant tree-based data permission to row security permission lists.
Before you work with data security and PeopleSoft Tree Manager, make sure that human resources data is defined in the PeopleSoft HCM control tables.
Warning! Before you create or modify a security tree, we recommend that you review the PeopleTools: PeopleSoft Tree Manager for a detailed discussion of using PeopleSoft Tree Manager because this section does not provide a complete overview of the application. Security is an important component of your system, and it is crucial that you understand all aspects of PeopleSoft security and its tools before you implement it.
See Setting Up and Assigning Tree-Based Data Permission.
See Assigning Role-Based Data Permission Security to Permission Lists.
See PeopleTools: PeopleSoft Tree Manager
Security Trees and Departments
For the purpose of building department security trees, PeopleSoft defines all entities in an organization—from companies to departments—as departments. The department data is created and stored in the Departments component (DEPARTMENT_TBL), which you can access from PeopleSoft Tree Manager or the Set Up HCM menu. You assign security access based on these departments so define each entity in your organization in the Departments component so that you can add its department ID code to the security tree.
Trees are built with levels and nodes:
Levels are the levels of the hierarchy.
Nodes, representing organizational entities, are added at different levels to indicate their place in the hierarchy.
For example, the first level of your tree might be the company level. The second level might be the regional level. A node that is added at the first level is a company-level node and represents the company department. A node that is added at the second level is a regional-level node and represents a regional department, such as an office. The first node in your organization is the root node. This is the highest node in the hierarchy. All other nodes (departments) report up to the root node.
Access to data is based on the hierarchy that you create. If you grant access to a department, you also grant access to each department that reports to that department.
Note: You should include inactive departments on your security tree; otherwise, data for retired, terminated, or transferred people who used to be in inactive departments will be inaccessible.
Security Trees and Effective Dates
All security trees are called DEPT_SECURITY. Security trees are uniquely identified by their set ID and effective date.
You can create future-dated trees to reflect a change in your reporting structure and you may want to grant access using the newer tree (or, perhaps, to a historical tree).
When you assign data to a permission list on the Security by Dept Tree page select the date as of which you want the trees to be effective. When you add a row in the Define Security Profile grid on the Security by Dept Tree page and select the set ID of the security tree, the system references the security tree that is effective as of the date you selected in the As of Date for the Trees field.
For example, it is now April, 2005 and you have created a future-dated security tree for the SHARE set ID dated January 1, 2006. You wish to try out the data permission using the new tree. On the Security by Dept Tree page, enter January 1, 2006 (or a higher date; the date does not have to be the exact effective date of the tree) in the As of Date for the Trees field. Add a row in the Define Security Profile grid and select the SHARE set ID. The system displays January 1, 2006 in the Effective Date field in the grid and uses the future-dated tree to enforce data permission for that permission list.
When the future-dated tree becomes effective, the system does not automatically update the security profiles of permission lists referencing the old tree. For example, on January 1, 2006, the system continues to use the previous SHARE tree to enforce data permission for all the permission lists that were referencing it.
To update the permission lists so that they reference the new tree, enter the Security by Dept Tree page, enter the date January 1, 2006, and click the Refresh Tree Effective Date button. The system will update the effective dates of all the trees referenced by that permission list to the dates the trees effective as of January 1, 2006.
You can create a security tree automatically or manually.
Use the Tree Manager page (PSTREEMGR) to use to set up or modify department security trees.
You must run the Refresh SJT_CLASS_ALL process whenever you set up or modify a tree.
Navigation
Creating Security Trees Manually
The steps for creating a tree manually are described in the PeopleTools: PeopleSoft Tree Manager. When you create a security tree, enter the following data on the Tree Definition and Properties page (PSTREEDEFN):
|
Field |
Description |
|---|---|
|
Tree Name |
Enter DEPT_SECURITY. |
|
Structure ID |
Select DEPARTMENT. PeopleSoft delivers the system with this structure ID set up. |
|
Description |
Enter a description of the tree. |
|
Set ID |
Select the set ID of the departments that you will add to the tree. |
|
Effective Date |
Enter the date that the tree becomes effective. Add only the departments that are effective on or before this date. |
|
Status |
Select the status of the tree. |
|
Category |
Select the category of the tree. |
|
Use of Levels |
Select one of the following options:
|
|
All Detail Values in this Tree |
Leave blank. |
|
Allow Duplicate Detail Values |
Leave blank. |
Once you've created the basic tree structure, you begin to add nodes. In a security tree, each node represents a business entity in your organization. You define nodes on the Departments component, creating a department for each business entity in your organization.
You must have a node for every department in the set ID. You can add nodes to your trees as you add departments to your organization.
To add a new, future-dated departments in order to maintain data security for people added to the new departments, create a future-dated security tree. This will enable you to add people to the new department before it becomes effective and still be able to control access to their data in the present.
Creating Security Trees Automatically
You can create a security tree using an existing organizational structure. Use the following Structured Query Report (SQR) procedure to import the existing hierarchy and build your security tree. You import your department data into a temporary Department Table, and the system uses that data to build the security tree.
To set up a hierarchy of departmental entities and build your data security tree automatically:
Import the entity data.
Import the entity data into the temporary table R_PER507 using the PeopleSoft Import utility, a Structured Query Report (SQR), or another batch facility. You load department data into this temporary table, so before you use this utility, you must establish the reporting hierarchy for all the departments in your organization. To do this, use the REPORTS_TO_DEPT field in the R_PER507 temporary table. R_PER507 is included with PeopleSoft HCM; it looks like DEPT_TBL, but it includes the following additional columns:
New Column
Description
SETID_RPDEPT
Specifies the set ID of the department that a particular department reports to. In addition to the other Department Table data, you must load data into this column.
REPORTS_TO_DEPT
Specifies department that a particular department reports to. In addition to the other Department Table data, you must load data into this column.
ORGCODEFLAG
Indicates whether the department is selected for processing as of a particular date. The system populates this column based on your department data and the REPORTS_TO_DEPT field values.
ORGCODE
Designates the position of the department in the hierarchy. The system populates this column based on your department data and the REPORTS_TO_DEPT field values.
TREE_LEVEL_NUM
Temporary work column.
PARENT_NODE_NUM
Temporary work column.
TREE_NODE_NUM
Temporary work column.
TREE_NODE_NUM_END
Temporary work column.
Set up the reporting hierarchy.
Run PER507 to set up the reporting hierarchy of your tree. This utility determines whether a department is active or inactive as of the date that you enter when you run the utility, and populates the ORGFLAG column in R_PER507 accordingly. The utility creates a structured organization code based on the REPORTS_TO_DEPT field values that you loaded and populates ORGCODE accordingly. This utility uses the ORGCODE values to set up the department hierarchy.
Build the department security tree.
Run PER508 to build your DEPT_SECURITY tree. The effective date of the tree is the latest effective date of the departments that were processed in step 2.
Note: To set up multiple trees to represent security or organizational structures at different points in time, perform step 2 for each tree, setting the As of Date each time, and perform this step again.
Transfer department data into the department component.
Run PER509 to transfer the information that you set up in R_PER507 into DEPT_TBL. You can't view or update the Department component until you run this utility.
Renumber and insert numbered gaps in the security tree.
Run PTUGAPTR.SQR to renumber the nodes in your tree and insert numbered gaps between the nodes.
Modifying Security Trees
You can modify an existing tree by changing either the nodes or the levels. When you modify a security tree, the tree node numbers usually change, so you need to refresh the numbers. You also need to run the Refresh SJT_CLASS_ALL process to update the data access profiles and security join tables.
Renumbering Gaps in Security Trees
PeopleTools assigns each node a number and reserves a series of unused numbers, called gaps, which the system uses to make changes to sections of a security tree. When you move a node, the system renumbers the nodes that appear to the right of the node that you moved (the children of the node that you moved). When you save changes to a tree, the system saves only the parts of the tree that have changed.
To refresh the unused numbers in the gaps between nodes, run the PTUGAPTR.SQR utility. Refresh unused numbers when:
You load your security tree structure.
You modify your security tree.
An error message tells you to gap your tree.
Use the Security Tree Audit Report page (RUNCTL_PER506) to create a list of discrepancies between the data you've entered in the Departments component and the departments you've added to the current security tree.
Navigation
After you build your security tree, we recommend that you run an audit (PER506.SQR) to determine which department IDs are in the Departments component, but not in the security tree, and which IDs are in the security tree, but not in the Department component. You cannot implement tree-based security for new departments until you add them to your security tree. This audit ensures that you add each department in your system to the security tree.
Use the Security by Dept Tree page (SCRTY_TABL_DEPT) to grant tree-based department data access to row security permission lists.
Navigation
Image: Security by Dept Tree page
This example illustrates the fields and controls on the Security by Dept Tree page. You can find definitions for the fields and controls later on this page.
|
Field or Control |
Definition |
|---|---|
| Refresh Tree Effdts by (refresh tree effective dates by) |
The system will reference the trees that are effective as of this date when you select a tree set ID in the Define Security Profile grid. Select a date in the future to reference a future-dated tree. For example, to use the department security trees that are current as of today's date, enter today's date in this field. |
| Refresh Tree Effective Dates |
Select to refresh the trees listed in the Define Security Profile grid to trees that are effective as of the date in the As of Date for Trees field. Note: To ensure that your row security permission lists use the current trees you must enter the appropriate as of date and click this button whenever you create a more recent version of a set ID's security tree. |
Define Security Profile
|
Field or Control |
Definition |
|---|---|
| Set ID and Dept ID (department ID) |
Enter the tree set ID and the ID of the department that you are granting access to. The row security permission list has access to each department ID that reports up to this one on the security tree (unless you specify otherwise) so you don't have to select each department ID individually. |
| Access Code |
Indicate what kind of access the row security permission list has to the data for this department ID. To restrict access to one or more departments that report up to a department ID that you've granted access to, insert a row and select the restricted department's ID and then select an Access Code of No Access. You need to restrict access explicitly only for department IDs that report up to the department ID to which you want to grant access. Otherwise, the row security permission list doesn't have access to a department unless it or the department to which it reports has been granted access on this page. |
| Effective Date of Tree |
Displays this set ID's tree effective date. Make sure that the effective date of the tree is accurate. The system will not update the effective date automatically if you make a newer version of a tree. To update trees, enter the date as of which the tree is effective in the Refresh Tree Effdts by field and click the Refresh Tree Effective Dates button. |
Use the Refresh SJT_CLASS_ALL page (SCRTY_OPR_RC) to run the Refresh SJT_CLASS_ALL process when you create or modify a security tree or when you create or modify a row security permission list to update SJT_CLASS_ALL with the user security data.
Navigation
Whenever you add or modify a tree or add or modify a row security permission list on the Security by Dept Tree component you need to run the Refresh SJT_CLASS_ALL process to update SJT_CLASS_ALL with the new user security data.
You can access the new or modified tree on the Security by Dept Tree page before you run this process so if you are creating a tree and then using it on a new or existing permission list you only need to run the process once, as long as you refresh the appropriate rows.