the delivered job data component has EMPLMT_SRCH_COR as its search record (overridden at menu level). It looks for a tree named "DEPT_SECURITY". It can be setup with a hierarchy of DEPT IDs at "Tree Manager -> Tree Manager".

#1. Department IDs can be setup at "Setup HRMS -> Foundation Tables -> Organization -> Departments" (u can associate a company with a dept here, and dept to an employee on job data first page)

#2. Create a permission list with it's name starting with "HCDP" (HC Data Permission) and a description.

this way, a hr user from C3 would be able to see only those rows of emp A1 for which company is C3.

[#2] let us say, if ur hr head needs access to all companiies data u may wrap the above code with:

if not (isuserinrole(HR_SUPER_ACCESS)) then

HR_SUPER_ACCESS = a new role that u would create to bypass the restriction for a few super users.

[#3] more sophistication:
u may create a setup table which stores a mapping of ROLENAME and COMPANIES_ACCESSABLE. ur code should pick the list of companies that r mapped for the current user's role & accordingly filter the rows "where company in (a,b,..)"

But actually our req to restrict the data in rowset level. (suppose if
employee worked in multiple comp's current comp empl should not see the
earlier comp details.) with out writing a peoplecode, is any alternate to
solution using configuration(delivered/customised) (i..e in Data buffer
level (rowset)).

Set Up HRMS > Security > Core Row Level Security
Security Sets --> go to PPLJOB and bottom of page enable Type 004 - Job Company
Go to next tab for Security Update Groups and make sure Company is in list.
Save change
Navigate to

Sorry hit reply before done....
The transaction security join that will update is SJT_PERSON
To refresh this data navigate to Refresh Trans. SJT Tables
Run control parms:
One Security Set
People With Jobs
Check the box to Refresh all Rows
Run AE process - SCRTY_SJTUPD

I am on version 8.9. Thought the security was the same for 8.8, sorry.

Did you try the suggestion previously to tie in company value to the
department table and then do department level security? Depends on how
the departments are structured based on company if this would work for
you. Is there a department tree setup already?

I have seen th post. This solution we tried overriding the record at menu
level but in job data company is not a key field.

Moreover i dont want to restrict user at search level. I should restrict on
a Data buffer level (suppose say empl click on correct history - he has to
see only his company working details) with a configuration.

PeopleSoft row level security does not work to match your requirement.

Data security works by looking at the current row in Job to determine if
you qualify to view information on a specific employee.

If you have access to the current row then you can view any information
on that employee - up to the historical level defined via permission
list.

There have been complaints for years where some companies have wanted
their employees to have access to historical data even if they don't
have access to current data on an employee. For example, you have an
employee in company ABC from Hire until 2008. In 2009 they get
transferred to company DEF. An administrator for company DEF will no
longer have access to that employee since they are now in company ABC.

The delivered row level security configuration will not work for you. I
have never heard of a company designing their own row level security and
would not recommend doing so.

[ #1 ] There is no way to restrict data in buffers / rowsets without code or permission list.

(Once the EmpID A1 comes as output in search page, his entire job history rows WILL be seen on the page, UNLESS you "remove correct history access" to that guy C3 using permission list options OR writing rowset.select.where code)

[ #2 ] This is a case of an Inter-company transfer (ICT) of a single EmpID. U can explore the below option as an alternate HR data maintainance policy:

(a) terminate the current ID A1 with the relevant Action 'ICT'
(b) create a new EmpID A2 for the same guy A1.
(c) map this new ID A2 to A1's termination row (on job data page 1, u hav a group box - "Intercompany xfr", where u can map this guy's new company & new ID)

(This way ur guy would be having 3 separate emplids with corresponding companies as C1, C2, C3 respectively. So, ur problem would be solved using the search record which would filter out the irrelevant company's ids based on the dept id)

coz, as long as the empid (key) is the same (across multiple companies due to transfer), i think there is no way to filter specific company's rows without code

[ #3 ] u can try a complicated/desperate way:

registering the component with let us say 3 diff search records, in which u would hard-code ".. from job .. where .. and company = 'C1' " and ao on.. but that would mean everytime you ur organization creates a new company, u'l hav to register again using a copy of the earlier search rcd with, say "and company = 'C8' "

quite random thoughts.. but i hope to provide an insight into the possibilities and im-possibilities :)

Diananye: May be this scenario not recommended, but this one of the req of
our client.

Srinivas:

#1) It will not work bcoz the same guy want to see the histroy rows of
empl..?
#2)Changing the emplid to new emplid. it will change the entire business
process.
#3)This way is not possible there r so many comp's will exist in a
Orginzation.

We may want to implement this through a global configuration it may apply
for the entire organisation.

I think this scenario is not possible in peoplesoft till 9.1..Let's hope in
future may come..

Obviously specific code changes are possible but you open up a mess of security issues and how do you test for all possible scenarios? At what cost will this be to the client? Wouldn't it be wise to let them know the request is not inherent in the existing architecture but it is possible to do this manually? What will happen if there is a bug in the custom code and someone gets access to data they shouldn't see? You cannot blame the bug on Oracle...

As Diana and others identify the delivered PSFT security simply does not handle this. While at PSFT I covered Security in PeopleTools Product Strategy, and enhancements to address such row level security had too great an impact and hence has yet to be accomplished in standard psft.

I'm with Smart ERP Solutions now with other ex-psft folks and they have an add-on solution called Smart Security that provides such row level security, securing any page based on any field, any app, any module, any version 8.x and beyond--while avoiding customizations.