Table Security versus application and form Security

Wally28

Member
Hi JDElisters,

I need your expert advise, do you know if there are hierarchy in security settings? Like table security will prevail over application and form security?

First Scenario:
I have an role ROLE101 and these role contains application P0801CMP and form W0801CMPB, P0801CMP, form W0801CMP can update Pay Grade and Salary. P0801CMPB is using table F060116 (Data Item SAL and PGRD)

Then I applied column security (view=Y, Add=Y, change=Y) to ROLE101, table F060116 and data item EEOM, CBT, FOA#, SSN when I applied column security, Pay grade (data item PGRD) and Salary (Data Item SAL) was not appearing in W0801CMP and seems like it was blocked already.

Is this possible? Why does SAL and PGRD fields are not appearing even if I didn’t touch it or apply a column security on it? I only applied Y setting to EEOM, CBT, FOA# and SSN not to PGRD and SAL data item? Are they related or it recognizes the security settings applied in table level versus application, form level?



Second scenario:

This time there is an existing security setting applied to P055011 to update banking field (Data Item CBNK) under ROLE101, P055011 uses table F0030. Then I applied column security (view=Y,add=Y, change=Y) to ROLE101, table F0030 with data item CBNK. So in this case. Table and application permissions are both set up to CTOP101.

Now I can’t see the CBNK in P055011, is that possible? I even give Y setting to this data item in table, why is that it is now appearing now? Table and application security are conflicting with each other?


Thanks

Walter
 
Hi Walter,

Here is an extract from a document of ours (please also see attachment):

Column Security: Secures Columns in Reports (UBEs) and Interactive Applications. Has three possible values which are View (column is visible, or not), Change (data in Column can be modified), Add (data can be added to Column).
This Security can either be set at the Table level, or on an individual Application (Batch or Interactive), and *ALL is valid for both options, and which level is identified from the FunctionCodeOpenSystems Column. The Security hierarchy is as described in the diagram attached, but in this case Application level overrides Table Level, and *ALL on Table and Application is overridden by individual object name entry."

Thanks,
 

Attachments

  • 161905-Roles Hierarchy in 8.9+.jpg
    161905-Roles Hierarchy in 8.9+.jpg
    182 KB · Views: 119
Hi Lewis,

My question here is why does other data items are affected by column security you applied even if you didn't included that data item? in this example I applied column security (view=Y, Add=Y, change=Y) to ROLE101, table F060116 and data item EEOM, CBT, FOA#, SSN , when i applied these settings to table F060116, data item PGRD and SAL in F060116 were affected. Is there a way to check the realationship o data items? I'm guessing that these data items (EEOM, CBT, FOA#, SSN ) are related to PGRD and SAL. The other thing that i'm concern about is the setting of that I applied are YYY so i din't block it but give it but then PGRD and SAL data items are affected.

Thanks,

Walter
 
Hi Walter,

Program security overrides table security which is applied at the database level only. Give a ring if you would like more advice.
 
Back
Top