Anyone else on Inclusive Row security?

[joshlitt]

We just went live on 9.0 coming from XE. We went from Exclusive security with groups and menus to Inclusive with Roles of course. My problem is every department is split up into Business Units, ie. my department is 219, whereas another department would be 232 for example. In Exclusive we did a *ALL - CostCenter - A thru 218 and then a *ALL - CostCenter 220 thru 9999999999.

My problem with Inclusive is we grant access to 219 thru 219 on the MCU like we always had and now we had all kinds of errors and basically had to grant table access on way more than they need. I guess I am at a loss as to why *ALL doesn't really mean *ALL? I would think that would encompass all tables and grant the access they need. Documentation on Inclusive Row security is lacking to say the least, but I am ready to pull my hair out on it already.

If anyone has any insight, I would love to hear it.

 

[jjanowski]

PS add the Row security at user level - Not embedded into Roles… Build staging roles holding definitions for re-usable locations. Then just copy and paste…

 

[jjanowski]

INCLUSIVE is 100000X better in the long run and will simplify maintenance and make SOX easier…

You need to include the following records for your example:
*ALL MCU = from 219 thru 219
*ALL CO = from 219 thru 219
*ALL MCU = from ALL thru ALL (Hard coded JDE thang)
*ALL CO = from ALL thru ALL (Hard coded JDE thang)
*ALL MCU = from *BLANKS thru *BLANKS (just trust me, SQL thang)
*ALL CO = from *BLANKS thru *BLANKS (just trust me, SQL thang)

 

[Joel]

We have inclusive row security at a customer site and use MCU security extensively. Keep in mind that when you use row security on MCU, it may first check what companies the role has access to. Then find the corresponsing MCU's for those CO's and then check the MCU's the role has access to from against the list generated by the previous step.

 

[joshlitt]

Jjanowski,

Thanks for your suggestion, we don't have any security on the CO, but adding the other two on the MCU for ALL-ALL and BLANKS-BLANKS looks like it did the trick. Do you normally handle someone with All cost centers the same way minus the one line for a specific or do you add in a *BLANKS to 9999999999?

 

[Luke Phillips]

We always recommend inclusive because its easier to maintain and can help performance.

As John explained, *BLANKS is also a variable (which we needed to allow for so our row security role merging program works correctly). If anyone wants one I have a document which can explain row security and the inclusive/exclusive options available.

 

[jjanowski]

Requiring all cost center access is the easiest. No row security attached delivers all access.

Remember this is how it works: (Example Roles A, B, C and Plants 1, 2, 3)
Exclusive:
- For user1 needing role B plant 2 setup role relationship to standard B and exclude plants 1 and 3
- For user2 needing role C plant 1,3 setup role relationship to standard C and exclude plants 2

Inclusive:
- For user1 needing role B plant 2 setup role relationship to standard B and include plants 2
- For user2 needing role C plant 1,3 setup role relationship to standard C and include plants 1,3

Usually the model is MUCH more complex then A,B,C and 1,2,3 which quickly highlights WHY using Inclusive is better. When your model incorporates a much bigger landscape (legal entities, profit centers, cost centers/business units) the complexity GROWS dramatically. It becomes much easier to include what is needed vs. exclude what is not.

Perform you row security at the user level using row security templates like I am suggesting ((TRUS ME)) and keep your roles standard then you can thank me later on…

 

[Alex_Pastuhov]

Is it actually "ALL", not the usual "*ALL"?

 

[jjanowski]

*ALL for object names/Tables. ‘ALL’ for From Thru values on MCU. ALL is a JDE hard coded value and does not mean ALL in the normal sense.

 

[Alex_Pastuhov]

Ok, thanks, I didn't know this.

Can you explain what the ALL & *BLANKS actually mean?

I assume these are not _only_ available for MCU security, the same values can probably be used anywhere in the row security setup, right?

 

[jjanowski]

Hi Alex, If using *ALL for objects (includes all current and future MCU tables) you need ALL for MCU from/thru because ALL is hard coded inside JDE. *BLANKS is just for the blank values. I don’t remember which tables exactly, it has been a while. You could always SQL the MCU table list from the cross reference.

I guess you could use them for other setups. Every row security framework I have done is wrapped around MCU and CO with a bit of exclusive (type 9) security. Once you start using inclusive Row(Type 4) Security, you probably will need to use Exclusive application (Type 9) security to prevent restrictions on certain programs like R09801. This is a separate security type without a global inclusive/exclusive setting. I anticipate this question might be coming next from this discussion as most people have no idea what type 9 is for and how it is used...

 

[Alex_Pastuhov]

Thanks, but I've tried it every-which way without JDE ever honouring it ;-(

In EXCLUSIVE mode it plainly ignores it. And in INCLUSIVE, it treats ALL as a literal value, with padding and everything.

Does this need any additional setup, like do you have to enable BU security first, or something?

I was testing this in E900/TR8984 with F4211 as a Guinea pig - it has an MCU column in it. But that should not matter - if it works, it should work with any table.

Oh, yes, I did enter "CostCenter" in the data item field of the security table. And it was a row security type 4. Maybe I needed to leave this field blank

What am I missing?

 

[CNC_Person]

Hi, I'm not sure if anyone has mentioned this, but have you also checked the data dictionary on the item to make sure it has row security checked?
Have a good day!

 

[jjanowski]

Did you make sure the global setting is inclusive? Exclusive is default.

 

[Alex_Pastuhov]

Yes, I did. And I did see that this security is ignored for EXCLUSIVE.

But what I see here with INCLUSIVE is that "ALL" is passed into SQL as a value, literally, as in: "WHERE xxx BETWEEN ' ALL' AND ' ALL'", which does not seem normal...

 

[jjanowski]

Alex, this is exactly what is required for it to work correctly... Why i said "ALL is a JDE hard coded value and does not mean ALL in the normal sense"

 

[Luke Phillips]

In a nutshell inclusive uses the view = Y and exclusive uses the view = N records

 

[BPConnor]

JOhn, a great and very effective illustration of the row security modes.
Remember that in AllOut when you are in Inclusive mode, you can create roles for row security and then combine them using role relationships just like any application security role and allout handles merging them together. This way you don't need the row security at the user level.