LSF9 Security along with HR Data Security

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3288
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1351
Roger French	1311
mark.cook	1244

Kartik

Posts: 5

4/6/2011 3:43 PM

I have set up LSF9 security in HR with TRAdmin Role (for Training Administrator) and appropriate security class with restrictions on HR11 (cannot view SSN, pay rate etc). Since I am migrating from LAUA, there is already the existing HR Data and User security set up in HR09, HR10 and HR12. I find that the HR Data security completely overrides the security rules set up in the security class. For instance, if I deny access to view SSN in the security class, but the appropriate security level in HR09 and HR10 allows SSN view, then the Data Security prevails over LSF9 security. Has that been the experience with others? Is there a way to turn off the HR Data Security so that all the access requirements are encapsulated in the security class only?

Roger French

Veteran Member

Posts: 545

4/6/2011 3:55 PM

Could you remove the employee's info from HR09? And also the security level from it's HR11 record?

Al

Basic Member

Posts: 17

4/6/2011 4:02 PM

Make sure the checkLS flag is set to Y for the ID's you are using to test this out.

Greg Moeller

Veteran Member

Posts: 1498

4/7/2011 1:02 PM

Yes, HR09 will override any security setup in LS. We stumbled upon this when we were testing our security implementation. Had to remove all HR09 records if we wanted LS to behave correctly.

Kartik

Posts: 5

4/15/2011 9:32 PM

Thanks for your insights. I have done the following to reset data level security. I have not been able to test it due to other issues. I shall keep the forum posted

1. Reset Security Level / Location to 9 / 9999999999 in Company Set up HR00
2. Reset Security Level / Location to 9 / 9999999999 in Process Level Set up HR01
3. Reset Security Level / Location to 9 / 9999999999 in Department Set up HR02 (Table DEPTCODE fields SEC-LVL and SEC-LOCATION)
4. Delete all values in User Data Item Security (HR09)
5. Reset the Security Level field in Data Item attributes to 9 (Table PASCRTY field SEC-LEVEL)
6. Reset Security Level / Location to 9 / 9999999999 in Employee Set up in HR11 (Table EMPLOYEE fields SEC-LVL and SEC-LOCATION)

ScottG

New Member

Posts: 1

4/28/2011 8:48 PM

Can anyone offer a reason why HR security is not affecting access for a user recently converted to LS? I am in the process of converting from LAUA to LS an existing account, under LAUA the user is unable to see executive records in the HR11.1, under LS the HR security is not kicking in. I talked to Lawson support, and was advised that HR security is not used in LS, now I read that it is.

Please go easy on me on this one, just took the admin course, less than 2 months working with the system in any meaningful way, so stumbling along as best i can.

Thanks!

Eric.Beck

New Member

Posts: 2

5/1/2011 8:44 PM

LSF9 Security requires that you create an Element group for Security Level and Location, if you would like to use the HR Application security. The setup must be correct in the application and in the RULES you right in in the LSF9. You also need to review the HR Security suppliment that show what forms in the HR Suite that can be secured by SEC_LOCATION. I think I have the PDF of this if you needed.

Eric.Beck

New Member

Posts: 2

5/1/2011 8:45 PM

Sorry I misspelled Write.

Mark Petereit

Advanced Member

Posts: 21

5/1/2011 9:24 PM

It's been a couple of years since I looked at LSF9 security, but from what I remember, there really wasn't a clean path from LAUA security to LSF9 security, being that LAUA security was subtractive (i.e. users start with access to everything and you add restrictions) whereas LSF9 security is additive (users don't have access to anything until you grant it.) Most organizations, especially those employing data security professionals, opted to completely abandon their LAUA security setups and start over in LSF9 with a clean slate. As I recall, after our own thorough analysis of LSF9 security, we came to the same conclusion and created all new profiles before migrating to LSF9.