*ALL for Row Security

eanderson

Member
I am working to define Row Security for Companies and am considering specifying *ALL for the Table. I am utilizing Inclusive Row Security, and know that I must grant back CO 00000. Any advice and/or experience with this approach?
 
Eric,
Your system configuration would help all to understand your situation.
With that said, I have used row security for Business Units and it works really well. I have never tried using company. Are you only running financials ? I'm not sure company would be effective if you are using other modules.
Regards,
Dave
 
We are using row security heavily but from an
exclusive side. The only other issue we had other
than Co 00000 was if you have any model that people
need to get to that needs to be associated with a
company everyone has access to.
--- eanderson <[email protected]> wrote:
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=OW&Number=49051


=====
Dan Eppich
The Anschutz Corporation
B7332 Coexistant, V4R5 w/central objects
INS Card deployment server
SP16.1
Optio DCS 6.3.2
Fat and Citrix ICA Web Client

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
 
Here's my configuration:

OneWorld Xe - SP 19, running via Citrix and HTML.

We are using Financials, Manufacturing, Sales Management, Inventory Management, Planning, and Procurement in multiple countries. We need to segregate data by country (e.g., Company)

Some BU Row Security will be utilized, but the main concern (now) is to segregate data by CO

Thanks,
Eric
 
I am trying to do the same thing using *ALL (Table) , MCU (BU) and inclusive security.
JDE has told me that the use of *ALL for TABLE will cause problems and that I should define selected tables to secure. The problem is for any application we need to isolate each BU from accessing any other BU. Trying to find out which tables to secure for each application then specify that for each BU is a nightmare.
There is one tool that helps solve some of the issues that arise from using *ALL and that is "Exclusive Application Security". You can use this to bypass any Row security that might be causing application failures.
We are still in test and we are asking JDE to do something about this issue which is very important to us. World users who used BU security will be disappointed when they find out Row security is not a replacement.
SInce you are doing this for CO not BU you might be OK but I wanted to let you know we have had problems already in test mode.
If you're using JAS components then the above workaround is not applicable either.
 
Hi!
You are using a mixture of financials where company is a key part of the data entry and distribution where all of the entry is by BU.
You will be better advised to look at either a mixture or pure BU security (over f0006) plus some form of apps security.
Note that the two key approaches on security are
1) take everything away - then give it back as needed (using CRP scripts)
2) give them everything and take away bits as we find what they shouldnt have access too.

Im a take everthing away type of person - but this takes longer.

Best regards

Peter
 
Eric,
Maybe a combination of row security for BU and company will work for you. Most of the non-financial modules are controlled using BU which then concentrate into companies in the financials (if my undestanding is correct).
Contrary to other posts, I never ran into any problems with row security.
Some say that the use of row security is too much overhead but I say just buy more CPU power if that is the case. It's a wonderfully easy security solution.
Good Luck,
Dave
 
I agree that identifying each table to secure is a total nightmare. The Cross Reference tool is very helpful, though.

Has anyone had success utilizing Inclusive Row Security and *ALL for CO?

We are using the Default Deny approach, and have used quite a bit of Exclusive Application security at this point (we are using HR and have secured the Employee search type at *ALL via Row Security).

Thanks,
Eric
 
Are you using Job Cost? If you are then it adds another level of complexity to the task because bus units are constantly being added.

You need to give access back to things that are accessed by all users like CO 99999 in F0010 and MCU 1 in F0101. All our address book entries have MCU of 1.

I like soyer will be going into test mode soon.
 
I've just started to implement inclusive row security with *ALL for range of companies.

I'm finding that there are problems with custom financial reports using FRW using *ALL for range of companies. If I lock down F0911 and F0902 using range of companies then I don't have the problem.

I had to give access to CO 00000, 99999 in F0010.

Have you successfully implemented inclusive row security with *ALL for CO? How are you setting up row security?
 
Back
Top