Skip to main content
Skip table of contents

Permissions Model - Inheritance and Conflicts

The following is an overview of the SuperSTAR permissions model, explaining how inheritance of permissions works, and what happens if there are conflicts between permissions:

SummaryDescription
Granting dataset access allows full access by defaultBy default, when you give a user access to a dataset, that user can access all dataset components. You need to specifically set permissions at the field level if you want to change that.
You can set permissions for users, groups, and all users

You can set permissions for:

  • Individual users
  • Groups of users
  • All users (this is a built-in group called "allusers"; it applies to all users of the system)
Permissions are inherited in hierarchies

Permissions set at a given level in a hierarchy will be inherited by that level's children.

For example, if you set permissions for a hierarchical field like the following, then any permissions set at level A will be inherited by B and C:

  • A
    • B
      • C
Deny permissions take precedence in hierarchies

If you deny access to a given level in a hierarchy, the user will not be able to access any level below that in the hierarchy.

This applies regardless of any security settings that have been specifically set a lower level in the hierarchy.

For example, in the following hierarchy:

  • A
    • B
      • C

If you deny the user access to level B, that user will not be able to access C, regardless of any other security settings that have been applied to C. 

With conflicting group permissions, deny permissions take precedence

If a user belongs to multiple groups that have conflicting permissions, then if any one of the groups that the user belongs to has specific deny permissions set for a field or dataset, the user will not be able to access that item.

However, if the user belongs to one group that has allow permissions for a field or dataset and belongs to another group where no specific permissions are set for that field or dataset, then the user will be able to access that item.

For example:

If...Then...

myuser belongs to both group1 and group2

group1 has read access to the bank dataset

group2 is denied access to the bank dataset

myuser can not access the bank dataset

myuser belongs to group1 and group2

group1 has read access to the people dataset

group2 has no specific permissions set for the people dataset

myuser can access the people dataset
User permissions override group permissions
  • Permissions set at the user level take precedence over permissions set at group level.
  • Permissions set at group level take precedence over permissions set at the "allusers" level.
Permission overrides are not inherited

If you want to override a permission that is defined at the "allusers" or group level you must explicitly override it at every level in the hierarchy where you want the override to apply.

For example, in the following hierarchy:

  • A
    • B
      • C

If the group permission denies access to B, and you override that permission at the user level for B, then that user will not be able to access C.

To override the group permission and allow the user access to both B and C you would have to explicitly override that permission for that user at both level B and level C.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.