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.
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.