Row Security persmission list is used to filter transaction data

Let take an example. You want that HR assistance only view admin, IT,
maitainaince employees. HR manager can see all employees but cannt see
directors. HR Directors can see all employees.

Main Menu > Set Up HRMS > Security > Setup Security Access
In HRMS you select row security permission list and assign dept which
are accessible. And assign that row security permission to user.

Lets another example, in HRMS time and Labour you want time
Administrator to see only those employee who reports him.

In Time and Labour, you create groups of employee and assign that group
to Row security permission list and that permission list assign to Time
administrator
Main Menu > Set Up HRMS > Security > Group Creation Security

For all these row filteration you use row security permission list.

Are Row Security Permission Lists only used with HRMS ?

Is it the same security as Query Security Records? Indeed, I read it is

used for the same purpose: row-level security.
For instance, if you want someone to have access to only its department's
data, you can give him access to the corresponding table (PERSONAL_DATA) but
restrict rows (thanks to a Query Security Record) for him to see only those
matching his own department.
What is also the difference when you set up Row Security Permission Lists?

It uses in FSCM also

Yup, Just open any Query Security Record in app designer and see it
SQL. Its actually implelentation of ROW Security Permission list :-)

"It uses in FSCM also"

This is incorrect. The Row Security Permission List on the user profile is ONLY used in the HRMS
system. Financials also uses a type of row security, but it is set up quite differently.

PS_SCRTY_ACC_GRP and PS_SCRTY_QUERY

PS_SCRTY_ACC_GRP and PS_SCRTY_QUERY tables – are 2 important tables for the
Query security at PeopleSoft level which get populated thorugh the query security panels.
While PS_SCRTY_ACC_GRP stores the query trees and their access groups thorugh
which the permission list can access the Peoplesoft records, the PS_SCRTY_QUERY
table contains information related to the level of access (number of joins a query can
have -QRY_MAX_JOINS,wheter or not the query can contain UNION clauses –
QRY_ADV_UNION ) and the functionality within the query managemnt tool each
permission list has.
The PS_SCRTY_ACC_GRP record storesfor each permission list (CLASSID) the name
of the tree (TREE_NAME) and the access group (ACCESS_GROUP) through which the
permission list is entitled to have rights on the specific tree.Please find, also, a script on
how determine the access groups and tree names on which a user has access to in the
“PeopleSoft Useful Scripts” category folder.

Understanding Row Level Security

One of the things that is often misunderstood about PeopleSoft applications is how row
level security works.

Part of the reason for this is that a lot of the application groups within PeopleSoft
provided their own row level security setup - HR with the security based on the
department tree being a great example. The Financials group went beyond just one type
of row level security "out of the box" - I forget how many choices they offered - there
were several different common chart of account fields (business unit, department,
account, etc.). With the application teams providing row level security in the vanilla
install, many customers didn't realize that it is possible to handle row level security
differently.

One thing that I always found helpful in customer meetings when this topic came up was
to go through exactly how the PeopleTools component processor used search records to
handle security. Once you understand that, then you can best decide if changing the row
level security that the application groups provide makes sense from a cost/benefit
perspective. And there definitely is a cost in the current PeopleTools - fixing row level
security so that it was brain dead simple for customers to pick and choose how they
wanted to implement it was one of the big ticket items planned for PeopleTools 9.

First, a quick side journey into the component processor (catch me at a conference or user
group meeting sometime and I'll tell you the inside story on where the "component" name
came from - it'll make you laugh). The component processor is truly the guts of
PeopleTools - it is what handles the business logic, database commits, etc. for just about
every page that you see in a PeopleSoft application. PeopleSoft components are
parent/child hierarchies of database records that automatically get pulled together as one
unit of work from the application developer's perspective.

There is one row of data at what is called Level 0. There can be up to 3 levels beyond
that. Each level is required to have the same unique keys as the level above it, plus at
least one additional unique key field to identify what makes the rows in that level unique.

For example, if a customer master record is at level 0 and has CUSTOMER_ID as it's
unique key, you might have customer contacts at level 1 keyed by CUSTOMER_ID and
CONTACT_ID. Customer contact phone numbers might be at level 2, keyed by
CUSTOMER_ID, CONTACT_ID and PHONE_ID.

The data at each level comes from the key values above it. If the CUSTOMER_ID at
level 0 is 1234, then the component processor would automatically use 1234 for
CUSTOMER_ID for selecting data into level 1, and so on, down to level 3 (there are
ways to override this, but that's how the default behaviour works).

The important thing to keep in mind here from the perspective of row level security is
that populating the key fields in the level 0 record drives everything else. This is what the
seach dialogs are responsible for.

When you first enter a component via the browser you get a page asking you for
whatever the key fields are. In this case it would just be CUSTOMER_ID, but if the level
0 record has multiple key fields, then you'd get prompted for those as well. If you don't
know the values, you click Search and get presented with a list of valid values.

But where does that list come from? Each component has what is known as a search
record. The component processor uses the search record to supply the values for the key
fields of the level 0 record, which then flow down to the child levels.

Any rows of data that the search record returns to the user gives the user access to that
data.

So if you wanted to limit someone to only look at active customers, then you could create
a view that had the same key fields as the customer master record, but had a WHERE
clause like " WHERE CUSTOMER_STATUS='A' ". The view would only return active
customers, which means that no one could get into that component to look at an inactive
customer.

The component processor recognizes a couple of "special" fields on search records -

OPRID and OPRCLASS. If the field OPRID exists on the search record, it automatically
gets filled in with the current logged in user's ID. If the field OPRCLASS exists on the
search record, it gets filled in with the Row Level Security Class (Permission List) that is
specified on the user's security profile.

And that's essentially it for how the component processor handles things for row level
security. There are a couple of PeopleCode events that fire when a search dialog is
initialized (SearchInit) and when the user clicks "Search" (SearchSave), but those are not
really intended for row level security. I'll write more about that in the future.

So how does the department tree security in HR work then? The HR group created a
setup page that lets you pick a security class (permission list) and a tree node from the
department security tree. For each one of these combos that you select, you decide
whether access is granted or denied. All of this data is stored in a table. The HR team
then created a view that links this table, the tree manager tables, and the employee
department data together. The component processor automatically plugs in the row level
security class for the user when selecting from the view, which limits what the user can
see.
Financials works in a similar fashion, although the performance of the trees in the view
didn't work well enough for them so they ended up with flatter security structures. The
HR team actually delivered a couple of de-normalizing utilities for larger customers to
deal with this issue as well.

So, how do you change that delivered security?

You could clone the delivered security views (and the tables/pages that they use to
maintain the data). I helped a customer once do this where they wanted to use the
position tree instead of the department tree.

You can also create your own security structures that do not mimic the delivered ones.
All that matters is that you have a table or view that will return the key values that a user
has access to. All that matters is that the search record has the same key fields as the level
0 record in the component that you're securing and that you either have the OPRID or
OPRCLASS there to provide security.

There are no restrictions about what data the search record looks at or how that data gets
maintained. For example, you might have some batch job that updates the table based on
security defined in some totally different system. Or maybe someone has to request
access to look at some data and security administrator will update the table that the search
record looks at. I know of one customer that wanted to have their call center employees
only be able to look at customer data when a call came in. So right before the server
would send the screen pop for the customer data down to the agent's desktop, the security
tables would be updated for that user to have access. As soon as the call was over, then
access was taken away.

So the development of a new search record/view is one cost. This includes not just the
technical development, but the auditing to make sure that it works properly as well.

Another cost is that the search record is attached to the component definition. So if you
update a whole bunch of components to point to different search records, then you have
to keep track of that at upgrade time. This is less costly than doing things like changing
delivered code since you just need to add one extra step in your upgrade - update any
changed components again. Not really a lot of thinking/analysis involved. But, a lot of
customers like to run as close to vanilla as they can, so it is worth keeping in mind.

Of course, you don't want to be so afraid of a small cost at upgrade time if your business
requirements need different data level security. I talked with a customer once that had
turned off row level security in their Purchasing implementation because the delivered
methods didn't work for them. Their auditors were complaining (and this was even before
all of the current SarbOx push) and they wanted to know when Purchasing would support
what they wanted. Changing the row level security is not so hard/costly that you'd want
to run without security.
Also, it's worth mentioning that there is a way to override the delivered row level security
without touching the delivered components.

Example for Rowlevel Security

Take JOB Table. For this table Qrysectable is : PS_H_EMPMTSRCH_QRY

For PS_H_EMPMTSRCH_QRY Description as follows:

For PS_H_EMPMTSRCH_QRY Description as follows:

CREATE OR REPLACE FORCE VIEW SYSADM.PS_EMPLMT_SRCH_GBL

(EMPLID, EMPL_RCD, ROWSECCLASS, ACCESS_CD, NAME,
LAST_NAME_SRCH, ALTER_EMPLID, EMPL_STATUS, NAME_AC, PER_STATUS)
AS
SELECT /*+ INDEX(JOB) USE_HASH(JOB) */A.EMPLID
,JOB.EMPL_RCD ,SEC.ROWSECCLASS ,SEC.ACCESS_CD ,A.NAME
,A.LAST_NAME_SRCH ,A.ALTER_EMPLID , JOB.EMPL_STATUS ,A.NAME_AC
,A.PER_STATUS FROM PS_PERSONAL_DT_FST A ,PS_JOB JOB ,PS_SCRTY_TBL_DEPT
SEC WHERE A.EMPLID=JOB.EMPLID AND (
JOB.EFFDT>=TO_DATE(TO_CHAR(SYSDATE,'YYYY-MM-DD'),'YYYY-MM-DD') OR
(JOB.EFFDT= ( SELECT MAX(JOB2.EFFDT) FROM PS_JOB JOB2 WHERE
JOB.EMPLID=JOB2.EMPLID AND JOB.EMPL_RCD=JOB2.EMPL_RCD AND
JOB2.EFFDT<=TO_DATE(TO_CHAR(SYSDATE,'YYYY-MM-DD'),'YYYY-MM-DD') ) AND
JOB.EFFSEQ= ( SELECT MAX(JOB3.EFFSEQ) FROM PS_JOB JOB3 WHERE
JOB.EMPLID=JOB3.EMPLID AND JOB.EMPL_RCD=JOB3.EMPL_RCD AND
JOB.EFFDT=JOB3.EFFDT ) ) ) AND SEC.ACCESS_CD='Y' AND EXISTS ( SELECT
'X' FROM PSTREENODE TN WHERE TN.SETID = SEC.SETID AND TN.SETID =
JOB.SETID_DEPT AND TN.TREE_NAME='DEPT_SECURITY' AND TN.EFFDT=
SEC.TREE_EFFDT AND TN.TREE_NODE=JOB.DEPTID AND TN.TREE_NODE_NUM
BETWEEN SEC.TREE_NODE_NUM AND SEC.TREE_NODE_NUM_END AND NOT EXISTS (
SELECT 'X' FROM PS_SCRTY_TBL_DEPT SEC2 WHERE SEC.ROWSECCLASS =
SEC2.ROWSECCLASS AND SEC.SETID = SEC2.SETID AND SEC.TREE_NODE_NUM <>
SEC2.TREE_NODE_NUM AND TN.TREE_NODE_NUM BETWEEN SEC2.TREE_NODE_NUM
AND SEC2.TREE_NODE_NUM_END AND SEC2.TREE_NODE_NUM BETWEEN
SEC.TREE_NODE_NUM AND SEC.TREE_NODE_NUM_END ) );