Tips & Tricks

Restricting access to parts of configuration

Hyperon Studio is made not only for the development phase but also a useful tool in maintenance. Considering all possible kinds of users administrator of the system may need to control access to parts of the configuration. For that purpose, we suggest using selected roles and/or tags with access control. 

In this article, our focus will be to understand how those functionalities work and how to combine them to achieve any expected effect.


How to restrict access within Hyperon Studio

There are two tools allowing you to restrict access within Hyperon Studio: one is assigning users roles with appropriate restrictions, the second is assigning elements tags with access control and assigning privileges to see that tag only to selected users. The default roles in Hyperon Studio are MPP_ADMIN, MPP_USER, MPP_READONLY, and HYPERON_SUPERPACK_IMPORT. One thing you have to know is what each role can do in Hyperon Studio. 


Role's simple characteristic

MPP_ADMIN - user role with full access to Hyperon, this role allows making any change in the configuration, creating new profiles, and even managing other roles and users. Admin role allows seeing all elements of the structure (even those with access control tags) and make changes to the full extent of the environment's internal configuration.

MPP_USER -  this role allows to make changes in configuration, add new elements to the domain (in Domain Configuration), create, edit parameters and functions. User with this role has no access to Domain Definition, therefore, is not able to make significant changes in the structure of the domain. Nevertheless is able to add new elements to existing domain structure and change attributes values as needed. This role has no default access to elements (parameters, functions, and domain elements) labeled with access-controlled tags. This user has no access to environment settings (including accessing users' accounts, roles, and grants, creating profiles, regions, and versions ).

MPP_READONLY - gives a user the ability to view all the configuration but with no possibility to in any way edit data, since this role doesn't allow to change the configuration, the user is not able to open nor publish a session.

HYPERON_SUPERPACK_IMPORT - gives the user the ability to view the whole configuration with parameters and function furthermore user can import a superpack and publish imported changes. So this role is basically MPP_READONLY plus import superpack privileges.

Below you will find description of all default roles. The following analysis includes the possibility of assigning tags with access control to selected elements. If "access control is considered" is checked it means that the user with that role can only view and/or make modifications to elements within his perspective. Symbol "-" means that the selected role's abilities are not impacted by labeling elements with access-controlled tags.

module
action
MPP_ADMIN
MPP_USER
MPP_USER_READONLY
HYPERON_SUPERPACK_IMPORT
Profile
access control is considered
-
true
-
-
view
true
true
true
true
edit
true
false
false
false
Context
view
true
true
true
true
edit
true
false
false
false
Domain Definition
view
true
true
true
true
edit
true
false
false
false
Domain Configuration
access control is considered
-
true
-
-
view
true
true
true
true
edit
true
true
fase
fase
Parameters & Functions
access control is considered
-
true
-
-
view
true
true
true
true
edit
true
true
false
false
Superpack
export
true
true
true
true
import
true
true
false
true
Snapshot
export
true
true
true
true
import
true
true
false
false
Versioning
view
true
false
true
true
edit
true
false
false
false
Testing modules
available
true
true
true
true


Tags with access control

All about how to create a tag is described in the User Guide. When we focus on tags with access control the most important thing to remember is: every tag with access control comes with a set of two grants: 

  • PAR_R_CAT_tagName  allows to - "READ" - view elements labeled with mentioned, in the grant's code, tag
  • PAR_W_CAT_tagName allows to  - "WRITE" - assign/remove the tag and edit elements labeled with mentioned, in the grant's code, tag

As you probably know first can work without the second but second without the first comes with no benefit, because we cannot overwrite an element we are not able to view. Well, the exception here would be importing file with changes on the element, which would overwrite the old state of the element, but the user still would no be able to view the updated element.