Address book and HR security...

Ok, I know that this has been discussed here many times, but since we've just started our HR implementation,
we've just now encountered it.

Like everyone else, we need to secure fields like Tax ID and Address for E records in the address book
so that only HR users can see them. Row security on E won't work, since purchasing users need to put themselves in
as buyers and users' workcenters are tied to their AB numbers. Column security won't work, since for non-E
search types there are lots of users who need to see the information.

We found JDE's SAR for this (6438564) where they say they're not going to fix it,
and looked at the document (OTT-01-0089) that explains how to fix this by modifying the AB application.
(BTW, can anyone actually find documents on the KG anymore? I found a whole bunch of
questions in which the document was referred to as the answer, but not
an actual copy of the document... we got it from someone who happened to have it saved.)

That still leaves the info open for anyone who uses UTB or ODA, which we certainly can't
take away from everyone who's not in HR.

So, what we've thought about doing is creating a new search type, like U for user, and creating a U
record for each user's login to be tied to. Is there any reason this won't work?
What about Employee Self-Service? Does it require that the login be associated with
the E record?

And ESS brings up another question about the HR tables themselves. We had planned to just lock all
non-HR users out of them by changing everyone else's system user to a user without access to those tables.
Will that break ESS?

We've done this at other clients. We avoided the modification route since the clients wanted to keep the applications 'pristine'. We developed a tool that uses security to accomplish this. The tool is either scheduled or triggered if appropriate. We continue to use standard functionality, and maintenance is hands-free.

Most importantly, privacy is maintained for the employees.

Let me know if you would like to discuss this further offline.

- Scott

Scotti,
We did just what you talked about. First, we secured the E records in F0101 using row security.

Then we added a new search type for non-confidential employee information in the address book. In our case, the only data in that record is employee name and employee number in the secondary key. This is the number we put in the security record for login. We also use this number in the approval routes for purchasing.

We decided to go this route when, after setting row security in the F0101, requisitioners names were red-barred in the approval processing screens for purchasing.

We also used the system user to secure HR files in the AS/400. For non-HR users, our system user cannot access the library containing HR files. This has worked very well for us.

Janice
XE, update 7, SP21, AS/400

Hello.
I'm going to pick up this old thread to bring a new spin on it. Instead of applying additional security or duplicating employees under a different search type, we're considering running a scheduled UBE to simply wipe out the F0101.TAX field when the Search Type = E. Preliminary analysis indicates that this wouldn't cause any issue since it is the F060116.SSN field which is used throughout the application.

I realize that probably the best would be a duplication of the search types. However, our client has already invested a lot of time and energy creating approval queues that would have to be completely redone.

Any comments on our approach? Any possible crashes that we are not foreseeing?

Thanks
edsfc
OW Xe_i1 update 7 sp23