Row security

soyer

Active Member
Hello to all OW experts,

We are World co-exist with XE, SP20, Upd4. and trying to figure out how to imitate the Business Unit Security from World side with the Row security using *ALL and MCU column on the OW side.
JDE tells us that the use of *ALL would cause trouble with some applications and they don't support or recommend this approach. But, our business is such that we can't allow any user from Business Unit X to see or do anything with data belonging to Business Unit Y, and visa versa.
Is anyone implementing Row level security using *ALL with the MCU column ? If so, have you encountered any issues with that?

Any of the experts out there if this isn't recommended what is the replacement for the World Business Unit Security in OW? I do realize that the Row security is not an exact replacement for BU security.

Do you know if the BU security will ever be available at some OW release in the future?

Thanks in advance for any and all inputs.
 
Actually YES and NO.

Instead of *ALL turn on Inclusive row security (ott-01-0099). This is the
greatest OneWorld security enhancement and will make your life a lot easier.

After configuring this then just indicate the BU's that a user CAN have
access to. I've also customized the P00950 in the past to give Business
Analysis the ability to do Row security for only one data item in a seperate
Security Table in Control Tables - CRP. This way the CNC doesn't have to
both with the very frequent changes in personal and Business Unit Access.

As for Business Unit Security being available in OneWorld? Well it's now
called row security. Business Unit Security is just a type of row security.


Colin



Colin Dawes, Sr. Technical Consultant
Syntax.net
B733.1 to ERP 8.0
Oracle 8i/9i/SQL Server 2K, DB2
 
Hi!
I have actually done what you are trying to achieve through "inclusive"
(see later post from Colin Dawes) row security e.g. to allow a
person/group access to BU 123 then you set up
Exclude MCU<=122
Exclude MCU>=123

OK my knowledge is a little dated so JDE MAY have actually fixed this
little gem, but I doubt it.

Watch out for some of the gotcha's around shared accounts, such as bank
accounts and item/bpl's which may require some additional thought!

Best regards

Peter

Peter Bannister

1st Consulting Ltd
www.1stconsulting.biz

Mobile : +(44)-7711-649358
 
Thank you for your reply Colin...
I do have "inclusive" security turned ON already. And we are specifying ONLY the BU's that the group has access to. My question is, when you do this:" *ALL(tables) MCU(column) for GroupXYZ from 0000 to 0010 Y,Y,Y,Y" for example does this create any problem with any application like JDE is suggesting. They are telling us that I should not use *ALL in the above Row security setting instead I should specify each file that I want to set permissions for.(ie: F0101 MCU GroupXYZ from 000 to 0010 Y,Y,Y,Y). This is almost impossible because we need to do this for every single file that MCU is in. We simply want to keep every user restricted to their own BU for any application that uses any table.
Are you specifiying *ALL when you set up your MCU Row security?or Did you specify each file? Thank you so much for sharing your experience.
Erkut.
 
For what it's worth...

We use exclusive row security to implement BU security. For every user we specify the BU's that he/she can NOT have access to. But... next to MCU, we also set row-level security to CO and KCO. We got some SQL scripts in place to execute mass updates for row security (e.g. new cost center). For new users, we simply copy the row-level security records from another user.

It kinda looks like:
USERX *ALL MCU 000000 thru 000120 N N N N
USERX *ALL MCU 000120 thru 000120 N N N N
USERX *ALL MCU 000130 thru 000130 N N N N
where we enumerate all business units this way. This enables us to turn on/off access to a business unit.

same for cost center and cost center key.

Have to admit that this was already set up before I joined the project. I know it works, but the exact justification for this approach I don't know.

Cheers,
Lambert
 
Re: RE: Row security

Peter,

Plese see my reply to Colin below. Let me know what you think.
Thanks.

Soyer.
 
You could try implementing row security on the Business unit master file F0006. I tried it here and it appeared to work but we were unable to implement it due to existence of Parent Child account relationships spanning different business units.
 
I have been following this thread with great interest. I have a need to secure a two divisions from each other. Since I am the only support person, I am looking for the simplest solution.
We have set up 2 companies, 1 & 5, so I can handle that, I think. My problem is business unit(MCU). I see that there are many types of business units; balance sheet(BS), income statement(IS), warehouse(WH), work center(WC). Our WC types are not sequential or in a range for each company nor are our IS types in any semblance of order.
I had thought of using *all but JDE doesn't approve but won't say why. I really am at a loss of what to do, I cannot afford to be a fulltime security officer nor do I want my security model to have an adverse impact on performance. I am under the gun to solve this by year's end when we turn on Xe! Any help/advice will be greatly appreciated. Thanks
 
Sounds like you have the same exact need as we do and getting the same "NO CAN DO" answer from JDE.
They flat out told me this is NOT supported. No, they won't tell me why other than it will cause problems with some applications. Basically I don't think they have a good solution for us. We are still undecided on OneWorld this could be the reason NOT to implement it.
Colin Dawes above sounded like he had implemented *ALL using inclusive security but he had not confirmed. I sure would like to hear from him and other people who have implemented this method of security and been successful or NOT!..
I am new to JDE and wonder how all those World customers migrated their BU security over to OW?
Appreciate ANY input good or bad...
THANKS.
Soyer.
 
Ahhh........ I finally understand what you're asking (sorry for the
confusion). The answer is no I don't use *ALL for MCU. Just a refresher,
when you use row security on OneWorld on a data item (in this case Business
Unit ~ CostCenter ~ MCU) you can secure thes items in ONE table at a time or
*ALL tables.

The *ALL option is useful for some Data Items but not others. Often you only
want to limit the selection of data in one particular Application, Report or
area of functionality, not in all applications, all reports or all arreas of
functionality.

In this particular case for Business Unit Security you CAN use *ALL but I
wouldn't, haven't and never will. The reason being is that in the Financial
module there are two key tables that are used by different applications:
F0011 and F0911. These are the only two tables that I have ever used for
Business Unit Security - again I have never used *ALL. If you use *ALL
you'll find that there will be a few necessary actions that users can not
perform because they need to update only one of these tables. My best
recommendation is instead of using *ALL use the F0011 and the F0911 for Data
Item CostCenter ~ MCU. Initially set up security identically on these two
tables. You WILL run into issues where a use has view access to a business
unit but CANNOT inquire or report on a business unit. This is often because
OneWorld writes the audit field when a user JUST looks at a record. If
you've locked out the change function then the audit field cannot be updated
and hence the user has no access. All you have to do to correct the issue is
figure out which of these to tables the use needs change access to - you do
not need to give them add or delete (also remeber you can give them change
without giving them view).

To test what table you need access to log on with debug on. Clear the log
before you perform the function in question. Parse the log for the SQL
statements 'SELECT ' and 'UPDATE ' or 'F0011' and 'F0911'. This tells you
what ocurs under NO security. Now log in as a use with the security
restrictions and repeat the process. Note and difference in the logs. ie, If
the secured user can not perform a function and the log is 'missing' UPDATE
PRDDTA.F0911 then you now know that this user needs CHANGE access on the
F0911 but not necessarily on the F0011.

To save time when you set this up I'd seperate my security tables for PD and
PY. Setup one user/group with F0011 entries. Export the PY table to Access
and then to Excel. Cut and paste the F0011 entries but update the F0011 to
F0911. Cut and paste all the F0011 and F0911 entries to all other
user/groups.

To make life simple I'd strongly suggest you use Inclusive rather than
Exclusive security. Besides being a resource hog Exclusive security can be
an administrative nightmare.

Hope this finally answers your question and let us know how it goes.

Colin




Colin Dawes, Sr. Technical Consultant
Syntax.net
B733.1 to ERP 8.0
Oracle 8i/9i/SQL Server 2K, DB2
 
Guys,
Like I said in my previous e-mail I have done this before - the client
wanted to have access internally by groups to certain BU's but they had
a call center (external company) where they would collect and reconcile
the client monies.

To do this we implemented BU security over the F0006 (BU file) and the
F0901 (account master) file by group. We also worked on the inventory
security for a new product line where we were using the F41001 (branch
plant).

The strategy we used was to secure EVERYTHING and then give access back
through the CRP scripts - i.e. if it doesn't work then grant access.
But this required a signed off script and potentially requires more
work.
To reiterate the previous e-mail we secured out by ranges as at that
time JDE did not work for the inclusive range ( e.g. exclude 1-4, 6-10
NOT allow 5!). I am less than convinced that JDE have addressed this
problem!

This works! The external call center only could access the accounts and
BU's they needed to see but the client staff could see all they were
required too plus the call center accounts.

If your BU structure does not easily fit into this type of security
implementation, then look at using a category code on these files. In
theory this should work equally well.
The "but" is that the CRP scripts would have to be sun through to
confirm that all is OK.

Best regards

Peter

Peter Bannister

1st Consulting Ltd
www.1stconsulting.biz

Mobile : +(44)-7711-649358
 
Colin,

First, thank you so much for sharing your knowledge.
From your answer along with Peter's what I conclude is this:
We can't and will NOT use *ALL when defining Row security for MCU column (perhaps others too). We have to identify which files and define the row security for MCU (BU) for those tables ONLY, not *ALL!...
You are giving me two table names(F0011 and F0911) and Peter gives me three other( F0006 F0901 F41001) table names from his implementation which tells me we need to figure out which tables we need to work with for our environment.
Our business requirement is such that your statement "Often you only
want to limit the selection of data in one particular Application, Report or
area of functionality, not in all applications, all reports or all arreas of
functionality." does not hold true!...In fact that is axactly what we are looking for. So, I thought the use of *ALL would be just perfect. But, now I see that you are confirming what JDE told us which is "DON'T USE *ALL".
I guess the challenge now is to figure out which files to use to do this. If I look at where used for MCU column we have 165 files using this column. I think at this point this will require application expertise not CNC. Unfortunatelly this will be very cumbersome and tedious process with lots of trial and errors (correct me if I am wrong here).
Thanks to all for all your inputs!.. if you have anything to add please do so as this topic will be chalenging lots of other people when they consider migrating their World BU security over to OW.
 
Actually, there are only a small number of master files across the whole
of JDE and an even smaller number that you actually using (due to what
you are implementing e.g. GL, AR, IN etc).

This should NOT be a major task - 1-2 days for a small implementation
(up to say 100 users) depending on the final requirements.

This area is actually largely in the apps area, whereas the network etc
security is wholly in the CNC side.

I hope this helps quantify the scale of the task.

Best regards

Peter

Peter Bannister

1st Consulting Ltd
www.1stconsulting.biz

Mobile : +(44)-7711-649358
 
This situation is unique. It's one that I haven't come across before and I
don't think many other have also. Usually (from my experiences) people want
to secure in one area but not another. In your case you want to secure in
ALL areas. I see no valid reason why this wouldn't work - even though I
wouldn't do it because none of my customers have asked for it. You're right
*ALL would be easier in this circumstance and after reviewing it I think I'd
atleast test it out. The only issues that I do see is securing out the
default company.


Colin



Colin Dawes, Sr. Technical Consultant
Syntax.net
B733.1 to ERP 8.0
Oracle 8i/9i/SQL Server 2K, DB2
 
I have been testing row security for bus unit. You can do it for *ALL, but there could be some side effects. You need to allow users access to common used objects like companies 00000 and 99999 in F0010 or else you will not be able to change any supplier master records.

Are you using job cost module? If so, then it will make the set-up more difficult since your company is constantly adding new bus units.

Look at the previous jdelist posting titled "Security by Company & Business Unit". There is a listing of the main tables that you might want to secure.
 
C Ho, i could not find the post about security by company and business unit. Could you help me find it? TIA
 
Back
Top