Below are some high level points which should get you started.
The term 'objects' in the title of this article refers to any items you may find on the OrgVue home screen, eg, datasets, reports, filters, branches, etc etc
Further information on how to use Role Based Attribute Control can be found in our tutorial videos:
- Only someone with the Admin role or the owner of a dataset has access to that dataset. For anyone else to access a dataset, specific permissions on that dataset must be set (tagging).
- By adding the role of 'readonly' to the Roles property of a user account, you restrict that account so that it is unable to change any data in the tenant (even if they are an admin, and that includes their own Users dataset node !) (Note however that such a user is still able to download data from OrgVue.)
- Tagging is done using fixed permissions sets: 'view', 'edit' and 'update' are the most common but there are others, such as 'hide'
- 'view' - user can only view the dataset
- 'update' - as 'view' and user can also change values in properties and add new nodes
- 'edit' - as 'update' and user can also edit properties
- 'hide' - tagging properties with 'hide' followed by the role/s will ensure these are not visible to the selected users
- 'private' - hides the object from everyone (including admins) except the owner
- Dataset-level permissions sets must be applied to roles: user and admin are the standard roles but others can be created
- Each dataset should have only one tag of each type, although a permission type can be applied to multiple roles e.g.
- Note that when setting Apply Tag (see screenshot at the end of the article) 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
- Multiple tags will not operate correctly when applied to one dataset e.g.
view:hrbp view:finance view:exec
The following approach is the minimum for a given user (name) to have access:
- Tag the desired dataset with
- Ensure username has an entry in the users table with at least role "user". (Only those with the admin role are able to create/amend users.)
- Now username should have access to the desired dataset, but so will everyone else that is a user in that dataset
Note that in a typical scenario where there are multiple datasets which should not be available to all users, any given individual will need at least two roles - which will be user plus at least one other. (Note also that Admins have unlimited access to all datasets in the tenant.)
Reminder: where people are assigned to two or more roles (permissions groups) which have different access level to the same dataset, the highest level would apply for that individual.
The following is a general example of managing user dataset access using roles (I will invent a new role 'ftb' to demonstrate)
- Ensure username has an entry in the users table with at least role "user".
- Update the role to state "user,ftb" : -
Note that the value separator here is a comma ","
- If I want anyone else to have the ftb role, I can update their record in the user table in the same way
- Update the dataset tag. If I want username to be the only one to make changes, I set the tag as "update:ftb", although if anyone else has the ftb role, they can now make changes
- If I want to let everyone see the dataset but only have username make changes, I set the tag "view:user,update:ftb"