LS Security-process level security - PROBLEM!

We use Element Groups>PROCLEVEL Security extensively to restrict subgroups of employees to HR-related data for their own process level (different locations, etc.). It seems to work across the board on inquires, selects, drop-downs, etc. Except we just found a loophole in HR07: when you drill on a supervisor code, it opens up the world and you can see dependents, etc. for all employees. Has anyone found a way to prevent that (other than taking away HR07)? Anyone willing to share how you set up process level security, especially if that piece is secured?

Are there other jumping off places that you are aware of that get around process level security? Feel free to reach out to me directly at jgardner@dg.com.

InPower Virtual 2020 Roadmap Presentation.pdf

Find more posts tagged with

Infor Lawson Technology Group - Discussion

Comments

Derick Safarian

If you use the DrillAround feature, it is looking at the security you have written on tables/files. If you are seeing Employee data, then perhaps the EMPLOYEE table is not secured properly. After you wrote the rule on the PROCLEVEL element group, you also need write a rule on the EMPLOYEE table using the isElementGroupAccessible() function, which references the PROCLEVEL element group, and uses the table.COMPANY and table.PROCESS-LVL fields.

unknown

Thanks Derick. I agree with you in general...if we want to restrict some subset of data in a table, we have to write a rule on that specific table. But it is my understanding and experience that Element Group security works for everything (or so I thought) - forms, tables, etc. For example, when I am testing these roles, I can't seem to find any way to get data from the EMPLOYEE table for employees outside my authorized process level, even though there is not any specific process level security written directly against that table. I think the element group security is meant to apply to everything - otherwise we would have to write process level rules on every single table in HR, PA, BN, PR, etc. So far it's just this HR07 and that supervisor field that allows a wormhole to some of this HR/PA data - reviews, emergency contact, certifications, dependents, etc.

I could be proven wrong though, it just doesn't seem consistent with everything else I have been told and have experienced.

0712050808501819.doc

unknown

There is another way, although it requires customization. That is: to go into the screen rules and drill-around rules (.sr and .or files) and customize the rules/lookups/drill-arounds. Unfortunately this is a customization that has to be maintained. I did it at another employer to eliminate SSN fields from drill-arounds. It's also possible to customize a screen to point to customized selects/drill-arounds. That's a further customization that also has to be maintained. I don't recommend doing this unless there is no other way. I would call this the "brute force" approach, since it directly fixes the problem without reference to any security setting. Hopefully you will find a more elegant solution in the security model.

unknown

user.attributeContains('ProcessLevelControl',trim(getDBFieldByIdx('EMPLOYEE','PROCESS-LEVEL','EMPSET1',table.COMPANY,table.EMPLOYEE))) Try putting something like this on the HRSUPER table. Since this table does not contain process level you have to add the condition to go find the process-level the employee is in and then it should block it.

Copyright © 2025 Infor. All rights reserved.