swhitmire
Reputable Poster
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 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?