Business Unit Security

nataliej

Member
Hello everyone...

I've got a question about implementing Business Unit security in OneWorld. Our main security at the moment is set up to deny all access and then allow back access to programs depending on each user's requirements.

I want to create similar security for the business units, so by default user's have access to nothing.

My main problem at the moment is that we're already live on OneWorld and our technical team do not want to create a separate security table for testing purposes. Obviously I'm a little bit concerned that making a big change to the security like this may grind our system to a halt.... I do have a separate environment set up for testing though.

I've read the numerous posts about this, but still have a few queries.

We are currently using the standard exclusive security, so in theory each user would need two lines of row security e.g.

Table DataItem From Thru Add Change Delete View
*ALL Company 00001 20999 N N N N
*ALL Company 22000 99999 N N N N

Would this work? I keep reading about problems encountered by using *ALL/*PUBLIC. What would be the benefit of using inclusive row security? In the above example I would now need three rows wouldn't I?

Table DataItem From Thru Add Change Delete View
*ALL Company 00001 20999 N N N N
*ALL Company 21000 21999 Y Y Y Y
*ALL Company 22000 99999 N N N N

Or am I missing the point?

I've been testing this so far by using security against a single logon but I'm already having problems. For instance adding the following lines made almost all our applications fall over:

Table DataItem From Thru Add Change Delete View
*ALL CostCenter 1 20999 N N N N
*ALL CostCenter 22000 99999 N N N N

The problems seemed to be resolved by using the range 2 - 20999 and 22000 - 99998, leaving '1' and '99999' unsecured.

To prove my setup works I'm hoping to get three users set up. One with access to business unit range 'A', one with access to ramge 'B' and one with access to both 'A' and 'B'. It is vital that the users do not see each other's data.

Any advice or opinions would be greatly appreciated!

Natalie.
 
First of all, I can't imagine why a technical dept would not create the setup so that you can test security before putting it in a live situation. Lets give them the steps to set this up and maybe they will see that it is not so difficult. After testing, you can inactivate this setup.
1) The Security Workbench table is F00950 in the System data source. Copy that table from the System Data source into an already existing data source that is environment specific for your test environment, say Control Tables - Test.
2) In OCM for both the system and server maps, find the OCM mapping for the F00950 for the test environment, it should say System - B733x datasource. Change just the one OCM entry for that test environment to the new data source that you copied the file to - Control Tables - Test.
3) sign on an test. it's as easy as that.

Next, I've not used the *ALL entry for tables, for every table that I'm worried about users having access to I specify that table. We secure the F0911, F0902, F1201, and now are getting ready to secure payroll tables as we are doing new things with payroll. The issue you are probably running into when you try to use the Row security starting with Business Unit 1, is that some tables, like the A/B, F0101 use BU 1 as a default value when you enter new A/B records. And some tables leave the BU blank.

Next, you can either use Exclusive security or Inclusive Row security, but not both. If you already have security setup one way or the other, if you decide you want to use the other, you have to change all of your security records to reflect this. For exclusive security you should not need the 'Y' records, only the 'N' records. But I do not know enough about exclusive security to understand how it handles records where you would like the user to be able to view the record, but not update it.
 
Back
Top