row security

I need to set up business unit (row security) so that each user can see only their own BU and nothing else.

We are using solution explorer security to lock down menu access and OW explorer security for action code and application security.

My problem is this. User A and user B belong to the same security groups called AccessA for solutions and OW explorer. (We are using the same security group names for solutions and explorer.) User A should only see head office BU and User B should only see regional office BU.

If I create a new solutions security group called AccessB and attach it to UserB solutions profile. OW explorer profile only allows for 1 security group per ID. Can I use AccessB in order to set up row security?

Or do I need to set up two different security groups for UserA and UserB and attach the new groups to OW user ID?

If not, then what is the best way to solve this problem?

Thanks for your input.

CHo, we recently were up against the same wall and here is how we solved our problem.

First, we'll assume that you've set the your application security for *PUBLIC to lock everyone out of every application. Then, we'll assume that you're having to explicitely add records for each application that you want each group to run, etc. This could easily be 100+ records per group. (whew)

Then we came to the wall you are facing now with row security. We decided that in most of our cases it was much easier to actually go down to the user profile level when using row security instead of defining it at the gruop level. If we had to define row security (specifically for MCU field) at a group level, then we'd have to replicate all of the application security records for a new group just to add one row security record. It just didn't make sense to do that. So, we accepted that we would need to use user profiles for most of our row security in order to minimize the number of groups that use application security.

Hope that helps...

How many users do you have?

I thought about using user ID instead of group ID for row security, but we have approx. 200 users. The executives want row security done company wide.

Or other alternative might be to divide the whole company into head office vs. regional. Apply row security to regional people only.

How long did it take you to set up and test row security?

Cho,

Depending on the size of your organisation I strongly advise against setting any kind of security at User Profile level. The administration involved in maintaining this has the potential to get out of control. Where possible I would divide your groups into logical units and apply the Row Security over CO/MCU accordingly. I would also advise on converting your security table to Inclusive rather than Exclusive as in the long run you will probably find this simpler.

Kind Regards

Doogie

We don't have enough people on JDE yet to even try to evaluate any stress testing. Our final plan is to have a couple of hundred concurrent users.

The problem that we're running up against is that we're trying to keep the number of groups to a minimum. This is quite a task since just the Human Resources and Payroll portion of our project spawned over a dozen groups alone. Since we place a very high value on security, we opted to exclude everyone at first. Then allow access to objects as needed. Just from the HRPR default menus, this required about 1,000 application security records. We've now identified a requirement for 3 groups which will be much easier to handle than a dozen. I'll use SQL to create the new security records and will delete records as required. This only works if we use row security at the user profile level (mostly 1 person jobs).

We don't expect to have this type of security for most of the departments. We're only finding it necessary for HR and PR at this point. So, we'll keep things at the group level as a standard.