How Permissions are Determined

Since permissions can be associated to a user or a user group, and a user can belong any number of user groups, it is important to understand how permissions are determined at run time on Twinit.

Permissions are Positive and Cumulative

By default a user has no permissions. A user does not have any permissions on Twinit until permissions are either assigned to their user or they are added to a user group to which permissions have been assigned.

Permissions are always Positive; meaning you give the user the permission to perform a given action within a given namespace on a given resource or set of resources. You never specify permissions a user does not have. There are not Negative permissions.

Permissions are Cumulative. If one permission gives the user READ access to a resource, and another permission gives them CREATE access, then they will have both READ and CREATE for that resource.

If a user belongs to three different user groups, and each user group has its own set of permissions assigned to it, then the user, when taking action on Twinit, will take action with the combined set of permissions afforded to the user by their membership to all three user groups.

For example, if a user is member of these three user groups providing these permissions:

User Group 1	User Group 2	User Group 3
READ all NamedUserItems	CREATE all NamedUserItems	DELETE all orchestrators

The users effective permissions when signed in to Twinit will mean they can READ and CREATE all NamedUserItems in the Item Service for the given namespace, and they can delete any and all orchestrators in the Datasources Service for the given namespace.

This can get confusing if you don't plan out the permission model for you application.

Why a Well Planned Permission Model is Important

Twinit's permission paradigm is flexible and powerful. Yet since permissions are cumulative, and permissions can be assigned to both users and user groups, if you do not carefully plan out your permission model, you could create problems for yourself.

It is recommended that you begin assigning permissions by user group or role. This allows for clear designation of permissions based on what the user needs access to on Twinit. It also allows better understanding of how to add users to a project.

Use permissions assigned to individual users sparingly, since it can make it difficult to understand exactly how the user has the permission.

Remember, a user can belong to multiple user groups, so if you need to layer permissions across user groups and then assign users to multiple user groups that is entirely possible. And it makes it very easy to tell where a user is being given any one permission.

Checking if a User Can Perform an Action

In your client code you can check if a user has permission to a given set of resources or action by using:

IafPermission.checkAccess(resourcesDesc, Action, ctx)

For instance, if you wanted to check to see if a user could execute a model import orchestrator, in order to display the appropriate controls in the user interface to import a model, you could use checkAccess like this:

const [ canImport, setCanImport ] = useState(false)
useEffect(() => {
   let checkCanImport = await IafPermission.checkAccess({      irn: 'datasourcesvc:orchestrator:<id of import orchestrator>   }, IafPermission.PermConst.Action.Run, ctx)
   setCanImport(checkCanImport)})

---