I came across a situation, when I set CheckLS='YES', the Role does not recognize the Rules to access the Company and Process Level, based on the element group. It gives access to everything ! Same thing happens, if I deny access to HR system code, for the same Role. They work fine on LAUA with checkLS = "No" When using LAUA it's easy to find exceptions from the ios.log. In the above situation, what are the logs I can check where the Role's permissions are located ? Greatly appreciate your kind assistance.
I came across a situation, when I set CheckLS='YES', the Role does not recognize the Rules to access the Company and Process Level, based on the element group. It gives access to everything !
Same thing happens, if I deny access to HR system code, for the same Role.
They work fine on LAUA with checkLS = "No"
When using LAUA it's easy to find exceptions from the ios.log.
In the above situation, what are the logs I can check where the Role's permissions are located ?
Greatly appreciate your kind assistance.
Also, see https://www.lawsonguru.co...cation-Security.aspx
Thanks to both of you.
I got the Security Rules for the Roles by running RM User Report via Lawson Security > Reports > Report Maintenance.
I have Security On for all the data areas.
I tried the Debug with exact Settings per John's link and this is all I got.
2008-05-01 09:54:53 com.lawson.lawsec.default.WARNING LOGGING.NOTIFICATION() Info: Default logger com.lawson.lawsec.default configuration: level is FINEST, output file is lase_server.log Users Logged:[ANIV]
2008-05-01 09:54:53 com.lawson.lawsec.default.WARNING LOGGING.NOTIFICATION()
Info: Default logger com.lawson.lawsec.default configuration: level is FINEST, output file is lase_server.log
Users Logged:[ANIV]
I vaguely remember having to do something special in Lawson Security Administrator from the class in order to debug rules. I want to say that on the Auditing + Logging tab we had to add "ALL" as a user to log but I'm not 100% certain. Is this correct John Henley?
Also, just out of curiosity do you use strToNum() in your rule? Can you post an example?
Assuming LSF 9.0 Security is turned on, I would guess that you may have a rule conflict where although in one security class you restrict something, another security class grants the access. In LSF 9.0 Security, the greater access wins when there is a conflict. I would suggest creating a temporary role specifically for troubleshooting this issue and assigning 1 security class to it at a time to see which security class is granting the unwanted access. If your role is complex then you may have to get more granular and isolate the rule. Good luck!