• Search Forums
    Advanced Search Topics Posts
Prev
Next
Forums Infor / Lawson Platforms S3 Security

LSF9 Security along with HR Data Security

 8 Replies
 0 Subscribed to this topic
 17 Subscribed to this forum
Sort:
Author
Messages
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: 549
Veteran Member
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
Basic Member
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.
Al
Greg Moeller
Veteran Member
Posts: 1498
Veteran Member
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
New Member
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
New Member
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
New Member
5/1/2011 8:45 PM
Sorry I misspelled Write.
Mark Petereit
Advanced Member
Posts: 21
Advanced Member
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.