Permissions modelSWEAGLE applies a "policy" driven permissions model. Policies are used to define if a user is allowed to perform a particular task and if configData items are visible and can be managed. Users, roles, and policies Policies are assigned to roles, roles are assigned to users. All relations are "many to many", so 1 policy can be assigned to multiple roles, and 1 role can have multiple policies. Same for users to roles model. In case a user is assigned with multiple policies for the same item, SWEAGLE will apply the most permissive policy. Policies explained Policies are a way to define what permissions a user has to view, edit, change, approve etc along the data model. Built-in policies Super user policies The admin, edit, and read policy are standard "generic" policies. When assigned they provide the user with those permissions across ALL dimensions. Use these built-in policies for "super users" only as they overwrite any of the other policies. These policies cannot be removed. Generic policies There are a few additional policies that give users more capabilities above and beyond their data path & tag access. parser admin policy allowing specific users to create and publish new versions of parsers (exporters, validators, and templates) content admin policy allowing specific users to manage the available node types and CDI types. approve and store change sets allowing specific users to apply incoming changes to the data model and store snapshots. Admin policies There are various admin policies available such as user admin (for local users), roles & permissions admin and system preferences admin Data path access policy Allows defining if a user has view or edit permissions to a certain node in the data model. When a user has a data access policy (read or write) for a given node somewhere in the data model, then the user will have EDIT permissions only to that specific node. The user can see other nodes of the staticTree but won't be able to access their data. As an example, if a user receives EDIT permission for the PRD1 node, then the user receives edit permissions for the "PRD1" edit permissions for any of the child nodes below "PRD1"no VIEW permissions on the CDIs of other nodes including sibling nodes such as PRD2, user gets a "ACCESS DENIED" message Data tag access policy Data Tag Access Policies help to further refine which CDI's a user can see and/or edit. When a Data Tag Access policy is defined for a tag, only users explicitly having that policy will be able to view and/or edit CDI's flagged with that tag, regardless of any other policies the user might hold (apart from the built-in admin). If no policies are defined for a tag, than the usual read/edit/Data Path Access policies apply. For CDI's without any TAGS assigned --> the "node" permissions are applied: a user with EDIT permissions for that node can edit all CDI's without TAGS on that nodea user with VIEW permissions for that node can see all CDI's without TAGS on that node For CDI's with a TAG but for which no Data Tag Access policy is defined in the system --> the "node" permissions are applied: a user with edit access to the node where the tagged CDI is defined will also be able to edit the tagged CDIa user with edit access to the node where the tagged CDI is defined will also be able to edit the tagged CDI for CDI's with a TAG assigned for which a Data Tag Access policy is defined --> Data Tag Access permissions are applied: a user needs to have that explicit "edit" Data Tag Access Policy added to its role(s) in order to edit the tagged CDI's.a user needs to have the explicit "view" Data Tag Access Policy added to its role(s) in order to see the tagged CDI's. Policy hierarchy The policies based permissions model applies a "most permissive logic". In case a user has both a VIEW and EDIT permission for the same node or CDI, then the EDIT will be allowed. Following the logic of "most permissive logic", the "built-in" policies are by default across all data paths and therefore a user with the built-in "READ policy" can view all data everywhere. Even when there are specific data path access policies in place. Most permissive logic means that SWEAGLE applies the following order in defining the permissions for a given node or CDI does the user have one of the built-in policies? If yes, apply that policy. does the user have access to the node based on a Data Path Access policy? If yes, apply that logic Are there TAG policies in place? If yes, check if the user has VIEW or EDIT policy for the CDI with specific TAGS. Based upon this hierarchy, TAG policies are only applied on the condition that the user has access to the node to which the CDIs are assigned.