This documentation only applies to v1.x.y
Access to features and products is controlled through product ownership, permissions, roles and custom workflow permissions.
Roles & Permissions
Ultimately permissions control access to features within IriusRisk. Permissions can be grouped together into Roles. IriusRisk includes a default set of roles that can be modified or deleted. Conceptually, permissions are grouped into Product Permissions and Global Permissions. Product Permissions grant or revoke access to features within a given product, for example accepting risk, updating the product details or answering the questionnaire. Global Permissions grant or revoke access to features not related to specific products, for example adding users, editing templates or managing access controls. In addition to this conceptual difference, Product Permissions can also be overridden using workflow permissions.
Roles and permissions are defined on the Roles tab:
Product Ownership
The Global Permission "PRODUCTS_LIST_ALL" grants the user access to all products on the system. Without this permission the user only has access to products within their own business unit. In addition to this default behaviour, both individual users and business units can be assigned to any product from the Ownership tab on the product details pane.
Workflow Permissions
Product ownership determines whether a given user has access to a product and Product Permissions control which operations the user can perform on the given product. Workflow permissions allow you to set custom permissions based on the workflow state of the product. Custom permissions can be set from the Workflow tab and are defined on each workflow state:
In the example above, the workflow state "started" and "approved" both use the default Product Permissions defined on the Roles tab. The "reviewed" state has a custom set of permissions which override the default permissions when the product moves into this workflow state. An example use case for this would be to allow the development team to answer the questionnaires and update the architecture during one state, but then prevent the team from modifying the architecture when the product has moved into the next state.
Comments
0 comments
Please sign in to leave a comment.