PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 5/4/2010 2:22 PM by  Fernando Labrada
MSS Drill Down Security
 4 Replies
Sort:
You are not authorized to post a reply.
Author Messages
Kevin H
Private
Private
New Member
(4 points)
New Member
Posts:2


Send Message:

--
4/23/2010 3:34 PM
    I have an issue with MSS drill down security and it's effect on ESS. LAUA is being used until LSF is rolled out in a later phase.

    The business wants to restrict drill security for direct reports. They want to hide benefit, deduction and certain employee information. In LAUA, I have used file and field security to restrict the data on the security class. Those changes make MSS work exactly how I want it to.

    The problem is with ESS. The security restrictions also keeps the employee from keeping their own information as well.

    I asked Lawson Support and they said to use a condition to correct the issue. This option will make maintenance a nightmare and director level employees will still see the information to their manager direct reports.

    Has anyone else dealt with this problem?

    Thx in advance.
    Shane Jones
    Private
    Private
    Veteran Member
    (1246 points)
    Veteran Member
    Posts:460


    Send Message:

    --
    4/24/2010 1:47 AM
    This is an issue that many of us have... This was going to be resolved with LSA but it does not resolve the issue in LID. If you setup the conditional security in LSA you can apparently make this work as long as users will only be using ESS/MSS/Portal - Not LID.

    We are still using LAUA and have dual accounts for security - oone account for HR access and one for personal access. It is a bit messy but it has worked.

    I got a proposal to setup LSA with conditional security and was told that the high price was primarily because of the conditional security.
    Shane Jones
    Tools: HR, Payroll, Benefits, PFI, Smart Office, BSI, Portal and Self-Service
    Systems: Lawson, Open Hire, Kronos, Crystal Reporting, SumTotal Learning
    ** Teach others to fish...
    Kevin H
    Private
    Private
    New Member
    (4 points)
    New Member
    Posts:2


    Send Message:

    --
    5/3/2010 12:40 PM
    Thanks for the reply Shane. I don't think the business will go for it but at least I can give an option.
    Shane Jones
    Private
    Private
    Veteran Member
    (1246 points)
    Veteran Member
    Posts:460


    Send Message:

    --
    5/4/2010 11:50 AM
    Kevin,
    I just tried to setup Lawson Security on our TEST box and have had some success with my own conditional access settings.

    Since you can use both LAUA and Lawson Security on the same system you might want to think about using LAUA for HR/PAYROLL/BENEFITS/FINANCE users and then use Lawson Security for the EMSS users. (At least until you can move everyone to Lawson Security... LAUA will keep you from doing what you need.) Setting up Lawson Security is not a small thing - but I just setup my first account to use Lawson Security and it appears to have fixed the issue - as long as the user does not intend on using LID. (It took about 4-6 hours to setup my first role using conditional security access.)

    The conditional setup was rather easy because it has an expression builder. You just say they can access if the form and user have the same company and employee numbers otherwise no access.

    Hope this is helpful.
    Shane Jones
    Tools: HR, Payroll, Benefits, PFI, Smart Office, BSI, Portal and Self-Service
    Systems: Lawson, Open Hire, Kronos, Crystal Reporting, SumTotal Learning
    ** Teach others to fish...
    Fernando Labrada
    Private
    Private
    Basic Member
    (34 points)
    Basic Member
    Posts:14


    Send Message:

    --
    5/4/2010 2:22 PM
    If you write the rules to the tables so that they can only be accessed by the user tied to the PDL_EMPLOYEE identity (where PDL is the product line) in the ESS class, then the user will be able to see their own data as intended in ESS but the managers will not.

    So, for instance, the BENEFIT table would be secured in the ESS class with something like:

    if(isElementGrpAccessible('COMPEMP','','HR',lztrim(table.COMPANY),lztrim(table.EMPLOYEE))){'ALL_ACCESS,'}else{'NO_ACCESS,'}

    Where COMPEMP is an element group containing the elements COMPANY and EMPLOYEE and is restricted to the contents of the PDL_EMPLOYEE identity in RM with an element group rule like:

    if(user.getCompany()==lztrim(COMPANY)&&user.getEmployeeId()==lztrim(EMPLOYEE)) {'ALL_ACCESS,'}else{'NO_ACCESS,'}

    So that a user that drills into the BENEFITS table will only be able to see their own records and a manager will see nothing.

    You will need these types of rules for every table you need to secure. It is a bit of work up front but once it is set up, it does not require much maintenance.
    You are not authorized to post a reply.