This content has been marked as final. Show 6 replies
What role(s) do the users have? Any user with the Administrator role bypasses class access checking and is assumed to have full access to everything. No other role provides this bypass.
Editing forms and grids has nothing to do with Entity security. If the forms and grids have no class assigned to them, they use the [Default] class which I suggest all users have All rights to anyway. If there are grids/forms you do not want users to change, you should assign a specific class to them, other than [Default].
Enable Metadata security filtering should restrict users from seeing the members for which they have None access to, but as long as they have Read or All access, they will see the members in a pick list.
No, the users do not have an admin role, but only one of the basic roles such as 'Data form writeback to excel' or 'Default ' assigned. Also, yes, our forms and grids too have a seperate security class attached to them which the user doesnt have access to, but he can still see all those forms and grids, and also all the entities while selecting one. On top of that the user can also go into the Form designer and edit it.
On doing some more R&D, i observed that even if my user is provisioned to only CONSOL1 application, he can access even CONSO2, 3 and other applications via the Navigate -> Applications -> Consolidation menu and can even open forms and grids in the application. It seems that there is no security restriction on the user even across applications
It sounds like your user could be part of a group that has roles beyond what you think he should have. You can run a security report from Shared Services that shows the roles which the user has both directly and inherited. In Shared Services select:
Administration > View Report
Show Effective Roles = Yes
Shows what users inherit from group membership
Look through the list and you can see if the user is a member of another group that has rights that you may not be aware of.
Thanks Chris, but we discovered what the issue was. Somehow, for each application (even new ones which we created for testing the issue), the WORLD user group was automatically getting administrator provisioning for the applications.
Don't know why and how this was happening, but removing the provisioning for the WORLD group resolved the issue :)