How do I manage complex dataset and property permissions (RBAC)?

An individual (via their role) must have at least view: permissions to access the dataset at all, then any property level permissions will override the dataset permissions at property-specific level,

Permissions: key concepts (troubleshooting)

  • No matter what other roles (permission groups) a user has been given in the ‘Users’ dataset (e.g. hr, superAdmin), they must have at least ‘user’ or ‘admin’ – otherwise they will not be able to access Workspace
  • Users always need to be given explicit permissions to access datasets which they do not own i.e. Admin roles can always access all datasets; the owner/creator of a dataset can always access that; anyone else who requires access needs explicit permission for access set
  • Where lookup datasets are used - for validation, for providing custom colours etc., users need to be able to view lookup datasets: and in that sense lookups are "just another dataset" and will need permissions set, typically view: for non-Admins
  • In practice, some people will  be assigned to two or more roles (permission groups) which have different access level to the same dataset (or property), in which case the highest permission type available will apply to the individuals concerned
  • Each dataset may have only one tag of each type, although a permission type can be applied to multiple roles e.g.
view:hrbp,admin,exec
edit:hrcentral,finance
  • Note that when setting Apply Tag (see screenshot at the end of the section) a different permission type must be set on a different line, but once saved each permission type will appear on the same line separated by ; i.e. the above example will display as
view:hrbp,admin,exec;edit:hrcentral,finance 
  • Multiple tags will not operate correctly when applied to one dataset e.g.
view:hrbp
view:admin
view:exec

 

Tag Types and Application

 

basic permissions setting workflow

There are a range of tags available to customise the behaviour of datasets and properties:

In a basic example, if the dataset permission is set as edit:user and the named property is hidden, then the property will be hidden regardless of the 'edit' permission for anyone with the role 'user'.

There are only two obvious exceptions to that example:

  • if the individual concerned has admin-level rights via the users table
  • property tagging is enabled which always overrides generic property-level security: in the example at the end of this article, the role hrsecure would have edit permissions on the property even though it is set to 'hidden'

 

Tag

Example

Scope

Difficulty

Description

view:<user_role(s)>

view:ops

Dataset

Standard

Listed roles can view the dataset only

update-values:<user_role(s)>

update-values:jgroup

Dataset

Standard

Listed roles can update cell values only i.e. they have to work within the existing structure both in terms of nodes (cannot add or remove nodes) and properties

update:<user_role(s)>

update:hr,finance

Dataset

Standard

Listed roles can update (add/remove) nodes and associated cell values but not properties i.e. they can impact the data values generally but not the data structure

edit:<user_role(s)>

edit:seniorhr

Dataset

Standard

Listed roles can edit nodes, cells and properties i.e. impact both the data values generally and the data structure

fav

 

Dataset

Standard

Put the dataset in the Favourites tab for all users

lookup

 

Dataset

Standard

Flag a dataset outside the Lookups tab as a lookup

template

 

Dataset

Standard

Allow a dataset to be copied from the home screen

survey

 

Dataset

Advanced

Automatically applied by OrgVue to surveys

At dataset level, the owner or Admin can set the level of Users' access to a dataset:

 

RBAC can be implemented at property level within a dataset

  • To limit a user’s access to dataset properties based on role, use the property ‘Security’ options
  • Note: setting a property to ‘Hidden’ will mean that standard users cannot colour by it or use it in any expressions.

 

 

Access

Description

Default

Dataset/ property can be accessed and edited by anyone tagged as “edit:….”

Update only

Cell values can be updated but the structure (e.g. node hierarchy, property settings) cannot

View only Can be seen but not altered in any way
Hidden Cannot be seen by anyone other than admins and the dataset owner

 

OrgVue is cautious by default

 

These are key rules to help you understand how RBAC works between datasets and properties

  • ‘Hidden’/‘Private’ overrules other permissions, i.e., a private dataset is always hidden - a hidden property in a editable dataset is still hidden
  • For non-hidden properties, setting a dataset to ‘View’ overrides any property-level security
  • For non-private datasets, setting a property to ‘View only' or ‘Update only' will restrict access.

The following is an overview of the interaction between dataset and property level permissions:

More granular property permissions are available beyond Security using tags

It is also possible to use tags for specific properties, and the syntax is identical to that set at dataset level i.e. view,edit rights are applied to those roles configured in the User table.

In this way, it is possible to override the per-property Security settings to apply to certain users: grouped by role

In the example below, the Security setting for the property Pension is set to Hidden.  This means that all those individuals with access to the dataset will not see the property or its values based on the Security setting, however those users with the role 'hrsecure' as enabled in the User table will be able to view and edit this property.

 

Access Tag syntax example

Invisible

(none set)

Read only

view: hrgeneral
Update only update:hranalyst
Edit edit:hrsecure

 

 

 

 

 

 

Have more questions? Submit a request

Comments