MSS Drill Down Security

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.

Thanks for the reply Shane. I don't think the business will go for it but at least I can give an option.

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.

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.