peoplesoft enterprise human capital management & campus ... › us › media › ebook ›...

PeopleSoft Enterprise Human Capital Management & Campus Solutions: Row Level Security in 8.9 Version 1.0 An Oracle White Paper March 2005

PeopleSoft Enterprise Human Capital Management & Campus Solutions: Row Level Security in 8.9


Version 1.0

Introduction........................................................................................................5 Design..................................................................................................................5

What is Row Level Security? .......................................................................5 How is Row Level Security triggered? .......................................................6 Security Structure Terminology...................................................................6 Security Installation Settings........................................................................8

Special Job Security ..................................................................................9 Actions that trigger Future Dated Security Rows..............................10

Security Sets: Defining What data is being secured................................11 Security Set Table Page ..........................................................................12 Head 3 ......................................................................................................12 Head 3 ......................................................................................................12

Security Update Groups Page ...................................................................13 Security Types: Defining How the data is secured..................................14

Security Type Table Page.......................................................................16 Security Type SQL Page ........................................................................18

Assigning the Transaction Security Field Values to Security to Permission Lists...........................................................................................18

Security by Department Tree................................................................18 Security by Permission List ...................................................................22

Use the Security by Permission List component for all security types that are not based on a department security tree....................................22 Follow these steps to set up security by permission list: .......................22

Variations .................................................................................................25 How Security Views work..........................................................................27 Entity Relationship Diagrams ...................................................................30 Security Records ..........................................................................................31

SCRTY_SET_TBL: Security Sets ........................................................31 SCRTY_TYPE_TBL: Security Types .................................................31 SJT_CLASS: Security data by Permission List (non-tree) ...............35 SCRTY_TBL_DEPT: Security data by Permission List (tree) .......35 SJT_CLASS_ALL: Security Join Table for the Operator Side .......36 SJT_PERSON: Security Join Table for People ................................38 SJT_DEPT: Security Join Table for Departments ............................40


SJT_PERSON_USF: Security Join Table for USF Employees.......40 HRS_SJT_JO: Security Join Table for Recruiting Solutions Job Openings..................................................................................................41

Core View Structure and View Text.........................................................41 Persons.....................................................................................................43 Enabling Different fields for the Search and List Box .....................47

Product specific views ................................................................................48 Custom Views..............................................................................................51 Refreshing the Operator Security Join Table..........................................51 Refreshing the Transaction Security Join Tables....................................52 Nightly Updates for the Transaction Security Join Tables....................55 Real-Time updates of the Transaction Security Join Tables.................56

SCRTY_SETTYP_VW .........................................................................56 SCRTY_DERIVED...............................................................................57 Process......................................................................................................57

Creating New Security Types.........................................................................60 Security for People without Jobs...................................................................71 Special Job Security Versions (aka Access by Association).......................73

Include Home/Host Access (aka International Security). ....................74 One Home – One Host.........................................................................75

Include Additional Assignment Security..................................................82 JOB Data .................................................................................................84

Include Japan Assignment Security ..........................................................86 Example of Security Access ..................................................................87

Implementation Process .................................................................................91 Steps ..............................................................................................................91 What Security Types to enable. .................................................................91 What to consider .........................................................................................91 Enabling Multiple Types in a Set ..............................................................92

Security in Production.....................................................................................92 User Maintenance........................................................................................92 Permission List Maintenance.....................................................................92 Role Maintenance........................................................................................93 Department Tree Maintenance .................................................................93 Security Type Maintenance........................................................................93 Future dated entries in the Transactional Tables....................................94 Changes to the Transactional Tables via Batch ......................................94

Upgrade Process ..............................................................................................94 Customers Using the Delivered Dept Security Tree..............................94 Customers Using the Delivered Dept Security Tree with Global or Japan Additional Assignments Versions..................................................95 Customers Who Have Customizations to use the Business Unit, Location, Regulatory Region, Company, or Salary Grade Fields instead of DEPTID..................................................................................................95 Customers Who Have Customizations to use the DEPTID but not via the Tree.........................................................................................................96


Customers Who Are in One of the Above Categories but Have Also Created Their Own Security Views ..........................................................97 Customers Who Have Customizations That Do Not Use a Field in the JOB_DATA Components.........................................................................97 Customers Who Have Turned off Row Level Security.........................97

FAQ...................................................................................................................98 Can I set up Read-only access? .................................................................98 Does the new security Structure support Field Level security?............98 How does this affect Manager eApps and Direct Reports?..................99 Can I update the SJT tables after a batch update?..................................99 Can I use other Trees other than the Department Security Tree?.......99

Customization ..................................................................................................99 Adding a new Security Set..........................................................................99



Version 1.0

INTRODUCTION Oracle’s PeopleSoft Enterprise HCM HRCS 8.9 provides enhancements to the setup, usage, and flexibility of row level security. This document will explain these improvements and discuss how you can use the new flexibility and offer tips to help you implement and approach customizations.

The major enhancements to row level security for 8.9 are:

• The ability to secure more than just access to person data.

• The ability to use more than one-way of securing your data.

• Easier setup and changeability.

• Better performance and flexibility for refreshing security tables.

• Real-time updates to security tables.

• Easier setup of global and additional appointment security.

DESIGN

What is Row Level Security? Row level security is a term used to describe the ability to prevent users from accessing rows of data that they are not supposed to see. Security at the row level restricts the user from accessing all of the data on a particular row. Row level security is enforced through the use of a security view. A security view joins together the user’s security definition with the data that is being secured and returns only the rows that the user is allowed to access.

For example, the JOB_DATA component uses a search view that uses row level security. When a user accesses the JOB_DATA component search page and searches for a record, the security view only enables the search page to return those rows the user has access to. So if the user has access to people in the department ABC and searches for employees with the name of Smith, the security view only lets employees with the name of Smith in department ABC be displayed on the JOB_DATA search page.

Row level security is a term used to describe the ability to prevent users from accessing rows of data that they are not

supposed to see. Security at the row level restricts the user from accessing all of the

data on a particular row.


Previous releases of PeopleSoft Enterprise HRMS enabled you to secure access to a person’s data using the department ID stored on their JOB record.

How is Row Level Security triggered? Different methods of accessing data require different security setups. For example, components are secured using a security search view that is associated with the component or overridden at the MenuItem level for that component. This prevents the user from being able to access data they are not allowed via the search page.

Records used in PS/Query are secured by using the security view that is defined in that record’s properties. The PS/Query tool will join in a record’s query security view whenever that record is used in a query. Batch processes join in specific security views in their code.

Security Structure Terminology Term Definition

Security Install Settings Basic overall settings on how you will use core row

level security

Security Set What type of data is being secured

Security Type What attributes are used to secure the set. There

may be multiple types for each set.

Permission List Security A single permission list that is used to define the

values securing data when using a security types

that is not tree-based. These permission lists are

assigned to security roles that are then assigned to

users.

Row Security Class A single permission list that is used to define the

values securing data when using department

security tree-based security. The row security class

permission list is assigned to a user via the

PSOPRDEFN.ROWSECCLASS field (the Row

Security field on the User Profile – General page).

Security Roles A grouping of similar permission lists for a specific

functional role that is assigned to users on the User

Profile – Roles page.

User’s Security Profile The roles and/or RowSecClass that have been

associated with a user and the security access that

they grant the user.

Different methods of accessing data

require different security setups. For example, components are secured using a

security search view that is associated with the component or overridden at the

MenuItem level for that component.


Term Definition

Security Join Table (SJT) The flattened physical table that contains the user

side security definitions or the transactional security

data.

There is one SJT for the user security data –

SJT_CLASS_ALL. There are generally different SJT

records for each Security Set.

The SJTs are populated using Application Engine

programs and Save PostChange Peoplecode to

provide real-time updates.

Security View A view that joins together the user security

definitions and the transactional security data with a

user’s security profile to determine which rows of

that data set are accessible to the user.

You’ll generally only set up information on the Security Installation Settings, Security Sets, and Security Access Types components once at installation time. You’ll want to determine which type(s) make the most sense for your organization and enable those. The security sets and types that have been delivered are already ready to use – you only need to decide which ones to turn on. You can always enable additional types at anytime, as your security needs change.

The security permission lists and row security classes contain exactly the data values that will be used for each enabled type and these can then be grouped into roles or used individually. Setting up and maintaining permission lists is an ongoing function.

As users are created or change functions, the security roles and/or row security class they are given will change. Assigning roles and row security classes is an ongoing function.

Each piece of the security structure is defined separately to make the structure flexible.

Take the statement:

User A has access to People with Jobs in Business Unit GBR01

And access to People without Jobs in Location Headquarters.

To make this happen, we need to define:

The Set and Type People with Jobs.

As users are created or change functions,

the security roles and/or row security class they are given will change. Assigning roles

and row security classes is an ongoing function.


The Set and Type People without Jobs using Location

The Permission List: People with Jobs in BU GBR01

The Permission List: People without Jobs in Location HQ

The Role: Access to all People at Headquarters

Which is assigned both Permission Lists

The User: User A who is given the Role “Access to People at Headquarters”.

Security Installation Settings There are a few settings that need to be entered during installation that will govern certain processes in row level security.

Component: SCRTY_INSTALL

Navigation: Set Up PeopleSoft Enterprise HRMS, Security, Core Row Level Security, Security


Installation Settings

Special Job Security

The Special Job Security Versions group box is used to enable the ability to assign these types of security at the security type level. This page is used to enable these versions and to what level. You can then enable the access (or not) for each security type that uses the PPLJOB security set. Each of these versions is discussed at length later in the document but here are some brief definitions:

Include Home/Host

Also known as global assignment or international security.

Employees going on global assignments have at least one home record, which falls under the jurisdiction of the HR administrators at the home base, and at least one host record, which falls under the jurisdiction of the HR administrators at the host location.

What this special security access does is to grant a user who has access to one type of record access to another record based on the association between the first and second records. The options are:

• Home can see Host: Users who have access to the home record can also have access to the current and future-dated host records.

• Host can see Home: Users who have access to the host record can also have access to the home record.

• Both: Home users can access the host records and host users can access the home records.

Include Additional Assignment

With PeopleSoft Enterprise HRMS 8.9, we have introduced the concept of a controlling job instance in order to categorize multiple jobs. When a new assignment is created, the user must first choose the controlling instance that this new assignment will be associated with. That is the instance (or EMPL_RCD) that has the Hire date that should be used for this person and instance. The new assignment inherits the Hire date from the controlling instance rather than having its own Hire date (although it does get an assignment start date).

The Additional Assignment security enables you to set up a similar security setup as with the Home/Host security. A user who normally has access to the person’s controlling instance may need to have access to that person’s additional assignments. Or the user who normally has access to the additional assignment might need access to the controlling instance. The options are:

With PeopleSoft Enterprise HRMS 8.9, we

have introduced the concept of a controlling job instance in order to

categorize multiple jobs. When a new assignment is created, the user must first choose the controlling instance that this new assignment will be associated with.


• Instance can see Assignment: Users who have access to the controlling instance can also have access to the current and future-dated additional assignment records.

• Assignment can see Instance: Users who have access to the additional assignment record can also have access to the controlling instance record.

• Both: Users with access to the controlling instance can access the additional assignment records and users with access to additional assignments can access the controlling instance.

• None: Users do not have any additional access beyond their user profile.

Japan Appointment (Kenmu).

Additional Appointments are tracked as additional jobs (employment record numbers) in the Job record. The Additional Appointment Information page enables you to track multiple additional appointment rows for each controlling instance row of the Job record. A separate Enter Cost Rate Information page enables you to tracking of cost rate distribution among a controlling instance and its additional appointments

The Japan Appointment security enables a user who has access to a person’s additional appointment to also have access to that person’s controlling instance. The reverse situation is not needed (where the controlling instance is granted access to the additional appointment because users can only access the additional appointment information by choosing the controlling instance in a search page).

Actions that trigger Future Dated Security Rows

The other group box on the Security Install Settings page enables you to choose which actions selected on the Job Data – Work Location page for a new, effective-dated job will trigger the system to include the future dated JOB row in the security join table (SJT_PERSON).

There are times when you want a user to be able to have access to a person even though the data that would give them that access won’t become effective until a future date. For example, you want users to be able to access people who are going to be hired as soon as they enter the system. Another example is for transfers. The user who administers the place (Dept, BU, Company, location etc) where the person is going to be transferred may need to access the person as soon as the transfer has been entered into the Job Data component even if that transfer is in the future.

Prior to PeopleSoft Enterprise HRCS 8.9, any future-dated JOB action would be available in the security search views. With PeopleSoft Enterprise HRCS 8.9, we enable you to choose which actions will be stored in the security join tables as soon as the JOB rows with those actions are created. We deliver the system with actions already selected, but you can delete and add other JOB actions as you choose.

With PeopleSoft Enterprise HRCS 8.9, we

enable you to choose which actions will be stored in the security join tables as soon

as the JOB rows with those actions are created. We deliver the system with

actions already selected, but you can delete and add other JOB actions as you

choose.


At this time, this flexibility is only available with the Persons with Jobs security set that. Other security types can have future dated actions but they will use all future dated rows.

Security Sets: Defining What data is being secured There are many different types of data in the PeopleSoft Enterprise HRCS system. For example: people, departments, job openings, and so on. In previous releases, we supplied row level security to secure data that is associated with a person. Our new security structure allows you to define multiple sets of data that can be secured. Each set is defined and managed separately. In PeopleSoft Enterprise HRCS 8.9, we are supplying as system data the definitions for these sets:

People with Jobs

(PPLJOB)

Security for any person who has a PS_JOB record.

People with Jobs for United

States Federal Government

(PPLUSF)

Security for any person who has a PS_GVT_JOB

record.

People without Jobs

(PPLPOI)

Security for any person who does not have a

PS_JOB or PS_GVT_JOB record.

Note. PeopleSoft Enterprise HRCS 8.9 now allows

you to capture data for people even if they are not

part of your workforce. Because they are not part

There are many different types of data in the PeopleSoft Enterprise HRCS system.

For example: people, departments, job openings, and so on.


of the workforce, they do not need a job record.

Without a job record we use different data to

provide security for people without jobs so we treat

these as a separate Set.

Departments

(DEPT)

Security for department setup data and associated

data, including positions.

Job Openings

(HRSJO)

Security for job openings created in PeopleSoft

Enterprise HRCS Recruiting Solutions.

Component: SCRTY_SET_TBL

Navigation: Set Up PeopleSoft Enterprise HRMS, Security, Core Row Level Security, Security Sets

Security Set Table Page

Head 3

This is head 3 text.

Traditionally, two distinct approaches—shared nothing and shared disk—have been used in the implementation of database systems on parallel hardware. Each approach, in its pure form, offers certain unique benefits and trade-offs. We present an outline of the major elements of each approach in this section and provide a conceptual foundation for the central argument in this paper .

Head 3

In pure shared nothing architecture, database files are partitioned among the instances running on the nodes of a multi-computer system. Each instance or node ‘owns’ a subset of the data and all access to this data is performed exclusively by the owning instance. In other words, a pure shared nothing system uses a partitioned or restricted access scheme to divide the work among multiple processing nodes. Data ownership by nodes changes relatively infrequently—database reorganization and node failure are the typical reasons for change in ownership.

Parallel execution in a shared nothing system is directly based upon the data partitioning scheme. Each partition is accessed in parallel by a single process or thread, with no provision for intra-partition parallelism. Conceptually, it is useful to think of a pure shared nothing system as being very similar to a distributed

.


Transaction Sec. Join Table

The security join table used by this security set. More than one security set can share a security join table if there is a need to combine those results. For example, People with Jobs and People without Jobs share the SJT_PERSON Security Join Table.

SJT Temp Table.

This is the temporary table that is used during the SCRTY_SJTUPD Application Engine process that refreshes the transaction security join table. This table must be a copy of the Transaction Sec Join Table along with the PROCESS_INSTANCE field.

SQLID for Value Field List

This is the SQLID of the SQL object that contains a list of the fieldnames found in the transaction security join record. This SQL is used in the App Engine Process SCRTY_SJTUPD when the transaction security join record is refreshed.

Security Access Types for this Set

This is a read-only grid that displays all of the security types that have been created for this security set and indicates which ones have been enabled.

The Security Set Table page is display only for PeopleSoft Enterprise-delivered security sets. Note. It is possible to create a new security set, but it requires customizations (See Appendix).

Security Update Groups Page The second page in the Security Set component describes which groupings of data can be selected for refresh on the Refresh Trans. SJT table’s component for this security set. This allows the process to be run for just a subset of data in the SJT instead of having to refresh the entire table.

The second page in the Security Set component describes which groupings of

data can be selected for refresh on the Refresh Trans. SJT table’s component for this security set. This allows the process

to be run for just a subset of data in the SJT instead of having to refresh the entire

table.


The Rows to Update field offers a list of translate values containing the groupings that the Application Engine process (SCRTY_SJTUPD) can process. Adding a new grouping requires customization of the AE Process.

The system is delivered with all of the valid groupings for each security set selected. You can choose to delete one or more of them to make that option unavailable on the SJT Refresh page. If you add values other than those delivered as System data, the Application Engine code will not understand the job and it will probably fail.

Security Types: Defining How the data is secured The security type defines exactly what attributes will be used to secure the data that is contained in the security set. Each set may have multiple types defined and you can choose to enable those that make sense for the organization. PeopleSoft Enterprise HRCS delivers the most commonly requested security types for each set preconfigured. To use any of these types, you have only to enable them. It is possible to create your own types and that will be discussed later.

Security Set Security Type

People with Jobs Dept Security Tree

Location

Business Unit

Company

Regulatory Region

Salary Grade

The system is delivered with all of the valid

groupings for each security set selected. You can choose to delete one or more of them to make that option unavailable on the SJT Refresh page. If you add values

other than those delivered as System data, the Application Engine code will not

understand the job and it will probably fail.


Security Set Security Type

Department (not using the tree)

PER_ORG_ASGN Person Organizational Relationship

(Employee, Contingent Worker, Person of Interest)

People without Jobs Person of Interest Type

Business Unit

Location

Institution

Departments Dept Security Tree

Departments (non Tree)

Setid

Job Openings Dept Security Tree

Business Unit

Location

Company

U.S. Federal Gov’t

People with Jobs

Dept Security Tree

Business Unit

Location

Company

Salary Grade

Enable the security access types you wish to use in your implementation. You can choose a different setup at anytime - even in production.

Each type defines exactly how the data will be treated. You can change some of the attributes on the pre-configured types to better suit your implementation.


Component: SCRTY_TYPE2_TBL

Navigation: Set Up PeopleSoft Enterprise HRMS, Security, Core Row Level Security, Security Types

Security Type Table Page

Most of the fields on the Security Type Table page are display only for PeopleSoft Enterprise-delivered security access types. For system-delivered security types, you can modify only the following fields:

• Enabled

• Include Future Dates

• Special Job Security Version

This is an example of the security type definition for the People with Jobs security set using the department security tree.

Each type can only belong to one security set and will update only one security join table. Once you choose the security set, the system displays the transaction security join table for that set.

Enabling or Disabling a Security Type

You can choose to enable or disable a security type by selecting or clearing the Enabled check box. You will need to refresh the appropriate data in the user and transaction security join tables whenever you enable a security access type.

You can choose to enable or disable a

security type by selecting or clearing the Enabled check box.


Future Dated Rows

You can also choose whether to include future-dated transactions from the transaction recording the security join table for this access type. Normally, only current transaction data is used for security but there are cases when you want to be able to use the data as of a future date. Selecting the Include Future Dates check box enables users with this type of security to access future-dated data. For example, users can view the Job record a future employee or the host record for an employee who will start their global assignment in a month. You can give some users access to future date rows while limiting others to the current-dated rows by giving them security using different types.

For security types that use JOB as the transaction table, you can choose which actions would cause a future dated row to be included in the security join table. Select actions on the Security Installation Settings component.

Use Department Security Tree

This check box indicates that the security access type is based on a department security tree. When the Use Dept Sec Tree? check box is selected; the system populates the rest of the fields for use with the department security tree.

Transaction Table

This is the transaction record that contains the attribute that this security type is based on. In this case, it is the Department ID in the JOB record.

Security Keys

The security key fields contain the actual attributes that are used for this security type. In some cases, a parent attribute will also be required, such as the SetID or the Business Unit. Because we are using the Department Security Tree and the Trees are keyed on SETID, we need to provide the SetID for the Department, not the Business Unit. The JOB record has the SetID for the DEPTID field stored on it as SETID_DEPT. Up to three keys can be used although 3 are not normally necessary. Of the delivered security types, only the People with Jobs by Salary Grade type required the 3 keys.

You must include the prompt record for each field. This prompt record is used in the components where the actual values for these fields are assigned to a permission list. If the field is a translate value then a view must be created to return those translate values.

For security types that use JOB as the transaction table, you can choose which

actions would cause a future dated row to be included in the security join table.

Select actions on the Security Installation Settings component.


Special Job Security Versions

The system only displays this group box when the transaction record is JOB. The fields shown will depend on which of these have been enabled on the Security Installation Settings component.

What each of the options means is described in the Special Job Security section.

Security Type SQL Page

The second page in this component shows the SQLID for the SQL objects used in the Application Engine program SCRTY_SJTUPD for refreshing the transaction SJT. You cannot modify this information for the delivered security types – nor is it important for you to refer to or understand this SQL unless you wish to create your own security types. Please refer to the customization section for more information.

Assigning the Transaction Security Field Values to Security to Permission Lists. You need to define the actual data values for the security type fields that a user can access. How you define this will depend on your actual functional needs. There are two components used to capture these groupings (Security by Dept Tree and Security by Permission List). Which you use depends on the security types you enabled.

For security types that use the department security tree, you must assign security values using the Security by Dept Tree component. All other security types are assigned security values using the Security by Permission List component.

Security by Department Tree

Data permission based on department security trees is virtually the same in release 8.9 as it was in past releases with these two differences: There are two

• You can set up security access for different security sets.

In earlier releases you could only control data access to people based on department. Now you can also control data access to the departments themselves.

• The refresh process to update the security tables has changed.

Follow these steps to set up security by department tree:

You need to define the actual data values

for the security type fields that a user can access. How you define this will depend on

your actual functional needs.


1. Create the Permission Lists

You first create Permission Lists using the PeopleTools, Security, Permissions & Roles, and Permission Lists component. You only need to define a name and enter a description for the permission list.

It will make your implementation simpler if you use a standard prefix for permission lists that you will be using for row level security. In our PeopleSoft Enterprise HRCS Demo data, we use the prefix HCDP. Once you have created your permission lists you can assign row level security data to them.

A row security class is just a permission list that has been associated with a user via the Row Security List field (ROWSECCLASS) on the User Profile – General page. There is no special setting that you enter in the Permission List component for these.

2. Create the Department Security Trees

Create and maintain your department security trees. This process has not changed in anyway from the previous releases. Please refer to the Oracle’s PeopleSoft Enterprise HRMS 8.9 Application Fundamentals PeopleBook, “Setting Up and Administering PeopleSoft Enterprise HRMS Security” for instructions on doing this.

3. Assign the Department Access to the Permission Lists

Assigning the department access to a row security class permission list is slightly different from earlier releases. The component is now called Security by Dept Tree and now you will enter the effective date that you want the tree data to be controlled by directly in this page.

Whenever you enter the page, it will default to today’s date. You can change this to a date in the past or the future; depending on what effective date (EFFDT) you want to pick up for the trees you choose. The system will use effective date for each tree that is less than or equal to the effective date you enter on the page. The actual date of the tree is stored in the underlying table SCRTY_TBL_DEPT that this component updates.

The rest of the page functions the same as it did in earlier releases. Please refer to the Oracle’s PeopleSoft Enterprise HRMS 8.9 Application Fundamentals PeopleBook, “Setting Up and Administering PeopleSoft Enterprise HRMS Security” for instructions on doing this.

It will make your implementation simpler if

you use a standard prefix for permission lists that you will be using for row level

security.


Component: SCRTY_DATA

Navigation: Set Up PeopleSoft Enterprise HRMS: Security: Core Row Level Security: Security by Dept Tree

4. Refresh the Operator Security Join Table - SJT_CLASS_ALL

Because we need to capture the actual DeptIDs that a permission list has access to in the security join table, we need to run a process that will figure these out based on the department values you defined in the Security by Dept Tree page (which saves to the SCRTY_TBL_DEPT table). The Application Engine process is called SCRTY_CLASS and replaces the HR_FASTVIEW process. One difference is that this process updates only the operator (user) security join table. There is a separate App Engine to update the transaction SJTs. This process is also different now because you can choose to refresh only part of the SJT table instead of the whole thing. If all you have done is created a new Permission List, you could choose to refresh just the data affected by that one Permission list. Or if you have modified two department security trees, you can choose to refresh just the data affected by those two trees.

See the section on Refreshing the Operator Security Join Table for more information.


Component: SCRTY_OPR_RC

Navigation: Set Up PeopleSoft Enterprise HRMS: Security: Core Row Level Security: Refresh SJT_CLASS_ALL

5. Assign the Row Security Permission Lists to the Users

You now need to associate the row security permission lists with users. This is done User Profiles – General page. A user can only have one row security permission list.

Navigation: PeopleTools, Security, User Profiles, User Profiles, General


Security by Permission List

Use the Security by Permission List component for all security types that are not based on a department security tree.

Follow these steps to set up security by permission list:

1. Create the Permission Lists You first create Permission Lists using the PeopleTools, Security, Permissions & Roles, and Permission Lists component. You only need to define a name and enter a description for the permission list. It will make your implementation simpler if you use a standard prefix for permission lists that you will be using for row level security. In our PeopleSoft Enterprise HRCS Demo data, we use the prefix HCDP. Once you have created your permission lists you can assign row level security data to them. Associate these permission lists with a user via security roles instead of using the Row Security permission list field on the User Profile – General page. This allows you to assign a user multiple security setups because a user can have multiple roles. You will want to create a permission list for each unique grouping of security values that you will be entering. For example, if you were using the security type People with Jobs by Business Unit, you would want to set up one permission list per business unit. You can then use security roles to group these separate permission lists into functional groups.

Permission List Set Type Value HCDPBUWEST People with Jobs By Business Unit WEST

HCDPBUEAST People with Jobs By Business Unit EAST

HCDPBUNORTH People with Jobs By Business Unit NORTH

HCDPBUSOUTH People with Jobs By Business Unit SOUTH

You will want to create a permission list for

each unique grouping of security values that you will be entering.


2. Assign the Access to the Permission Lists Component: SCRTY_CLASS

Navigation: Set Up PeopleSoft Enterprise HRMS, Security, Core Row Level Security, Security by Permission List

For the security sets and security access types you select for this permission list, select the key values that this permission list will have access to. For example, to give the HCDPBUWEST permission list access to business unit WEST, select the People with Jobs security set, the By Business Unit access type, and in the WEST business unit in the Key 1 field

The record behind this component is SJT_CLASS.

When you save this component, SavePostChange PeopleCode will update the Operator Security Join Table (SJT_CLASS_ALL) automatically. It can also be refreshed at anytime by using the App Engine Process: Refresh SJT_CLASS_ALL (SCRTY_CLASS).

3. Group the Permission Lists into Roles

On the Roles – Permission Lists page attach the appropriate permission lists to the role.

Security Role Permission List

Security- People with Jobs in East BU HCDPBUEAST

Security- People with Jobs in West BU HCDPBUWEST

Security- People with Jobs in North BU HCDPBUNORTH

Security- People with Jobs in South BU HCDPBUSOUTH



Security- People with Jobs HCDPBUEAST HCDPBUWEST HCDPBUNORTH HCDPBUSOUTH

Security- People with Jobs in Sales Business Units HCDPBUEAST HCDPBUNORTH

Navigation: PeopleTools, Security, Permissions & Roles, Roles

6. Assign the Roles to Users

You would then assign the roles to users on the User Profile –Roles page.

User Security Role

User A Security- People with Jobs in East BU Security – People with Jobs in West BU

User B Security- People with Jobs in West BU User C Security- People with Jobs in North BU

Security- People with Jobs in South BU User D Security- People with Jobs User E Security- People with Jobs in Sales Business Units


Navigation: PeopleTools, Security, Users, User Profile

You can assign multiple roles to a user. This means that you could choose to not create a role that has all of the permission lists, but instead assign each individual role to a user. It all depends on which setup makes your maintenance easier.

Variations

You might also choose to put multiple business units in one permission list

Permission List Business Unit

HCDPBUWEST WEST

HCDPBUEAST EAST

HCDPBUNORTH NORTH

HCDPBUSOUTH SOUTH

HCDPBUSALES EAST NORTH

If you enable multiple security types, you can choose to group these under permission lists or roles. For example, if you also enable access to People with Jobs by Company, you might have these Permission Lists:

Permission List Set Type Field Value


And you add two new roles


Security: People in Company ABC HCDPCOMP1

Security: People in all Companies HCDPCOMP1

HCDPCOMP2

And then give User A an additional role

User Security Role

User A Security- People with Jobs in East BU

Security: People in Company ABC

The user’s row level security profile is the accumulation of all of the data in the individual permission lists. These are joined together in the security views using OR. This means that User A has access to:

People with Jobs in the Business Unit East OR

People with Jobs in the Company ABC South

This does not mean that User A has access to People with Jobs who are in Company ABC AND are also in Business Unit East. User A will have access to anyone who has a BU of EAST or anyone in Company ABC. So, they will have access to a Person who is in BU East even if they are in Company DEF.

You need to keep this rule in mind when creating your permission lists and roles and are assigning them to users.

HCDPBUWEST People with Jobs Business Unit WEST

HCDPBUEAST People with Jobs Business Unit EAST

HCDPBUNORTH People with Jobs Business Unit NORTH

HCDPBUSOUTH People with Jobs Business Unit SOUTH

HCDPBUSALES People with Jobs People with Jobs

Business Unit Business Unit

EAST NORTH

HCDPCOMP1 People with Jobs Company ABC Company

HCDPCOMP2 People with Jobs Company DEF Company

HCDPSEC1 People with Jobs People with Jobs

Business Unit Company

WEST ABC Company


How Security Views work The SJTs are used in core security views, which can be used as component search records, Query security records, SQR security records, security prompt views, or inside product specific security search views that need to include additional criteria or search/list fields. The core security search views also join in additional information that can be used for search criteria, where criteria, or list box information.

The views contain the security fields themselves along with other fields that are normally present for that type of view:

• The component search view includes the Name fields as alternate search fields along with fields normally present in the list box or that is used by transactional search views to further customize it.

Each EMPLID appears as many times as they have distinct search items (EMPLID/ERN combination).

• The Query security view includes only the security and the EMPLID or EMPLID/EMPL_RCD fields. . It is pared down as much as possible to increase performance in queries. Each EMPLID or EMPLID/EMPL_RCD appear just once.

• The process security views do not include alternate search fields or list box items. Processes operate on the assumption that the EMPLID or EMPLID/EMPL_RCD is known and the batch process just needs to validate access based on those keys. All other join records are removed to prevent performance drag and to remove the multiple rows for a single person. Each EMPLID or EMPLID/EMPL_RCD appear just once.

The security prompt view includes the NAME fields and each EMPLID appears only once. This type of view is used where you need to provide a prompt/edit value for a field in a component and the values returned in the prompt may different for the user than the values returned when they use the component search view.

Example:

User A has access to all people in Dept 1020 in BU ABC and can view the Job Data or Personal Data records of these people. In the Job Data component there is a Supervisor ID field (SUPERVISOR_ID). This field contains the EMPLID of the person’s supervisor. When User A needs to enter that field, he will need to access more people than just the ones in Dept 1020. If the prompt/edit view used is just against the PERSON_NAME view then every person in the database is shown. To limit User A to only seeing people in BU ABC instead of everyone you need to change the security prompt view. This is still a row level security access issue, but the usage is different than the who can I see/edit use.

The SJTs are used in core security views, which can be used as component search

records, Query security records, SQR security records, security prompt views, or

inside product specific security search views that need to include additional

criteria or search/list fields.


Example:

User B has access to modify the Department setup data for all Deptids in BU ABC.

User B also has access to modify the personal/job data of all people in BU ABC and DEF.

When User B is in the Job Data component and wants to select a DEPTID to assign to a person who is in BU DEF, he needs to have prompt access to the Deptids in BU ABC and DEF (at least). The security view used on the JOB.DEPTID recfield needs to be different than the security view used on the JOB_DATA search record.

Core Security Views

Type Security View EMPL RCD

Include Future

POI TYPE

APPT Type Rows

All Persons PERALL_SEC_SRCH

No Yes All No Kenmu

One row per EMPLID and distinct Search Items

PERAll_SEC_QRY

No No All No Kenmu

One row per EMPLID

PERALL_SEC_SQR

No No All No Kenmu

One row per EMPLID

People with Jobs

PERS_SRCH_GBL

No Yes Ones with Jobs

No Kenmu

One row per EMPLID/EMPL_RCD/Future and distinct Search Items

PERS_SRCH_QRY

No No Ones with Jobs

No Kenmu

One row per EMPLID

FAST_SCRTY_SQR

Yes But ignored

No Ones with Jobs

No Kenmu

One row per EMPLID

People/ Assignment with Jobs

EMPLMT_SRCH_GBL

Yes Yes Ones with Jobs

No Kenmu

One row per EMPLID/EMPL_RCD/Future and distinct Search Items

EMPLMT_SRCH_QRY

Yes No Ones with Jobs

No Kenmu

One row per EMPLID/EMPL_RCD


Type Security View EMPL RCD

Include Future

POI TYPE

APPT Type Rows

FAST_SCRTY_SQR

Yes No Ones with Jobs

No Kenmu

One row per EMPLID/EMPL_RCD

People without Jobs

POI_SEC_SRCH n/a n/a Ones w/out Job

n/a One row per EMPLID, POI_TYPE and distinct Search Items

POI_SEC_QRY n/a n/a Ones w/out Job

n/a One row per EMPLID/ POI_TYPE

POI_SEC_SQR n/a n/a Ones w/out Job

n/a One row per EMPLID/ POI_TYPE

There are also product specific security search views that are based on these core views, but have different attributes or rules.


Entity Relationship Diagrams

People with Jobs and People without Jobs

Each Security View (like PERS_SRCH_GBL) above determines which Security set (PPLJOB, PPLPOI) are included.

Department Access


Security Records

SCRTY_SET_TBL: Security Sets

Defines what data is being secured.

Fieldname Key Type Length Label

SCRTY_SET_CD Key Char 10 Security Set

DESCR Char 30 Description

DESCRSHORT Char 10 Short Description

RECNAME_SJT Char 15 Transaction SJT

RECNAME_SJT_TMP Char 15 SJT Temp table for AE Process

OBJECTOWNERID Char 4 Objectownerid

SYSTEM_DATA_FLG Char 1 System Data

SEC_SQL_FLDNM Char 30 SQLID for Value Field List

COMMENTS Text 16 Comments

System Data for Security Sets

Set Description Transaction SJT SJT Temp SQLID for Field

List

DEPT Departments SJT_DEPT SJT_DEPT_TMP SEC_DEPT_FLDVAL

PPLJO

B

People with

Jobs

SJT_PERSON SJT_PRJ_TMP SEC_PPLCORE_FLD

NM

PPLPOI People

without Jobs

SJT_PERSON SJT_PRJ_TMP SEC_PPLCORE_FLD

NM

PPLUS

F

US Federal

People with

Jobs

SJT_PERSON_USF SJT_PRJUSF_TM

P

SEC_PPLUSF_FLDN

M

RSOPN Recruiting Job

Openings

HRS_SJT_JO HRS_SJTJO_TMP SEC_RSOPN_FLDN

M

SCRTY_TYPE_TBL: Security Types

Defines how the Data in the Set will be secured.

Fieldname Key Type Len Label




SCRTY_TYPE_CD Key Char 3 Security Type

DESCR Char 30 Description

DESCR_LABEL Char 30 Transaction Label

DESCRSHORT Char 10 Short Description

ENABLED Char 1 Enabled

FUTURE_FLG Char 1 Include Future data

RECNAME_S_TRANS Char 15 Transaction Table

KEY1_PROMPT_REC Char 15 Prompt Record for Sec Key

1

KEY1_PROMPT_FLD Char 18 Security Key 1


2



3


HCR_HOME_HOST_TYPE Char 1 International Type

HCR_JPN_SEC_FLG Char 1 JPN Appointment

HCR_ASGN_TYPE Char 1 Access Type

OBJECTOWNERID Char 4 Object Owner

TREE_NAME Char 18 Tree Name

SYSTEM_DATA_FLG Char 1 System Data

System Data for Security Types

Set Type Description Transaction table Tree

DEPT 021 Departments by Tree DEPT_TBL DEPT_SECURITY

DEPT 022 Departments - non

Tree

DEPT_TBL

DEPT 023 Departments by Setid DEPT_TBL

PPLJOB 001 Job Department Tree JOB DEPT_SECURITY

PPLJOB 002 Job Location JOB


Set Type Description Transaction table Tree

PPLJOB 003 Job Business Unit JOB

PPLJOB 004 Job Company JOB

PPLJOB 005 Job Reg Region JOB

PPLJOB 014 Job Salary Grade JOB

PPLJOB 015 Person Organization PER_ORG_ASGN

PPLJOB 025 Job - Deptid - non

Tree

JOB

PPLPOI 006 POI Business Unit PER_POI_SCRTY

PPLPOI 007 POI Location PER_POI_SCRTY

PPLPOI 008 POI Institution PER_POI_SCRTY

PPLPOI 009 Person of Interest PER_POI_TYPE

PPLUSF 016 US Federal

Department Tree

GVT_JOB DEPT_SECURITY

PPLUSF 017 US Federal Location GVT_JOB

PPLUSF 018 US Federal Company GVT_JOB

PPLUSF 020 US Federal Salary

Grade

GVT_JOB

RSOPN 010 RS Company HRS_JOB_OPENING

RSOPN 011 RS Business Unit HRS_JOB_OPENING

RSOPN 012 RS Dept Id HRS_JOB_OPENING DEPT_SECURITY

RSOPN 013 RS Location HRS_JOB_OPENING

Set Typ

e

Prompt for

Key1

Key 1 Prompt

for Key 2

Key 2 Prompt

for Key3

Key 3

DEPT 021 SEC_DEPT_

SET_VW

SETID DEPT_TB

L

DEPTID

DEPT 022 SET_DEPT_

VLD_VW

SETID DEPT_TB

L

DEPTID

DEPT 023 SET_DEPT_

VLD_VW

SETID

PPLJOB 001 SEC_DEPT_

SET_VW

SETID_DEP

T

DEPT_TB

L

DEPTID


Set Typ

e

Prompt for

Key1

Key 1 Prompt

for Key 2

Key 2 Prompt

for Key3

Key 3

PPLJOB 002 BUS_UNIT_

TBL_HR

BUSINESS_

UNIT

LOCATIO

N_TBL

LOCATION


TBL_HR

BUSINESS_

UNIT

PPLJOB 004 COMPANY_

TBL

COMPANY

PPLJOB 005 REG_STAN

DARD_VW

REG_REGIO

N


TBL_HR

BUSINESS_

UNIT

SAL_PLA

N_TBL

SAL_ADMI

N_PLAN

SAL_GRA

DE_TBL

GRADE

PPLJOB 015 PER_ORG_

VW

PER_ORG


TBL_HR

BUSINESS_

UNIT

DEPT_TB

L

DEPTID

PPLPOI 006 POI_NOJOB

_VW

POI_TYPE BUS_UNI

T_TBL_H

R

BUSINESS

_UNIT


_VW

POI_TYPE BUS_UNI

T_TBL_H

R

BUSINESS

_UNIT

LOCATIO

N_TBL

LOCATIO

N


_VW

POI_TYPE INSTITUT

ION_TBL

INSTITUTIO

N


_VW

POI_TYPE

PPLUSF 016 SEC_DEPT_

SET_VW

SETID_DEP

T

DEPT_TB

L

DEPTID

PPLUSF 017 LOCATION_

TBL

LOCATION

PPLUSF 018 COMPANY_

TBL

COMPANY

PPLUSF 020 BUS_UNIT_

TBL_HR

BUSINESS_

UNIT

SAL_PLA

N_TBL

SAL_ADMI

N_PLAN

SAL_GRA

DE_TBL

GRADE

RSOPN 010 COMPANY_

TBL

COMPANY


Set Typ

e

Prompt for

Key1

Key 1 Prompt

for Key 2

Key 2 Prompt

for Key3

Key 3

RSOPN 011 BUS_UNIT_

TBL_HR

BUSINESS_

UNIT

RSOPN 012 SEC_DEPT_

SET_VW

SETID_DEP

T

DEPT_TB

L

DEPTID

RSOPN 013 BUS_UNIT_

TBL_HR

BUSINESS_

UNIT

HRS_LO

CATION_

VW

HRS_PRM_

LOCATION

SJT_CLASS: Security data by Permission List (non-tree)

SJT_CLASS stores security data by permission list for security types that do not use the department security tree.

Sample Data

Permission List Set Type Key 1

HCDPALLPOI PPLPOI 009 00000





SCRTY_TBL_DEPT: Security data by Permission List (tree)

SCRTY_TBL_DEPT stores security data by row security permission list for security types that use the department security tree.


ROWSECCLASS Key Char 30 Permission List

SETID Key Char 5 Setid

DEPTID Key Char 10 Dept Id

ACCESS_CD Char 1 Access Code

TREE_EFFDT Date 10 Effective date of Tree

TREE_NODE_NUM Nor 10 Tree Node Number

TREE_NODE_NUM_END Nbr 10 Tree Node End


Sample Data (some)

Permission

List

Setid Deptid Access Date Tree

node

Tree Node

End

HCDPALL AUS01 ALL

DEPTS

Y 01-Jan-80 1 2000000000

HCDPALL BEL01 10200 Y 01-Jan-80 1 2000000000

HCDPALL BNCAN B001 Y 01-Jan-80 1 2000000000

SJT_CLASS_ALL: Security Join Table for the Operator Side

SJT_CLASS_ALL is the security join table for operator security data, both tree and non-tree based.


CLASSID Key Char 30 Permission List


SCRTY_TYPE_CD Key Char 3 Security Type

SCRTY_KEY1 Key Char 20 Security Key 1



TREE Char 1 Tree

The data for this table comes from the SJT_CLASS table and the SCRTY_TBL_DEPT table.

The TREE field is Y/N to indicate that the data is coming from the department security tree and the CLASSID must only be defined on the PSOPDEFN.ROWSECCLASS. This is because there are still places in the PeopleSoft Enterprise HRCS product that use the SCRTY_TBL_DEPT data outside of this new security structure. These places expect that the CLASSID is defined only as the user’s ROWSECCLASS.

The SJT_CLASS data is loaded row for row. The SCRTY_TBL_DEPT data is loaded by determining for each CLASSID exactly what DEPTIDs are accessible by looking at the Dept Security Tree itself. All the DEPTIDs that are at and below the department node defined in the SCRTY_TBL_DEPT table are included unless the DEPTID exists in the SCRTY_TBL_DEPT with an ACCESS_CD of N- No Access. This is what happens when the Refresh SJT_CLASS_ALL process is run and why it needs to be run.


Sample Data (some)

CLASSID Set Type Key1 Key2 Key3 Tree Flag

HCDPALLPOI PPLPOI 009 00000 N





HCDPALL PPLJOB 001 AUS01 10000 Y



HCDPALL PPLJOB 001 BNCAN B001 Y

HCDPALL PPLJOB 001 BNCAN B200 Y

HCDPALL DEPT 021 AUS01 10000 Y



HCDPALL DEPT 021 BNCAN B001 Y

HCDPALL DEPT 021 BNCAN B200 Y


SJT_PERSON: Security Join Table for People

SJT_PERSON is the security join table for the person transactional data. This table is updated from JOB, PER_POI_TYPE, PER_POI_SCRTY, and PERS_NID. It contains the data for the PPLJOB and PPLPOI security sets.

The record contains the data from the transaction records joined with the security setup data. There is one row for each security type setup and JOB or PER_POI_TYPE/PER_POI_SCRTY rows.

Example

These rows come from JOB – Emplid KU0004 Empl_Rcd 0. One row for each Security Type for the PPLJOB Security set. Type 001 is the Department Security Tree so Key1 will be the SETID_DEPT and Key2 will be the DEPTID. Type 002 is Location so Key1 will be the Business Unit and Key 2 will be the Location. For this Emplid/Empl_rcd, two rows are created with the first 4 columns being different. The data from JOB itself will be the same for both rows.

The record contains the data from the transaction records joined with the

security setup data. There is one row for each security type setup and JOB or

PER_POI_TYPE/PER_POI_SCRTY rows.


Type Key1 Key2 Key3 EMP

LID

EMP

L_R

CD

BU Setid

Dept

Dept

Id

Setid

Loc

Loca

tion

Com

pany

001 SHA

RE

4200

0

KU00

04

0 US00

4

SHA

RE

4200

0

SHA

RE

KUN

Y00

GBI

002 US00

4

KUN

Y00

KU00

04

0 US00

4

SHA

RE

4200

0

SHA

RE

KUN

Y00

GBI

These rows come from PER_POI_TYPE. Each distinct EMPLID/POI_TYPE will cause one row in SJT_PERSON for each relevant Security Type (which is 009).

Type Key1 Key2 Key3 EMP

LID

POI

Type

BU Setid

Dept

Depti

d

Setid

Loc

Loca

tion

Com

pany

009 0000

0

Z890

06

0000

0

0

009 0000

7

HXS

EC20

0000

7

0

009 0000

7

HXS

EC22

0000

7

0

009 0000

8

HX65

4D

0000

8

0

009 0000

8

HX65

4F

0000

8

0

These rows come from PER_POI_SCRTY. Each distinct EMPLID/POI_TYPE/Security data will cause one row in SJT_PERSON for each relevant Security Type (which is 006 - BU).

Please see the section on People without Jobs for more information on PER_POI_SCRTY.


Type Key1 Key2 Key3 EMPLID POI_TYPE BU

006 00007 HXBU1 HXSEC22 00007 HXBU1

006 00008 HXBU1 HX654D 00008 HXBU1

006 00008 HXBU1 HX654F 00008 HXBU1

006 00008 LEBU LEPOI02 00008 LEBU

006 00008 ZBU00 Z89002 00008 ZBU00

006 00009 PSUNV SFTRN017 00009 PSUNV

SJT_DEPT: Security Join Table for Departments

SJT_DEPT is the security join table for the department transactional data. This table is updated from the DEPT_TBL. It contains the data for the DEPT security set.

Type Key1 Key2 Key3 SETID DEPTID Dept EFFDTs

021 AUS01 10000 AUS01 10000 01-Jan-80

021 AUS01 11000 AUS01 11000 01-Jan-80

021 AUS01 12000 AUS01 12000 01-Jan-80

021 AUS01 13000 AUS01 13000 01-Jan-80

SJT_PERSON_USF: Security Join Table for USF Employees

SJT_PERSON_USF is the security join table for the US Federal Person transactional data. This table is updated from GVT_JOB. It contains the data for the PPLUSF security set.


HRS_SJT_JO: Security Join Table for Recruiting Solutions Job Openings

HRS_SJT_JO is the security join table for the Recruiting Solutions job openings transactional data. This table is updated from HRS_JOB_OPENING table. It contains the data for the RSOPN security set.

Core View Structure and View Text All security views share some characteristics both in their structure and their view text.

Each view must include the OPRID as a key field, the keys for the transaction data, and any additional fields that are used as search or list box fields. Most core views also include other fields from the security join record that other views can enter where criteria against.

We are not including ROWSECCLASS as a key in the security views. This is because if we do, then we would have to require a ROWSECCLASS be entered for every USERID. The reason for this is that when Tools does the join to PSOPRDEFN behind the scenes, it will put the value of PSOPRCLS into the field returned from PSOPRDEFN.ROWSECCLASS if the ROWSECCLASS is blank. If the PSOPRCLS is also blank, then the USERID is returned. This makes it

Each view must include the OPRID as a

key field, the keys for the transaction data, and any additional fields that are used as search or list box fields. Most core views

also include other fields from the security join record that other views can enter

where criteria against.


impossible to join to the SJT_CLASS_ALL table. Including the ROWSECCLASS as a non-key field in the security view is okay, but does not provide any benefit. You will still find it in some views because it was less risky to leave it there for now.

The core views need to join in PSOPRDEFN, SJT_CLASS_ALL, and the appropriate transaction SJT. For example, for People with Jobs and/or People without Jobs the SJT record is SJT_PERSON.

A – Add the records for the From SELECT DISTINCT OPR.OPRID , SEC.EMPLID ,SEC.EMPL_RCD

FROM PSOPRDEFN OPR , PS_SJT_CLASS_ALL CLS , PS_SJT_PERSON SEC , PS_NAMES NM WHERE

B – Choose the Security Set

(CLS.SCRTY_SET_CD = 'PPLJOB' )

C – Join the SJTs keys

AND (CLS.SCRTY_TYPE_CD = SEC.SCRTY_TYPE_CD AND CLS.SCRTY_KEY1 = SEC.SCRTY_KEY1 AND CLS.SCRTY_KEY2 = SEC.SCRTY_KEY2

AND CLS.SCRTY_KEY3 = SEC.SCRTY_KEY3)

D – Join for Security using Dept Tree (only join To the PSOPRDEFN.ROWSECCLASS)

AND ( (CLS.TREE = 'Y' AND CLS.CLASSID = OPR.ROWSECCLASS )

E – and/or Join for other Security Types (can join to ROWSECCLASS or the User’s Classes ) OR (CLS.TREE = 'N' AND (CLS.CLASSID = OPR.ROWSECCLASS OR CLS.CLASSID IN ( SELECT DISTINCT C.CLASSID FROM PSOPRDEFN A , PSROLEUSER B , PSROLECLASS C WHERE A.OPRID = B.ROLEUSER AND B.ROLENAME = C.ROLENAME AND A.OPRID = OPR.OPRID ) ) ) )

To make developing and maintaining security views, we provide several objects that are used as building blocks for the views and view text.

To make developing and maintaining

security views, we provide several objects that are used as building blocks for the

views and view text.


Persons

PERS_SRCH_GBL

SELECT DISTINCT %Sql(SCRTY_SEL_PKEY, OPR,SEC) , %Sql(SCRTY_SEL_CORSBR, NM,SEC) , %Sql(SCRTY_SEL_FLDSBR,SEC) FROM %Sql(SCRTY_PER_FROM) , PS_NAMES NM WHERE (CLS.SCRTY_SET_CD = 'PPLJOB' )

AND %Sql(SCRTY_WHERE) AND %Sql(SCRTY_NO_APPT1) AND SEC.EMPLID = NM.EMPLID AND NM.NAME_TYPE = 'PRI' AND NM.EFFDT = ( SELECT MAX(B.EFFDT) FROM PS_NAMES B WHERE B.EMPLID = NM.EMPLID AND B.NAME_TYPE = 'PRI' AND B.EFFDT <= %CurrentDateIn ) Resolved: SELECT DISTINCT OPR.OPRID , SEC.EMPLID ,SEC.EMPL_RCD , NM.NAME_DISPLAY ,NM.LAST_NAME_SRCH ,NM.SECOND_LAST_SRCH ,NM.FIRST_NAME ,NM.LAST_NAME ,NM.LAST_NAME_SRCH ,NM.NAME_AC ,SEC.PER_ORG ,SEC.POI_TYPE ,SEC.BUSINESS_UNIT ,SEC.SETID_DEPT ,SEC.DEPTID ,SEC.SETID_LOCATION ,SEC.LOCATION , SEC.COMPANY , SEC.REG_REGION ,SEC.INSTITUTION ,SEC.NATIONAL_ID ,SEC.HR_STATUS , SEC.APPT_TYPE ,SEC.EMPL_STATUS ,SEC.OTHER_ID_JPN ,SEC.FUTURE_FLG ,SEC.REPORTS_TO


,SEC.SUPERVISOR_ID ,SEC.SETID_JOBCODE ,SEC.JOBCODE FROM PSOPRDEFN OPR , PS_SJT_CLASS_ALL CLS , PS_SJT_PERSON SEC , PS_NAMES NM WHERE (CLS.SCRTY_SET_CD = 'PPLJOB' ) AND (CLS.SCRTY_TYPE_CD = SEC.SCRTY_TYPE_CD AND CLS.SCRTY_KEY1 = SEC.SCRTY_KEY1 AND CLS.SCRTY_KEY2 = SEC.SCRTY_KEY2 AND CLS.SCRTY_KEY3 = SEC.SCRTY_KEY3) AND ( (CLS.TREE = 'Y' AND CLS.CLASSID = OPR.ROWSECCLASS ) OR (CLS.TREE = 'N' AND (CLS.CLASSID = OPR.ROWSECCLASS OR CLS.CLASSID IN ( SELECT DISTINCT C.CLASSID FROM PSOPRDEFN A , PSROLEUSER B , PSROLECLASS C WHERE A.OPRID = B.ROLEUSER AND B.ROLENAME = C.ROLENAME AND A.OPRID = OPR.OPRID ) ) ) ) AND SEC.APPT_TYPE <> '1' AND SEC.EMPLID = NM.EMPLID AND NM.NAME_TYPE = 'PRI' AND NM.EFFDT = ( SELECT MAX(B.EFFDT) FROM PS_NAMES B WHERE B.EMPLID = NM.EMPLID AND B.NAME_TYPE = 'PRI'

AND B.EFFDT <= { fn CURDATE() } )

Standard Subrecords and associated Sql Objects

Subrecord Description SQL Object SQL Text

PER_KEY_SBR Security Keys with

EMPL_RCD not a key

SCRTY_SEL_PKEY %P(1).OPRID,

%P(1).ROWSECCLASS,

%P(2).EMPLID,

%P(2).EMPL_RCD

EMPL_KEY_SBR Security Keys with

EMPL_RCD a key

SCRTY_SEL_PKEY (same

sql as PER_KEY_SBR)

%P(1).OPRID,

%P(1).ROWSECCLASS,

%P(2).EMPLID,

%P(2).EMPL_RCD

PERS_SRCH_SBR Fields used for Search and

List box from

SJT_PERSON

SCRTY_SEL_CORSBR

SCRTY_SEL_PERSBR

(either works)

%P(1).NAME

,%P(1).LAST_NAME_SRCH

,%P(1).SECOND_LAST_SR



CH

,%P(1).FIRST_NAME

,%P(1).LAST_NAME


,%P(1).NAME_AC

,%P(2).PER_ORG

,%P(2).POI_TYPE

,%P(2).BUSINESS_UNIT

,%P(2).SETID_DEPT

,%P(2).DEPTID

,%P(2).SETID_LOCATION

,%P(2).LOCATION

, %P(2).COMPANY

, %P(2).REG_REGION

,%P(2).INSTITUTION

,%P(2).NATIONAL_ID

,%P(2).HR_STATUS

PERS_SRCH2_SBR Just the Name fields for

the search and List

SCRTY_SEL_NMSBR %P(1).NAME


,%P(1).SECOND_LAST_SR

CH

,%P(1).FIRST_NAME

,%P(1).LAST_NAME


,%P(1).NAME_AC

SCRTY_FLD_SBR Other fields from

SJT_PERSON table that

might be used in later

views.

SCRTY_SEL_FLDSBR %P(1).APPT_TYPE

,%P(1).EMPL_STATUS

,%P(1).OTHER_ID_JPN

,%P(1).FUTURE_FLG

,%P(1).REPORTS_TO



,%P(1).SUPERVISOR_ID

,%P(1).SETID_JOBCODE

,%P(1).JOBCODE

SCRTY_PAY_SBR Payroll fields from the

SJT_PERSON

SCRTY_SEL_PAYSBR %P(1).PAY_SYSTEM_FLG

, %P(1).PAYGROUP

, %P(1).GP_PAYGROUP

SQL Object SQL Text

SCRTY_PER_FROM PSOPRDEFN OPR, PS_SJT_CLASS_ALL CLS ,

PS_SJT_PERSON SEC

SCRTY_DEPT_FROM PSOPRDEFN OPR, PS_SJT_CLASS_ALL CLS ,

PS_SJT_DEPT SEC

SCRTY_WHERE (CLS.SCRTY_TYPE_CD = SEC.SCRTY_TYPE_CD

AND CLS.SCRTY_KEY1 = SEC.SCRTY_KEY1

AND CLS.SCRTY_KEY2 = SEC.SCRTY_KEY2

AND CLS.SCRTY_KEY3 = SEC.SCRTY_KEY3)

AND ( (CLS.TREE = 'Y'

AND CLS.CLASSID = OPR.ROWSECCLASS )

OR (CLS.TREE = 'N'

AND (CLS.CLASSID = OPR.ROWSECCLASS

OR CLS.CLASSID IN (

SELECT DISTINCT C.CLASSID

FROM PSOPRDEFN A

, PSROLEUSER B

, PSROLECLASS C

WHERE A.OPRID = B.ROLEUSER

AND B.ROLENAME = C.ROLENAME

AND A.OPRID = OPR.OPRID ) ) ) )

SCRTY_NO_APPT1 SEC.APPT_TYPE <> '1'


Enabling Different fields for the Search and List Box

The fields that show up as search and list box fields are determined by the Record Field Use properties. Since most of the search views will use the core views or will use the subrecords that the core views do, it is a simple matter of choosing which fields to enable.

For Example, the PERS_SRCH_GBL core view uses the PERS_SRCH_SBR in addition to the PER_KEY_SBR that brings in the EMPLID as a Search and List box field.

These are the delivered Use settings for this subrecord:

Other views will use the PERS_SRCH2_SBR that has must some Name fields.


You can affect a majority of the component search views by modifying one (or both) of these subrecords and choosing the fields you want to enable for search and/or list box access.

For example, if you wish to include PER_ORG as a search field you would open the PERS_SRCH_SBR in the Application Designer, right-click on PER_ORG and change its Record Field Properties to be an alternate search key and include in list

box. Save.

While this is a customization, it is a very low-risk one.

Product specific views There are times when a core security view does not meet the needs of a specific component. This may be because the product needs to join a product record in with the search, or it needs to add an additional Where clause to further limit the rows returned.

In most cases, a product specific view can be created using one of the core views as a basis. To make this easier to do, we provide a set of subrecords and sqlobjects that can be used.

Example:

CAR_PLAN_SRCH

This view needs to return only people that the user has access to how are also in the CAR_PLAN record.

There are times when a core security view

does not meet the needs of a specific component. This may be because the

product needs to join a product record in with the search, or it needs to add an

additional Where clause to further limit the rows returned.


This view doesn’t need to include any special fields in the view field list so the standard subrecords that EMPLMT_SRCH_GBL uses can be used here.

What will be different is the view text. What we need to do here is to join in the PS_CAR_PLAN record where the EMPLID is the same as the EMPLID in the security search view.

SELECT %Sql(SCRTY_SEL_PKEY,SEC,SEC) , %Sql(SCRTY_SEL_PERSBR,SEC,SEC) , %Sql(SCRTY_SEL_FLDSBR,SEC) FROM PS_PERS_SRCH_GBL SEC ,PS_CAR_PLAN H WHERE SEC.EMPLID = H.EMPLID

The core SQL objects SCRTY_SEL_PKEY, SCRTY_SEL_PERSBR, and SCRTY_SEL_FLDSBR are used to build the select list to match the core subrecords.

The core security view PERS_SRCH_GBL is put in the From clause along with the product specific CAR_PLAN and the Where clause is entered with the PERS_SRCH_GBL.EMPLID = CAR_PLAN.EMPLID

An example of a view that needs to add an additional filter would be PERS_SRCH_ST_PR that adds a filter to return just Employees or Stock - Non-

HR Employees.

SELECT %Sql(SCRTY_SEL_PKEY,SEC,SEC) , %Sql(SCRTY_SEL_PERSBR,SEC,SEC) , %Sql(SCRTY_SEL_FLDSBR,SEC) FROM PS_PERS_SRCH_GBL SEC WHERE ((SEC.PER_ORG = 'EMP')


OR (SEC.PER_ORG = 'POI' AND SEC.POI_TYPE = '00004'))

But many product specific views do a combination of both. For example: GP_PI_PAY_SRCH

SELECT SEC.OPRID , MNL.EMPLID , MNL.EMPL_RCD , MNL.GP_PAYGROUP , MNL.CAL_ID , SEC.NAME FROM PS_GP_PI_MNL_DATA MNL , PS_EMPLMT_SRCH_GBL SEC WHERE MNL.EMPLID=SEC.EMPLID AND MNL.EMPL_RCD=SEC.EMPL_RCD AND (EXISTS ( SELECT 1 FROM PS_GP_CALENDAR CAL , PS_GP_RUN_TYPE RT WHERE CAL.GP_PAYGROUP=MNL.GP_PAYGROUP AND CAL.CAL_ID=MNL.CAL_ID AND CAL.RUN_TYPE=RT.RUN_TYPE AND RT.CALC_TYPE='P') OR EXISTS ( SELECT 1 FROM PS_GP_PYE_CAL PC WHERE PC.EMPLID=MNL.EMPLID AND PC.EMPL_RCD=MNL.EMPL_RCD AND PC.GP_PAYGROUP=MNL.GP_PAYGROUP AND PC.CAL_ID=MNL.CAL_ID))

In this case the view needs to return only People with Jobs that the user has access to that have data in the GP_PI_MNL_DATA record.

In this case the view record fields are not using any of the core subrecords. This is okay – but is not recommended. The important field to include is the OPRID as a Key (but not as a Search or List) and to get the value for that field from one of the core views. However, not using the standard subrecords and SQL objects will make it difficult to apply changes to security in the future and also to making the search and list fields standard across the database.


Custom Views If a core view will provide the attributes and rules that you need, then use the core view. But you can create your own security search views by using the instructions for the product specific views. Again it is recommended that you use the standard subrecords and SQL objects wherever possible to avoid issues with your customizations in a later upgrade.

Refreshing the Operator Security Join Table This process refreshes the SJT_CLASS_ALL table from the SJT_CLASS and SCRTY_TBL_DEPT tables. You must run it initially to populate the table after you have set up your permission list security. It also must be run when you have made changes to a department security tree or to the data in the Security by Dept Tree component. Changes made to the Security by Role component are automatically updated to the SJT_CLASS_ALL table during SavePostChange.

Component: SCRTY_SJT_OPR

Navigation: Set Up PeopleSoft Enterprise HRMS, Security, Core Row Level Security, Refresh SJT_CLASS_ALL

You can choose to refresh all rows in the SJT_CLASS_ALL table or choose to refresh just a part of the table. Choose Permission List, Security Type, or Tree depending on what you have updated. For each of these choices, you can enter one or more values.

If a core view will provide the attributes and rules that you need, then use the core

view.


The ASOFDATE can be left blank if you want the tree data to come from the current versions of the trees.

The process that runs is the SCRTY_CLASS Application Engine Program. The run control Records are RUN_CNTL_SCRTY1 and RUN_CNTL_SCRTY2 (for the list of values to update).

Refreshing the Transaction Security Join Tables This process refreshes the SJT transaction tables. You must run it initially to populate the table after you have set up enabled your security types. If you enable of disable security types you must rerun the process as well. Changes made to the transaction tables will be reflected in the SJT tables at save time. But, if you have run a batch process that does not use a Component Interface you should rerun the process afterward.

You must run it initially to populate the

table after you have set up enabled your security types. If you enable of disable

security types you must rerun the process as well.


Component: SCRTY_SJT_RC

Navigation: Set Up PeopleSoft Enterprise HRMS, Security, Core Row Level Security, Refresh Trans SJT Tables

You can choose to update all Security Sets – or choose a single set to update.

Once you choose the Security Set, you can then choose to refresh all data for that set – or only part. The values that are displayed in the Rows to Update field are setup on the Security Set TableUpdateGroups page for each Set.


One you choose the type of rows to update, you can then enter one or more values.


The process that runs is the SCRTY_SJTUPD. Application Engine Program. The run control Records are RUN_CNTL_SCRTY3 and RUN_CNTL_SCRTY4 (for the list of values to update).

Nightly Updates for the Transaction Security Join Tables Some security join tables are based on transaction records that are effective dated. Because the rows that are loaded into the SJT are based on the current effective date (except for the future rows), when a new row in the transaction table becomes effective the SJT needs to be updated. Even future dated rows captured in the SJT need to be updated because they contain a flag that designates them as future-dated so that the views that do not want future dated rows can exclude them. You need to update them so that their status changes to current.

We have an Application Engine process that you should set up to run every night shortly after midnight for each security set you are using that has effective-dated transaction records. These sets are the People with Jobs, People without Jobs, USF People with Jobs, and Departments. You should create a separate Run Control ID for each security set.

Navigation: Set Up PeopleSoft Enterprise HRMS, Security, Core Row Level Security, Nightly SJT Refresh Process

You need to choose the SJT record that this process will update. Leave the AS Of Date field blank if you will be setting this Run Control on a recurring basis. The App Engine process will substitute the system date each time it runs. You want to schedule the job for shortly after midnight, which is when the rows with effective dates equal to the system date become current.

Select the Include yesterday’s changes? check box to capture not only the newly current data but also any transaction records that were updated at all during the previous day. This ensures that you capture updates that were made outside of the component or component interface.

We have an Application Engine process

that you should set up to run every night shortly after midnight for each security set

you are using that has effective-dated transaction records.


The process that runs is the SCRTY_SJTDLY Application Engine program. The run control record is RUN_CNTL_SCRTY3. The App Engine actually determines the key values of each transaction row that needs to be updated and loads them into the RUN_CNTL_SCRTY4 table. It then calls the SCRTY_SJTUPD App Engine Process to do the actual update.

Real-Time updates of the Transaction Security Join Tables One of the big enhancements for PeopleSoft Enterprise HRCS 8.9 is that the security join tables are updated in real-time instead just using an Application Engine process.

This is accomplished by using a special subpage that contains the working fields that are needed. This subpage (SCRTY_SJT_UPD) needs to be put on a page that is in the components where the transaction records are updated. For the transaction record JOB, the subpage has been attached to the JOB_DATA1_WRK page. This page is included in all of the components where the JOB record is updated (either directly or as a component interface).

Putting this subpage in the component is all that is needed to do to get the updates. SCRTY_SJT_UPD subpage contains these records:

SCRTY_SETTYP_VW

This view provides a working scroll of all enabled Security Types with the pertinent fields needed to do the updates.

One of the big enhancements for PeopleSoft Enterprise HRCS 8.9 is that the

security join tables are updated in real-time instead just using an Application

Engine process.


SELECT B.SCRTY_SET_CD ,A.SCRTY_TYPE_CD ,A.DESCR ,B.RECNAME_SJT ,A.RECNAME_S_TRANS ,A.KEY1_PROMPT_FLD ,A.KEY2_PROMPT_FLD ,A.KEY3_PROMPT_FLD ,A.ENABLED , A.FUTURE_FLG , A.HCR_HOME_HOST_TYPE , A.HCR_JPN_SEC_FLG , A.HCR_ASGN_TYPE FROM PS_SCRTY_TYPE_TBL A , PS_SCRTY_SET_TBL B WHERE A.SCRTY_SET_CD = B.SCRTY_SET_CD AND A.ENABLED = 'Y'

SCRTY_DERIVED

This is the work record that contains the peoplecode. The relevant fields are these:

Process

When a component is loaded the function INIT_SJT() is run to determine if this component has any Security Transaction Records.


When the component is opened, the RECNAME.SJT.RowInit PeopleCode fires. This program determines whether there are any records in the component buffer structure that are transaction records in an enabled security type. If it finds any, it loads component level arrays that will be used at save time to determine what needs to be updated.

This is done only once, when the component is entered. After that the InitSJT() is skipped because it has already been run.

SCRTY_DERIVED.RECNAME_SJT.RowInit

At SavePreChange, the SCRTY_DERIVED.RECNAME_SJT.SavePreChange code determines if there has been a change made to a security transaction record in the buffer.

Loop thru all the records in buffer (Level 0 thru Level 3

Until all records in the buffer have been checked - OR - until all of the Transaction SJTs have been triggered

Or - until all of the Transaction Records have been checked.

At SavePostChange the SCRTY_DERIVED.RECNAME_SJT.SavePostChange code loops thru each of the enabled security transaction records and runs the associated function if that record has triggered an update.

Note These functions do contain Security Set Specific Code – so this is an area that would need to be modified if a new Security Set is created.


SCRTY_DERIVED.RECNAME_SJT.SavePostChange Declare Function UpdateSJTPerson PeopleCode SCRTY_DERIVED.SCRTYPPL FieldFormula; Declare Function UpdateUSFPerson PeopleCode SCRTY_DERIVED.SCRTYUSF FieldFormula; Declare Function UpdateSJTRS PeopleCode SCRTY_DERIVED.SCRTY_RSOPN FieldFormula; Declare Function UpdateSJTDEPT PeopleCode SCRTY_DERIVED.SCRTY_DEPT FieldFormula; Component string &CompDoSecurity; Component array of array of string &TriggerSJT; Component array of array of string &SJT_SET; If &CompDoSecurity = "Y" Then /* Is this a component where there are SJT records to update*/ &L = 0; While &TriggerSJT.Next(&L); &SJT_REC = &TriggerSJT [&L][1]; &Trigger = &TriggerSJT [&L][2]; If &Trigger = "Y" Then &IND = &SJT_SET.Find(&SJT_REC); &Set = &SJT_SET [&IND][2]; Evaluate &Set When "PPLJOB" SCRTY_DERIVED.EMPLID = PER_ORG_ASGN.EMPLID; SCRTY_DERIVED.EMPL_RCD = PER_ORG_ASGN.EMPL_RCD; SCRTY_DERIVED.POI_TYPE = PER_ORG_ASGN.POI_TYPE; &OIN = PER_ORG_ASGN.ORG_INSTANCE_ERN; UpdateSJTPerson(&SJT_REC, &Set, SCRTY_DERIVED.EMPLID, SCRTY_DERIVED.EMPL_RCD, SCRTY_DERIVED.POI_TYPE, &OIN); Break; When "PPLPOI" SCRTY_DERIVED.EMPLID = PER_POI_TYPE.EMPLID; SCRTY_DERIVED.POI_TYPE = PER_POI_TYPE.POI_TYPE; UpdateSJTPerson(&SJT_REC, &Set, SCRTY_DERIVED.EMPLID, SCRTY_DERIVED.EMPL_RCD, SCRTY_DERIVED.POI_TYPE, &OIN); Break; When "PPLUSF" SCRTY_DERIVED.EMPLID = GVT_EE_KEY.EMPLID; SCRTY_DERIVED.EMPL_RCD = GVT_EE_KEY.EMPL_RCD; SCRTY_DERIVED.POI_TYPE = " "; UpdateUSFPerson(&SJT_REC, &Set, SCRTY_DERIVED.EMPLID, SCRTY_DERIVED.EMPL_RCD, SCRTY_DERIVED.POI_TYPE); Break; When "RSOPN" SCRTY_DERIVED.HRS_JOB_OPENING_ID = HRS_JOB_OPENING.HRS_JOB_OPENING_ID; UpdateSJTRS(&SJT_REC, &Set, SCRTY_DERIVED.HRS_JOB_OPENING_ID); Break; When "DEPT" UpdateSJTDEPT(&SJT_REC, &Set, DEPT_TBL.SETID, DEPT_TBL.DEPTID);


Break; End-Evaluate; End-If; End-While End-If;

CREATING NEW SECURITY TYPES The most commonly requested fields to base security on have been delivered pre-configured. To use them, you only have to enable them. But if you want to use a different field – whether your own or one already in the system, you will need to create a new Security Type.

Most of the time, this will be an easy thing to do. But you will need to understand SQL statements and the relationship of the records in the transactions. We recommend that a technical team member do the creation of Security Types.

First we’ll walk through the basic steps to add a new Security Type.

The simplest setup is when the field you want to use for security is:

1. Already part of the functional transaction (on the same transaction record as one of the other types for that set).

2. Has a prompt record that can be used to select the values when associated it with the Permission Lists.

An Example of this would be if we wanted to add a new Security Type to the Set People with Jobs that uses the PAYGROUP field.

First you should look at the other Security Types defined for this Set and see if any of them are similar (using the same transaction record for example). The Type 004 – Job by Company is similar to PAYGROUP. Both are on the JOB record, and both will need just one security field. The 002 type – Job Location – uses two keys because the LOCATION field needs the BUSINESS_UNIT as a parent key.

Let’s look at the Job Company Security Type.

We recommend that a technical team member do the creation of Security Types.


When we create the Job Paygroup Type, everything on this page will be the same except for the Security Key 1 (PAYGROUP) and the Prompt Record for Sec Key 1 (PAYGROUP_TBL).

The harder part comes in with the next page. The Security Type SQL:


These are the SQL objects that will be needed by the Application Engine process that refreshes the Transaction SJT Tables (SCRTY_SJTUPD). In most cases, you will actually be able to use the same SQLIDs as the Type you are copying except for the SQLID for the Key Contents (which is generated for you). If you look at this code you can see that for the new type by PAYGROUP, the only SQL that will need to be different is the Key one which would need to use PAYGROUP instead of COMPANY.

The Core SQLs have a standard naming to make it easier to identify which ones you can use.

The naming rule is: SEC_[security set]_[sqlusage]. For custom created SQL objects, the naming convention is SEC_[type code]_[sqlusage]. When you enter the page, the SQL names and objects will default based on the rules below.

SQLID SQL Usage Rule Comments

SQLID for the Value Field List FLDNM This is always the same for all

types in a Set. It is actually

defined in the Security Set

Component.

SQLID for the Key Contents [typecode]_SEL This is generated when you

enter the page based on the

Key fields entered on the first

page.

SQLID for the Field Contents FLDVAL This will default to being equal

to the Value Field List

SQLID for the From Contents FROM This will default to the

Transaction table from the first

page

SQLID for the Where WHERE This defaults to 1=1

SQLID for the Future dated where FUTWHERE This defaults to blank

You should not modify the SQLID or the SQL contents for the first two SQL Objects. These will always be correct as generated.

The remaining ones may need to be modified. Or you may be able to use the SQLIDs from the Type you were basing yours on. If this is the case, just type the name in the SQLID and tab out of the field. The SQL will be replaced with the SQL of that name. If you are using a Core SQL object, you will not be able to modify the SQL. If you are using the defaulted names, you will be able to modify the SQL directly on this page and it will save to the SQL table when you save. You need to make sure that you have entered correlation names for each record in the FROM SQL and that you use those consistently in the Field Contents and Wheres.

You should not modify the SQLID or the SQL contents for the first two SQL

Objects. These will always be correct as generated.


As these SQLs are run from within App Engine, you can use any valid meta-sql as well.

Here is an example of how these SQL Objects are used in the App Engine.

The App Engine loads into the AET record and then brings the SQL into Steps like the above.

SQLID Fieldname

SQLID for the Value Field List SEC_SQL_FLDNM

SQLID for the Key Contents SEC_SQL_KEYVAL

SQLID for the Field Contents SEC_SQL_FLDVAL

SQLID for the From Contents SEC_SQL_FROM

SQLID for the Where SEC_SQL_WHERE

SQLID for the Future dated where SEC_SQL_FUTWHERE

To return to our example: These are the steps we would take.

Choose ADD a New Value,

Choose a Security Set, the next available number for Security Type will default in – you can change this if you wish.

Click on Add.


The First page will be displayed with the Security Set and the Security Join Table brought in as related display.


We will enter the following data:

We then click on the Security Type SQL Tab – this data is defaulted in:


A

B

C

D

E


A & B No changes are needed.

C: SQLID for the Field List –we can change the

SQLID to the core SQL - -

SEC_PPLJOB_FLDNM

D: SQLID for the FROM contents – we can

change the SQLID to the core SQL -

SEC_PPLJOB_FROM

E: SQLID for the Where contents – we can

change the SQLID to the core SQL -

SEC_PPLJOB_WHERE

F: SQLID for the Future Where – we can enter

the SQLID for the core SQL -

SEC_PPLJOB_FUTWHERE

After we do this, the page looks like this:


Save.

That is all that is needed to create a Security Type for the JOB Paygroup.

The same would be true for any field that is already on a transaction record on one of the other Security Types for that Set (for example JOB.POSITION_NBR,

• If you have added a field to one of these records, you do not have to do anything different.

• If you have added a new record into the JOB component, then you would need to create the SQL for the FROM and WHERE SQLs to join in your record. You can enter this SQL directly into the page above – or create it via the Application Designer.

There are some cases that will cause you to have to do some minor customization.

There must be a prompt record available for the fields you enter as security keys. Using the PSXLATITEM table directly will not work. If the field you want to use uses Xlat values, then you will need to create a view that selects those values prior to creating the new Security Type. This is a current limitation of the design as the Security by Role component needs to have a Prompt record to use to allow the user to select valid values.

If the transaction record you are adding is not already in one of the components that contain the other transaction records for the set, then you will need to add the security secondary page into any component where that transaction record is maintained in order to get the real-time updates. The secondary page is what provides the real-time updating of the security data into the transaction SJT tables.

If the transaction record you are adding is not already in one of the components that

contain the other transaction records for the set, then you will need to add the

security secondary page into any component where that transaction record is maintained in order to get the real-time

updates.


SECURITY FOR PEOPLE WITHOUT JOBS In the case of People without Jobs, the transaction records that are part of the Person Object do not contain fields that would make sense to base security on. We added a record called PER_POI_SCRTY that is a child of PER_POI_TYPE to contain security data for these people without Jobs. But rather than try to think of what fields all you might want to use, we have implemented a much more flexible structure. You can define fields that you want to use for security in the Security Structure and these fields are then available to have data entered for them on the person side.

Entity Relationship Diagram for People

The PER_POI_SCRTY record uses the meta-data fields that are used in the Security Structure. The POI_TYPE takes the place of the SCRTY_KEY1.

You can define fields that you want to use

for security in the Security Structure and these fields are then available to have data

entered for them on the person side.


Example:

Creating new Security Types for People without Jobs is very simple.

The only field you would need to enter differently than the Type 006 – POIs without Jobs by Business Unit is the values of Key2 and Key 3

You would use the exact same SQLIDs as type 006 did.


SPECIAL JOB SECURITY VERSIONS (AKA ACCESS BY ASSOCIATION) There are three special types of security options available for People with Jobs. Two of these were available prior to PeopleSoft Enterprise HRCS 8.9, but using them required a lot of steps by the user.

With PeopleSoft Enterprise HRCS 8.9, we have made the usage of these easily enabled with just a configuration setting–and have also added in an additional level of special security for core Additional Assignments as well.

Navigation: Set Up PeopleSoft Enterprise HRMS: Security: Core Row Level Security: Security Install

Settings

What these versions allow is to have a User get access to a person’s assignment (EMPLID/EMPL_RCD) based on a relationship that that assignment has to one that the User has access to normally.

With PeopleSoft Enterprise HRCS 8.9, we

have made the usage of these easily enabled with just a configuration setting–and have also added in an additional level

of special security for core Additional Assignments as well.


For example, User A has access to an Employee’s Home Assignment (EMPL_RCD 1) through the normal security access rights. This Employee also has an active Host Assignment (EMPL_RCD 2). The attributes of the Host Assignment are such that User A would not normally have access to it (say based on the Host Department ID), but because there is a business relationship between a “Home” and a “Host” assignment, we actually want User A to get access to this Host EMPLID/EMPL_RCD as well as the Home assignment. But this would not mean that User A would get access to any other EMPLID/EMPL_RCD that was in that dept. And User A would only get access to the Host assignment as long as it is an Active HR Status.

Include Home/Host Access (aka International Security). Security access to employee data assumes greater importance when processing global assignments because human resources (HR) administrators at multiple locations need access to data on the same employee. With multiple current home or host data at various locations around the world, security access can be a logistical nightmare.

The PeopleSoft Enterprise Human Resources system eliminates this worry. Employees going on global assignments have at least one home record, which falls under the jurisdiction of the HR administrators at the home base, and at least one host record, which falls under the jurisdiction of the HR administrators at the host location.

What this special security access does is to allow a User who has access to one type of record – to also have access to another record based on the association between the first and second records. The options are:

• Users who have access to the Home record can also have access to the Current and Future Host Records.

• Users who have access to the Host Record can also have access to the Home Record.

• Or both access allowed.

The fields for Home/Host Access that contain the relationship between the Assignments are the EMPL_RCD, HOME_HOST_CLASS, and ORG_INSTANCE_ERN.

To create an International Assignment, the user accesses the ADD_HOST_ASSIGN Component for a Person

Employees going on global assignments have at least one home record, which falls

under the jurisdiction of the HR administrators at the home base, and at least one host record, which falls under

the jurisdiction of the HR administrators at the host location.


Navigation: Workforce Administration: Global Assignments: Add a Host Assignment

This page will show all of the Organizational Instances that the Person has and the Assignments attached to each. An International Assignment can be attached to any Organizational Instance. The User positions on the scroll row for the Instance they want to be the HOME and presses “Create Host Assignment”.

They are then presented with the Component HOME_HOST_CLASS that allows them to create this international assignment. Upon Save, they are returned to the Add Host Assignment page, where they press Refresh and can now see the Home and the Host assignments.

One Home – One Host

Often, employees have data pertaining to one home and one host: they have one permanent job and go on one assignment after another, sequentially. To show you how organizational security works, in this section we’ll look at a few examples of simple and complex global assignment situations involving Yves Chabot, an employee permanently based at KF1 company headquarters in France, in department 13000

Step 1: First Assignment

In 1989, Yves went on a four-year temporary assignment to the Edinburgh, Scotland office, department 21300. His home data (in France) uses employment record 0 and his host data (for Scotland) uses employment record 1. To administer human resource tasks for Yves, HR administrators in both France and Scotland need access to his data.

Often, employees have data pertaining to one home and one host: they have one

permanent job and go on one assignment after another, sequentially.


French administrators have the HCDPFRA Permission List, which allows them access to data for French departments. The administrators in Scotland belong to the HCDPGBR permission list class, which allows them access to data for all departments in the U.K. Note: we could be using the COMPANY field as the security access field instead of department to grant the normal security access and the examples would be the same. Nor is there any special meaning based on the value of the EMPL_RCD.

If no special Job Security is enabled then this is the allowed access for the two Permission Lists.

Employment Record

(Unique Identifier for

different assignments)

Assignment Type

(HOME_HOST_TYPE)

Security

Permission List

HCDPFRA

Security

Permission List

HCDPGBR

0 (FRA) Home Access No Access

1 (GBR) Host No Access Access

If Home can see Host is enabled then this is true:

Employment Record



Assignment Type

Security

Permission List

HCDPFRA

Security

Permission List

HCDPGBR

0 Home Access No Access

1 Host Access Access

If Host can see Home is enabled then this is true:

Employment Record



Assignment Type

Security

Permission List

HCDPFRA

Security

Permission List

HCDPGBR


1 Host No Access Access

If Both is enabled then this is true:

Employment Record



Assignment Type

Security

Permission List

HCDPFRA

Security

Permission List

HCDPGBR

0 Home Access Access

1 Host Access Access


Step 2: Second Assignment End

In 1994, Yves completes his assignment in Edinburgh. This JOB row is made inactive by entering a Termination type action in JOB history. The HR_STATUS is now ‘Inactive’ for EMPL_RCD 1.

No Association Security

Employment

Record

HOME_HOST_CLASS HCDPFRA HCDPGBR


1 (Inactive) Host No Access Access

With Home can see Host

Employment

Record



1 (Inactive) Host No Access (because

inactive)

Access

With Host can see Home

Employment

Record


0 Home Access No Access (because

inactive)


With Both

Employment

Record





Step 3a: New Second Assignment Start (reusing EMPL_RCD)

In 1995, Yves begins another temporary assignment in Sydney, Company KAB/Department 12000. HR administrators enter a new row in JOB History that will make the EMPL_RCD 1 Active again with the Sydney information. The HR administrators in Sydney belong to the permission list class HCDPAUS, which gives them access to data for all departments in Australia.

When Yves begins his new assignment in Sydney, the assignment data uses employment record 1, the same number that was used for his assignment in Edinburgh. Because the data row that contains information about Sydney is current, the system now permits users in the HCDPAUS primary permission list class to access Yves's employee data:


Employment

Record

HOME_HOST_CLASS HCDPFRA HCDPGBR HCDPAUS

0 Home Access No Access No Access

1 (Active in

AUS)

Host No Access No Access Access


Employment

Record



1 (Active in

AUS)

Host Access No Access Access


Employment

Record


0 Home Access No Access Access

1 (Active in

AUS)




Employment

Record



1 (Active in

AUS)


With Both

Employment

Record



1 (Active in

AUS)


Step 3b: New Assignment Start (using new EMPL_RCD)

In 1995, Yves begins another temporary assignment in Sydney, Company KAB/Department 12000. HR administrators create a new Assignment Row with EMPL_RCD 2 that will make the EMPL_RCD 2 Active with the Sydney information. The HR administrators in Sydney belong to the permission list class HCDPAUS, which gives them access to data for all departments in Australia.

When Yves begins his new assignment in Sydney, the assignment data uses a new employment record 2. This setup allows the HR Administrators in Edinburgh to still have access to the EMPL_RCD 1 data.


Employment

Record



1 (Inactive in

GBR)

Host No Access Access No Access

2 (Active in

AUS)




Employment

Record



1 (Inactive in

GBR)


2 (Active in

AUS)



Employment

Record



1 (Inactive in

GBR)


2 (Active in

AUS)


With Both

Employment

Record



1 (Inactive in

GBR)


2 (Active in

AUS)


There is actually one more level of complexity on this scenario. It is possible for a person to have more than one HOME record with different HOST records associated with each HOME. A single HOST record can only be associated with one HOME record, but a single HOME record can control more than one HOST record. The ORG_INSTANCE_ERN field is used to identify what the HOME record is for a HOST record.


With no Associative Security

Employmen

t Record

HOME_HOST_CLASS ORG

Instanc

e ERN

HCDPFRA HCDPGB

R

HCDPAUS

0 (FRA) Home 0 Access No Access No Access

1 (Inactive in

GBR)

Host 0 No Access Access No Access

3 (Active in

AUS)

Host 0 No Access No Access Access

2 (AUS) Home 2 No Access No Access Access

4 (Active in

FRA)

Host 2 Access No Access No Access

5 (Active in

GBR)



Employmen

t Record

HOME_HOST_CLASS ORG

Instanc

e ERN

HCDPFRA HCDPGB

R

HCDPAUS

0 (FRA) Home 0 Access No Access No Access

1 (Inactive in

GBR)


3 (Active in

AUS)

Host 0 Access No Access Access

2 (AUS) Home 2 No Access No Access Access

4 (Active in

FRA)


5 (Active in

GBR)

Host 2 No Access Access Access



Employmen

t Record

HOME_HOST_CLASS ORG

Instanc

e ERN

HCDPFRA HCDPGB

R

HCDPAUS

0 (FRA) Home 0 Access No Access Access

1 (Inactive in

GBR)


3 (Active in

AUS)

Host 0 No Access No Access Access

2 (AUS) Home 2 Access Access Access

4 (Active in

FRA)

Host 2 Access No Access No Access

5 (Active in

GBR)


With Both

Employmen

t Record

HOME_HOST_CLASS ORG

Instanc

e ERN

HCDPFRA HCDPGB

R

HCDPAUS

0 (FRA) Home 0 Access No Access Access

1 (Inactive in

GBR)


3 (Active in

AUS)


2 (AUS) Home 2 Access Access Access

4 (Active in

FRA)


5 (Active in

GBR)

Host 2 No Access Access Access

Include Additional Assignment Security Additional Assignment Security is new in PeopleSoft Enterprise HRCS 8.9. It was added because the structure that supports the International Assignment and Japan Assignment Security can be used for “normal” Additional Assignments (aka Concurrent Jobs) as well.


Each Additional Assignment for a Person is connected with a Controlling Organizational Instance record. An Additional Assignment can only be connected with on Controlling Organizational Instance, but that Controlling Organizational Instance can be connected to multiple Additional Assignments. If you are familiar with the Global Assignments, then think of the Additional Assignments as Host jobs and the Controlling Organizational Instance as the HOME job.

What this special security access does is to allow a User who has access to one record to also have access to another record based on the association between the first and second records. The options are:

• Users who have access to the Controlling Instance record can also have access to the Current and Future Additional Assignments Records.

• Users who have access to the Additional Assignment Record can also have access to the Controlling Instance Record.

• Or both access allowed.

The fields for Additional Assignment Access that contain the relationship between the Assignments are the EMPL_RCD and the ORG_INSTANCE_ERN.

To create an Additional Assignment, the user accesses the ADD_PER_ORG_ASGN Component for a Person

Navigation: Workforce Administration: Job Information: Add a Additional Assignment

If you are familiar with the Global

Assignments, then think of the Additional Assignments as Host jobs and the

Controlling Organizational Instance as the HOME job.


In this case, we entered the component for EMPLID KU0020. There are two Organizational Instances for this person (see the circled scroll header). We need to determine if this Additional Assignment is related to the Organizational Instance 0 or the Organizational Instance 1.

In this case, it is related to the Organizational Instance 0. The User positions on this scroll, and presses the “Create Assignment” button. This takes them to the JOB_DATA_CONCUR component where the Additional Assignment data is created.

Once that assignment is created, the user is returned to the Add New Assignment component and can refresh the page to see the Assignment data.

JOB Data

EMPLID EMPL_RCD ORG_INSTANCE_ERN Business

Unit

Location

Code Location

KU0020 0 0 GBIBU KUDE00 Delaware

Operations

KU0020 1 1 CAN01 KCBC00 Vancouver

Branch

KU0020 2 0 GBIBU KUNY00 Corporation

Headquarters


We have 2 Permission Lists – HCDPA, HCDPB. Each Permission List has access to one Location. We are using the JOB Location Security in this case.

HCDPA Location KUDE00

HCDPB Location KUNY00

No Additional Appt Security

EMPLID Employment

Record

ORG_INSTANCE_ERN HCDPA HCDPB

KU0020 0 0 Access No Access

KU0020 2 (active) 0 No Access Access

KU0020 1 1 No Access No Access

With Additional Appt Security – Assignment can see Instance

EMPLID Employment

Record


KU0020 0 0 Access Access



With Additional Appt Security – Instance can See Assignment

EMPLID Employment

Record



KU0020 2 (active) 0 Access Access



With Additional Appt Security – Both

EMPLID Employment

Record


KU0020 0 0 Access Access

KU0020 2 (active) 0 Access Access


The access to the Related Row is only for as long as that row is Active.

With Additional Appt Security – Both - with the Assignment row now inactive.

EMPLID Employment

Record





Include Japan Assignment Security Additional Appointments are tracked as additional jobs (employment record numbers) in the Job record. The Additional Appointment Information page enables tracking of multiple additional appointment rows for each main appointment row of the Job record. A separate Enter Cost Rate Information page enables the tracking of cost rate distribution among a main appointment and its additional appointments

The Japan Appointment security allows the User who has access to the Additional Appointment to also have access to that person’s Main Appointment. The reverse situation is not needed (where the Main is granted access to the Additional Appointment because users can only access the Additional Appointment information by choosing the Main Appointment in a search page.

The Japan Appointment security allows

the User who has access to the Additional Appointment to also have access to that

person’s Main Appointment.


Example of Security Access

This illustration of security access is based on the following department security tree:

Sample Department Security Tree

Here is how the security would work

If you do not select Japan Assignment Security:

• If the user has access to department 200, then the user has access to employee 1000’s data.

• Even if the user has access to department 300, the user does not have any access to employee 1000’s data.

If you select Japan Assignment Security:

• If the user has access to department 200, then the user has access to employee 1000’s data.

• If the user has access to department 300 only, then the user can access employee 1000's data because the employee has an additional appointment in department 300.

Note. Security access is dependent upon the system date being earlier than the effective date of the release of the additional appointment. Security access to the data row ceases with the effective date of the additional appointment release.

Please refer to the PeopleSoft Enterprise HRMS 8.9: Administer Workforce PeopleBook for more information on the functionality of Japan Additional Appointments.

Note: The Japan Assignment Security can be configured on any of the People with Jobs Security Types – not just the Type by Security Dept Tree.

The fields for Japan Assignment Security that contain the relationship between the Assignments are the EMPL_RCD, MAIN_APPT_NUM_JPN, and APPT_TYPE.

Security access is dependent upon the

system date being earlier than the effective date of the release of the additional

appointment. Security access to the data row ceases with the effective date of the

additional appointment release.


To create a Japan Additional Appointment, the user accesses the AA_MGMT_JPN Component for the Person’s Main Appointment.

Navigation: Workforce Administration: Job Information: Additional Appointment JPN

To add a new Additional Appointment, the ADD button is pressed.

The User then enters the information for the Additional Appointment as either an Internal Company Transfer or an External Company Transfer.

The main page will show all Additional Appointments for this Main Appt. Here Maita Honzo has two Additional Appointments under EMPL_RCDs 1 and EMPL_RCD 2 – both belong to the Main Appt under EMPL_RCD 0.


JOB Data

EMPLID EMPL_RCD APPT_TYPE MAIN_APPT_

NUM_JPN

Business

Unit

Location

Code

Location

KJL401 0 0 0 JPN01 KJ01 Tokyo

KJL401 1 1 0 JCS01 J003 Fukuoka

KJL401 2 1 0 JPN01 KJ02 Osaka

We have 3 Permission Lists – HCDPJPN, HCDPJPNB, and HCDPJPNC. Each Permission List has access to one Location. We are using the JOB Location Security in this case.

HCDPJPN Location KJ01

HCDPJPNB Location J003

HCDPJPNC Location KJ02


Employment

Record

APPT_TYPE MAIN_APPT_

NUM_JPN

HCDPJPN HCDPJPNB HCDPJPNB

0 0 (MAIN) 0 Access No Access No Access

1 (active) 1 (Addl Appt) 0 No Access Access No Access

2 (active) 1 (Addl Appt) 0 No Access No Access Access


With Japan Additional Assignment Enabled

Employment

Record


NUM_JPN


0 0 (MAIN) 0 Access Access No Access



When the Additional Appointments are no longer active, then the User with access to the Additional Appointment can no longer see the Main Appointment regardless of whether the Japan Additional Assignment security is enabled or not.


Employment

Record


NUM_JPN





With Japan Additional Assignment Enabled

Employment

Record


NUM_JPN






IMPLEMENTATION PROCESS

Steps 1. Decide which Security Sets you will need

2. Decide if you will want to use Global Security, Japan Additional Appointment, or the Additional Assignment Security versions.

3. Decide what Job Actions you want to include in future dated security rows.

4. Determine which Security Types you will enable.

5. Refresh the Transactional Security Join Tables (This can actually be done at any time after step 4, but seeing the data in the table may help you make decisions in the following steps)

6. Decide how many Permission Lists you need to create in order to enter your security values at the most granular level.

7. Decide how many Roles you need to be able to group your Permission Lists by business functions. (Not needed if you are doing Security Access Types that only use the Dept Security Tree).

8. Create the Permission Lists

9. Enter the security data in each Permission List.

10. Refresh the Operator Security Join Table (SJT_CLASS_ALL)

What Security Types to enable. The system is delivered with the following Security Types enabled.

People with Jobs 001 – by Dept Security Tree

People without Jobs 009 by POI Type

Departments 021 by Dept Security Tree

First decide what Sets you will use. (These do not need to be enabled or disabled).

Decide if you will be implanting Global or Additional Assignment Security or would like to be able to use the new Controlling Instance Security.

What to consider Think about how your workforce is organized and how you functionally administer it. Do you have different payroll clerks processing payroll for different Business Units, Locations, or Companies. Does a Regional separation make sense?

Think about how your workforce is

organized and how you functionally administer it. Do you have different payroll

clerks processing payroll for different Business Units, Locations, or Companies. Does a Regional separation make sense?


Enabling Multiple Types in a Set The tradeoff here is flexibility vs. performance. The more Types you enable, the more data has to be stored in the Security Join Tables. For example, for People with Jobs, each enabled Security type requires at least one row of data in the SJT_PERSON table for each EMPLID/EMPL_RCD/ current Job for each Type. If you have 100,000 people in your workforce, you will have a minimum of 100,000 rows in the SJT_PERSON table. If you have two Security Types for People with Jobs enabled, then that is a minimum of 200,000 rows. If future dated transactions are turned on for one or both of the types, then that adds another row for each future row. While the number of rows is still much less than would be in your PS_JOB table, and we are joining directly on the keys, it is still something to consider.

SECURITY IN PRODUCTION There are some activities that the System Administrator will do once you are in production. Some of these activities will require the security join tables to be refreshed.

User Maintenance Any change made to a user profile will not cause any of the security join tables to be refreshed. This maintenance is done using Oracle’s PeopleSoft Enterprise PeopleTools User Profile component.

• New Users are created and are assigned a row security class and Roles.

• Current Users are given a different row security class and/or security Roles.

• Current Users are inactivated.

Permission List Maintenance Modifying permission lists used for security will cause the SJT_CLASS_ALL table to change. Some of these changes are done by the system while others need the System Administrator to run the refresh process.

Maintenance in the Security by Permission List component will cause the SJT_CLAS_ALL table to be updated upon save.

• Adding a new permission list in the Security by Permission List component

• Changing any attribute of a permission list in the Security by Permission List component

The tradeoff here is flexibility vs. performance. The more Types you enable,

the more data has to be stored in the Security Join Tables.


Maintenance in the Security by Department Tree component will require the Security Administrator to initiate the refresh process themselves. The reason for this is that the refresh of data that relates to the trees requires an Application Engine process to be run.

• Adding a new permission list in the Security by Department Tree component

• Changing any attribute of a permission list in the Security by Permission List component – including adding a new Department Security Tree node or changing the access type of a current node

Maintenance to the permission list done in the PeopleTools Permission List component does not require any refreshing of security data.

Role Maintenance Maintenance done in the PeopleSoft Enterprise PeopleTools Roles component does not require any refreshing of security data. This includes the creation and deletion of Roles. Security data is stored using the permission list not the role so there is no flattened role data.

Department Tree Maintenance Some changes that you make to departments may require the SJT_CLASS_ALL security join table be refreshed. The Security Administrator must initiate this refresh process. The main reason for this is that the refresh requires an Application Engine process to be run. Also, many times changes to a Department Security Tree will also require changes to be made to the permission lists as well. So it is best to wait until all related changes are done and then run the SJT_CLASS_ALL refresh process.

• Adding a new department to a Department Security Tree

• Deleting a department from a Department Security Tree

• Moving a department to another parent node in a Department Security Tree

• Modifying a Department Security Tree

Security Type Maintenance Making changes to security types will require that all affected security join tables be refreshed. The SJT_CLASS_ALL table must refreshed as well as the transactional security join table for the modified security type.

• Enabling or disabling an access type

• Changing one of the other attributes on an access type such as the future date flag or the special Job security versions

Maintenance in the Security by Department

Tree component will require the Security Administrator to initiate the refresh

process themselves. The reason for this is that the refresh of data that relates to the

trees requires an Application Engine process to be run.


Future dated entries in the Transactional Tables Security is generally based on the current data from the transactional tables that has been copied to the transactional security join table. When the transactional table has the ability to save future dated entries, then these entries need to be reflected in the security join table when they become effective. This is why you should schedule the Nightly Refresh of the Transactional security join tables process to run every night shortly after midnight. You’ll need to set up a separate run control entry for each transactional join table that has EFFDT that you are using. Please refer to Navigation: Set Up PeopleSoft Enterprise HRMS, Security, Core Row Level Security, Nightly SJT Refresh Process.

Changes to the Transactional Tables via Batch The security data in the transactional security join tables is kept up to date in real-time by using Component Save Post Change PeopleCode. Any updates done to the transactional data via the component or its component interface will cause this data to be updated. But if you use a SQL statement directly against the transactional table either using a database access tool or batch process, then the security data will not get updated.

When you do this, you can use the Refresh Transactional Join table process to bring that data up to date. Use the groupings feature available in that component to limit the rows that you have to update to match what you did in your batch job or refresh the whole table. One easy method you can do is to create a file of the EMPLIDs and EMPL_RCDs of the people you modified during the batch process and then use that file to load the RUN_CNTRL_SCRTY4 table with that list and schedule the process as part of your overall batch job. Please refer to Navigation: Set Up PeopleSoft Enterprise HRMS, Security, Core Row Level Security, Refresh Trans SJT Tables.

UPGRADE PROCESS If you are using the delivered Dept Security Tree security or the Global or Japan Additional Assignment Security you will have very little or no upgrade impact. If you have customized the Row Level Security, then the upgrade impact will depend on what you have done.

Customers Using the Delivered Dept Security Tree If you are currently using the delivered row level security of the Department Security Tree your Security setup will not be affected during upgrade. Your currently defined Row Security Classes and Users and SCRTY_TBL_DEPT will remain the same.

You will need to run the new Refresh Security Join Tables processes that are in the Post-conversion steps. This will load their data into the SJT_CLASS_ALL and SJT_PERSON tables.

You’ll need to set up a separate run control entry for each transactional join table that

has EFFDT that you are using.

If you are using the delivered Dept Security Tree security or the Global or Japan

Additional Assignment Security you will have very little or no upgrade impact. If

you have customized the Row Level Security, then the upgrade impact will

depend on what you have done.


If you want to take advantage of any of the new flexibility offered by the new structure, see the Implementation Process section.

Customers Using the Delivered Dept Security Tree with Global or Japan Additional Assignments Versions If you are using the delivered department security tree with global or Japan additional assignments, you will need to update the Security Install Setup to indicate that you wish to use Global Assignments or Japan Additional Assignments at the installation level.

You will then need to update the Security Type 001 (People with Jobs using the Dept Security Tree) to turn on the version(s) you want to use.

The rest of their data and setup will work with the new structure with no changes.



Customers Who Have Customizations to use the Business Unit, Location, Regulatory Region, Company, or Salary Grade Fields instead of DEPTID These data fields are all now provided as pre-configured Security Types for People with Jobs (and the US Federal Employees). If you fall into this category, you will be able to drop all of your customizations when you setup the new structure. You would want to disable the Security Type 001 – People with Jobs by Department Security – and enable whichever Security Type you wish to use. You will want to use the security views that are delivered with PeopleSoft Enterprise HRCS 8.9 only.

You will need to populate the SJT_CLASS table with the Permission Lists and data you created for your customizations. This is an upgrade script that you will need to write yourself since it would have been a customized table.

You do not have to create Roles to associate the Permission Lists to and then assign those Roles to the Users. The structure will actually allow you to leave the Permission lists assigned to the Users using the Row Security Permission List on the User Profile’s first page. Leaving them in the PSOPRDEFN.ROWSECCLASS field will work fine.



These data fields are all now provided as pre-configured Security Types for People

with Jobs (and the US Federal Employees). If you fall into this category, you will be able to drop all of your customizations

when you setup the new structure.


Customers Who Have Customizations to use the DEPTID but not via the Tree This is a supported Security Type that is provided for People with Jobs (and the US Federal Employees). If you fall into this category, you will be able to drop all of your customizations when you setup the new structure. You would want to disable the Security Type 001 – People with Jobs by Department Security – and enable the Security Type 025 (or 019 for US Federal). You will want to use the security views that are delivered with Oracle’s PeopleSoft Enterprise HRCS 8.9 only.





Customers who have customizations to use a different field on JOB or in the JOB_DATA components

You may be able to re-implement this customization as a new Security Type. How easy this is will depend on what the field is. Please refer to the Section in this document on creating a new Security Type. In most cases, any field that is accessible in the JOB_DATA components will be easy to set up as a Security Type with no customization.

If a new Security Type will work for you, then create that type; disable Security Type 001 (by Dept tree).



If you want to take advantage of any of the

new flexibility offered by the new structure, see the Implementation Process section.



Customers Who Are in One of the Above Categories but Have Also Created Their Own Security Views You should be able to modify your views to join to one of the core security views or to use the new SQL objects as is described in the Product Specific Security Views section.

Customers Who Have Customizations That Do Not Use a Field in the JOB_DATA Components If this is your situation, you may need to redo your customizations again after you have applied the upgrade. Since most of the tables used in the new security process are new (only the SCRTY_TBL_DEPT table is reused), you may be able to keep your customizations in place and just need to change the security views. You should read the section on the core views and how those are built. Most of the product specific views now join to one of the core views instead of doing their own joining to the security tables. This means that the number of views you need to customize may be smaller than before

If you have customized the FAST_SCRTY tables you can keep those tables in place. These tables have been deleted as part of the 8.9 upgrade – so you can choose to keep them. If you have customized any of the HRSECVIEW SQL objects, you can keep them as well. All of them will be deleted as part of the 8.9 upgrade.

Customers Who Have Turned off Row Level Security It is not possible to actually run the system with no Row Level Security. However, you only have to enter a small amount of setup data once in one Permission List and Role to set up the bare minimum needed. After that you do not have to worry about it again. Nor do you need to maintain a Department Security Tree. Also, since the updates to the SJTs take place in real-time when you save the Components, you never have to refresh them after initially setting them up – unless you run customized batch updates.

1. Choose a Security Type for the People with Jobs that would require the smallest number of entries. For example, if you have just one Company, choose Security by Job Company. The most number of entries required would be using Security Type 015 (by Person Organization). This requires just 3 entries in the Permission List – (Employee, Contingent Worker, and Person of Interest).

2. Choose the Security Type for the People without Jobs by POI_TYPE – 009. Enter one row for each enabled POI_TYPE into the Permission List you

It is not possible to actually run the system with no Row Level Security.


created above. This may require a maximum of 5 if you enabled all the POI Types without Jobs. This step is optional if you are not going to store people without Jobs.

3. Choose the Security Access Type 023 – Departments by Setid (this is for access to Departments). Enter one row of data for each SETID you are using in the DEPT_TBL in the Permission List you created in Step 1.

4. Add this Permission List to a Role that all of your Users get. For example Standard Non-Page Permissions.

5. Refresh the Security Join Tables once.

You probably would not want to give this Permission List to your Self-Service users though. Enabling this one Security Type does allow you to provide a level of security that at least prevents a Self-Service User from being able to access other people even if they were given access to a component by mistake. Or from being able to run a query on other people if the query access tree wasn’t set up right.

The amount of data in the Security Join Tables will be quite small. In the SJT_CLASS_ALL table there would be only a maximum of 8 plus one for each Department SETID you have. In the SJT_PERSON_ALL record, there would be one row for each EMPLID/EMPL_RCD current row in JOB, one for any Future Hires, and one for each EMPLID/POI_TYPE in PER_POI_TYPE. This is still a smaller number of rows to join than you would have joining to the PS_JOB table directly.

If you truly do not want to have any row level security, this will require some customization and you will not be able to access the People without Jobs in all places. For this reason, we do not recommend it and is why it is not supported anymore. You also will not be able to access People without Jobs in the same queries and batch processes as People with Jobs. This is because to combine the JOB data with the Non-Job table (PER_POI_TYPE) is only possible with a Union, which is not allowed in all platforms in a view. You could use a Union in a Component Search view to join the two tables together, but it would only be usable in that component.

FAQ

Can I set up Read-only access? No. This Security Structure has not added the ability to specify Read-only access. This can be done using the Component Access Security in Tools.

Does the new security Structure support Field Level security? No. Some Field Level access can be controlled using the Global Security where you identify for each Primary Permission List which country specific data are accessible for it.

If you truly do not want to have any row level security, this will require some

customization and you will not be able to access the People without Jobs in all

places. For this reason, we do not recommend it and is why it is not

supported anymore.


How does this affect Manager eApps and Direct Reports? The Manager Security is not affected by these changes

Can I update the SJT tables after a batch update? Yes. You can have your batch process start the appropriate Application Engine (SCRTY_CLASS or SCRTY_SJTUPD).

Can I use other Trees other than the Department Security Tree? Not at this time. But this is an enhancement we are considering.

CUSTOMIZATION

Adding a new Security Set This entails a larger customization and is not recommended at this time. The steps will be covered in a later White Paper.

PeopleSoft Enterprise Human Capital Management & Campus Solutions: Row Level Security in 8.9 (Version 1.0) March 2005 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 © 2005, Oracle. 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 merchantability 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, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

peoplesoft enterprise human capital management & campus ... › us › media › ebook ›...

Documents