Hi Shaik
This is not a simple to determine. Yes it is technical to map user through to org value by tables:
- AGR_USERS is user to roles but the user might have composite roles (could exclude them) based on the role type and confirm with AGR_AGRS table)
- AGR_1252 - Org Values
- AGR_1251 - Obtain the Org Fields where inheritance may be broken
The problem with joining these two tables is that organisational values depend entirely on the authorisation they are part of. Really the join is AGR_1251 to AGR_1252 to include that context.
What it means when you remove the authorisation is that you are getting all potential org values the user has but not how they are restricted. This means you might have situations such as:
- Display all data roles - asterisk or all potential values entered in the role
- Modify roles (posting/master data) - limit to specific org values
- Potentially broken inheritance (you'll need the AGR_1251 table for that)
- Modify roles that are not restricted on a specific org value that other roles would
And I'm sure I haven't covered all the scenarios. But what will happen is they will all be merged together and you'll lose the context in your analysis of how much access to the org data the user truly has.
The examples I list are potential situations if you mention the need to rebuild security. If you are at the stage of performing a massive clean up and rationalising design then there is a good chance you will have other technical issues in the build the further skews your analysis.
If you had managed to use a role convention and build and provisioning rules to limit users to certain areas of the business, then you might be able to rely on this analysis to an extent.
Regards
Colleen