This is the documentation for SuperSTAR 9.8

SuperSTAR 9.9 is now available.
View this page in the SuperSTAR 9.9 documentation or visit the SuperSTAR 9.9 documentation home.

Skip to end of metadata
Go to start of metadata

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
Default permissions allow full accessBy default, when you give a user access to a database, that user can access all database 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 database, 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 database and belongs to another group where no specific permissions are set for that field or database, 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 database

group2 is denied access to the bank database

myuser can not access the bank database

myuser belongs to group1 and group2

group1 has read access to the people database

group2 has no specific permissions set for the people database

myuser can access the people database
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.