Using record level security in LSF9 Security for HR

Toni,
We had this same issue when we made the move to LS9. Unfortunately the record level security functionality is no longer present in LS9. HR09 functionality still exists for use. Otherwise the only option is to use LS9 security. You can use rules several different ways to accomplish this. Let me know if that is the path you go and would like some suggestions.

Thanks.
MD

Toni,
We had this same issue when we made the move to LS9. Unfortunately the record level security functionality is no longer present in LS9. HR09 functionality still exists for use. Otherwise the only option is to use LS9 security. You can use rules several different ways to accomplish this. Let me know if that is the path you go and would like some suggestions.

Thanks.
MD

Lawson delivers an 'HREMP' element group with the typical LS install. You can write isElementGroupAccessible rules against this for the forms you want to secure with record level security. Also, depending on the employees you want to secure and the organization structure, you could organize them into a logical group and secure that way.

Lawson delivers an 'HREMP' element group with the typical LS install. You can write isElementGroupAccessible rules against this for the forms you want to secure with record level security. Also, depending on the employees you want to secure and the organization structure, you could organize them into a logical group and secure that way.

Thanks Matt for your responses. We have tried using HREMP and it works for not beng about to change your own record. But we wanted to have same security as we do today with record level with users not being able to see anyone on their team or people higher than them like VPs, etc. We didnt want to create a new structure in security because it would be too much maintenance and we can't use process level because we have too many to include.

How about some of Lawson functions, Like:
1. isInChainOf CmdOfzEmpInHR(string company, string employee)
2. isSupervisorOf(string RDId)
3. isSupervisorOf EmpInHR(string Company, string employee)
?

What we are trying to do is: They dont want them to see anyone within their own department and ANY mgr, vp, etc that is "above them" The chain of command wouldnt work within their own department and eventhough a manager is "above" them doesnt mean they may not listed as their supervisor or with in their chain of command structure. They just want them to see people "lower" than them. Has anyone done something using security structure? Is it a maintenance nightmare?

How do you define your process level in LS? You might can combine your process level into structure. So, in such way, you just maintain the strutcure for both functions. In fact, struture is less effort to maintain than attribute or group in LS. I was thinking to build the structure to define our process level but I haven't started it yet. So, at the end of each branch, it was everyone in the same process level. and above the end node, you can define your hierarchic struture.

Our process levels are so spread out and there is non hierachic structure in it, meaning VPs, Mgrs, etc are all in one process level.. but I am gonna research it and see.

Im just learning LS9 Security Structures. So if Im asking dumb questions it because Im new at this. Can you use record level/location in a structure?

Toni, no problem at all, I'm learning too. What do you mean record level? You can use location or whatever in a structure... Also, the process level is not necessary hierachic in the structure. We have the same things... All the people in the same department have the same process level, no matter if you are manager or not. What I meant in the previous reply, it is like building an equivanlent table in structure for process levesl... for example, I am in the process level 001, my manager is at 001 too, then I will create a node, maybe called ITM(IT manager) above the node 001, and my manager will be located in the ITM, so he belongs to 001 and also he can see something below him. But all other people in the 001, can't see him. I might create a node above my manager, so my manager's manager can see records below him... anyway, when you design the structure , you are from top to bottom... but I just explained it from bottom up...

I don't know if this will help, but this is what I was thinking about building my structure
for example: Company A has north region and south region, under north region, there are TMC, ROC, MCRWS ( location abbreviation)..., under each location, you might create next level ... and so on.... But at the end of each branch is the process level (everyone in the same process level is in the end node).. it depends how much levels you want to create, so that can meet your needs.

What I mean is each person is assigned in HR11 a record level, location that we used to use in LAUA. Can you not set up record level/location and use that as a structure.

I just thought about this, does your company use HR12? You can write a condition rule base on the setting on HR12 which will tell you who has the higer security level, right? Then you don't need to use the structure..

Yes when I inquire on HR12 there is data.

Structure is looking for people's code in Resouce manager, So you still need to enter person's code to the corresponding attribut in resource manager.. So it doesn't matter what kind of codes you want to use... you can use the record level or location as your structure code. But I think you are asking to retrieve the person's code from database, that is not for structure. Do I misunderstand your question? Otherwise, you can write a rule base on HR12 security level...

I'm not HR staff... but you can look for what HR09, HR12 can do for you... I don't understand these forms... and they are setup by HR manager... The security level is from highest 1 to 9... it will decide what data you can see... I don't know these forms...sorry!

Im gonna look into that HR12 rule and see what happens.. I was trying to write it on HR11.

You can use your current LAUA record level security in LSF9 Security. I would try writing the rules using element groups and then apply them to the employee table. That is how I did it. I made sure they could not drop down and pick them on the HR11 or any other screen. ALSO -- make sure they cannot do a next and get their info. I had an issue with this. HR 11 would tell you the employee was secured but once you got their employee number in the field you could drill around on some of their information, like pay rate history and payments.

We were interested in using record level security as well. We use it on a very limited basis under LAUA now.

According to Lawson LIS (Nina Ilao), record level security is supported under LS. She referred me to KB 202669. I'm pretty skeptical, especially after reading this thread, but that's what she said...

I don't believe record level security works with LS. I have worked with two Lawson consultants and both told me that it no longer exists.

With that said they also told me HR09 no longer works with LS but it does. So it is hard telling.

The security levels and locations are still in the DB but yes, what you defined in LAUA will not work under record level security, you have to write the conditional rules to use the elements just like you have to write them for process level, company and tokens etc.

HR09 and HR10 do work because their use is hard coded into the cobol code which has nothing to do with external security either LAUA or LS.

Record level security does work fine in LS9. I have used it many times. The only think it secures on is security level and security location contained within the HR11 records. This gives you plenty of flexibility to accomplish a variety of restrictions. This rule would be written on the HREMP element group. In order to properly secure on your own record as well you would need to either not allow users to see employees at their own level including themselves or you would need to specifically restrict them from their own record. This can be accomplished by simply creating a new element group that would restrict on company and employee. This element group would need to be referenced in each application and file. The issue here is that this would mean continual maintenance of the rules if you want to change the logic. The best way to do this and it should be done in order to ensure that all forms use the logic is to create an element group rule for HREMP and your new element group and then reference them both inside the application and file using iselementgrpaccessible. This would be a one time maintenance as from there out you can simply change the element group logic and the changes would go across all your apps and files with the rules. The rules on files and apps should be done anyway as not all applications utilize programmatic security.