Migrating from LAUA to LSA security

 10 Replies
 1 Subscribed to this topic
 15 Subscribed to this forum
Sort:
Author
Messages
Greg Moeller
Veteran Member Send Private Message
Posts: 1498
Veteran Member

We are trying to get a handle on LSF9 security (moving away from LAUA).  We have been to training, and had a consultant here for a week.  We also purchased the FastTrack security templates, but still seem to be having issues.

Situation:  We need to restrict certain roles from seeing exec pay-rate by process level (900 & 950).  We have the HRFFAFileAccess opened wide up (as delivered) and assigned to a role that should be able to see pay rate for everyone.  User cannot see pay rate for anyone.   The users that should be restricted, can't see anyone's pay rate either.  I can't figure this baby out.

On the field in the table, we have the following rule applied:

if(trim(getDBField('EMPLOYEE','PROCESS-LEVEL',table.COMPANY,table.EMPLOYEE))=='900'||trim(getDBField('EMPLOYEE','PROCESS-LEVEL',table.COMPANY,table.EMPLOYEE))=='950')    'NO_ACCESS,' else    'ALL_ACCESS,'

 

What are we missing?

MattD
Veteran Member Send Private Message
Posts: 94
Veteran Member
What field in the table is this written on? Matt
MattD
Veteran Member Send Private Message
Posts: 94
Veteran Member
Also do you use HR09 Security? This still exists and can be used to now allow access to pay rate information. Matt
Greg Moeller
Veteran Member Send Private Message
Posts: 1498
Veteran Member
The field is PAY-RATE. Yes, we have HR09 Security set up, but really aren't clear how to implement it with LSA Security. Could you elaborate?
Greg Moeller
Veteran Member Send Private Message
Posts: 1498
Veteran Member
Also, our company is 0001 , but we always enter it as just 1 - do we need an lztrim in the formula somewhere or not?
GregSl
Veteran Member Send Private Message
Posts: 38
Veteran Member
You have to use the same rule on HR11.PayRate Field. If you are using ESS, check the Rules for the users access to ESS tables. Hope this helps.
Greg Moeller
Veteran Member Send Private Message
Posts: 1498
Veteran Member
We are, but with LSA Security shouldn't the most permissive access in the role win out?
Greg Moeller
Veteran Member Send Private Message
Posts: 1498
Veteran Member
I removed the ESS portion from the role, and still no Pay-Rate field exists. Here is the rule that we have applied to the HR11.PayRate field. if(form.EMP_PROCESS_LEVEL=='900'||form.EMP_PROCESS_LEVEL=='950') 'NO_ACCESS,' else 'ALL_ACCESS,'
GregSl
Veteran Member Send Private Message
Posts: 38
Veteran Member
Try using the same logic on both : HR 11.PayRate and EMPLOYEE.PayRate HR11 with (form.EMP_PROCESS_LEVEL=='900'||form.EMP_PROCESS_LEVEL=='950') EMPLOYEE (table.PROCESS_LEVEL)=='900' etc. The Role you are testing has no access to pay rate or Check LS ='N' ,pointing to LAUA secuirty. Grant access and check.
MattD
Veteran Member Send Private Message
Posts: 94
Veteran Member
With regards to HR09 security if you are currently running HR09 security and have users restricted that way it will override Lawson Security 9. Lawson originally told me that HR09 doesn't work once you are on Lawson Security 9 but this is not the case. The most permissive rule "wins" in LS9, but only if it is an LS9 rule. HR09 will outrank them all even if it is more restrictive. I would try writing the form rule on the Pay Tab. Get it working there, then work with the PAY_RATE field. It's just easier to tell if the form rule is working and that no other rules are "winning". I would also remove all but one security class just to make sure another rule is not outranking your other rules. (Okay two security classes a file class and the class containing HR11) Hope this helps.
Greg Moeller
Veteran Member Send Private Message
Posts: 1498
Veteran Member
I think we've gotten this one working now! (although I'm not real sure what fixed it....) I believe that it was HR09 security that was blocking it all along, but can't confirm nor deny that.