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
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
    Posts: 94
    Veteran Member
      What field in the table is this written on?

      Matt
      MattD
      Veteran Member
      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
        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
          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
            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
              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
                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
                  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
                    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
                      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.