Row Security On Address Book

Hi

I recently put row security on the F0101 to secure most user groups from see in employee records. I used "Search Type" (AT1) and gave everybody access to A-D and F-Z but no access to E. We suffered a massive degradation in some of our AP reports such as R04413 (AP Summary Report) and R04570 (Create Payment Control Groups). The processing times went from 2 minutes to in some cases 1.5 hours.

I have of course deleted that bit of security, but now am left with the problem of how to secure the Employee address book records. Looking for ideas or solutions others have used.

Thanks
Marty

Hi Marty

We use row security for the same purpose. But I did the other way around. I blocked (No add, delete, change or view) the group which I didn't want to give access to Search Types other than C using range A-B and D-Z. We run R04413 and R04570 daily but don’t have any issues.

Sathu

Thanks for this Sathu. I just can't get this to work! If I use your method:

*PUBLIC F0101 AddressType1 E NNNN
DEVPAY F0101 AddressType1 E YYYYY

With this I end up locking everybody out of the address book.

If I use:

*PUBLIC F0101 AddressType1 A-D YYYYY
*PUBLIC AddressType1 E NNNNN
*PUBLIC F0101 AddressType1 F-Z YYYYY

DEVPAY F0101 AddressType1 E YYYYY

Then I get the massive overhead and everything runs like a dog. Could you give me the exact settings that you have? I should also mention that the basis for our security is that everybody has access to everything until we secure them out.
Thanks
Marty

Marti,

Just picked this up. Your settings, assuming that you are on exclusive (standard) security should be something like:

For *PUBLIC

F0101 AddressType1 A - D Y Y Y Y AT1
F0101 AddressType1 E-E N N N N AT1
F0101 AddressType1 F-Z Y Y Y Y AT1

I think that this may solve your issue.

Doogie

Thanks for the reply Doogie. Our base security is to grant access to everybody then exclude them from the applications we don't want them to have. As far as the row security goes, the suggestion you sent is exactly what we tried. The result was to grid the system to an unacceptable speed on a lot of applications. I'm blowed if I know where to go from here!

Hi Mjf

I think your primary issue is that you have an Open Security model. A lot of companies through their implementation seem to put an Open security model in place - and this causes issues when you go into production.

I would suggest that you first create a plan to migrate to a Closed security model.

Row-level security will certainly impact performance since multiple selects will be performed and rows will be checked against security instead of a single select.

Jon Steel
OneWorld Technical Specialist

Thanks Jon

I've been coming to that conclusion as well. The frustrating thing for me is
that when we first went live with OW, I did set up the security as closed.
When we upgraded to B732 we changed it to an open model. Not one of the
better decisions I've made in my career! Next upgrade, I'm definately going
back to a closed model. Thanks for the help.

Regards

Marty Fleming
Business Analyst
Richmond Limited

Phone: +64 +6 8786464 Ext 8168
Fax : +64 +6 8780959
Email: mailto:[email protected]

OneWorld: Xe SP16.1
Database: Oracle 8i
Enterprise Server: Compaq Proliant 8500R W2K






OneWorld: Xe SP16.1
Database: Oracle 8i
Enterprise Server: Compaq Proliant 8500R W2K