Roles and Permissions
Components perform some kind of work and that work is configured using Component Configurations. For example, a Component that fetches products from a Commerce backend may have a Component Configuration that specifies: 1) a list of product codes to fetch and 2) a product catalog id to fetch the products from. We refer to each of these configurations as a Component Configuration Property. In this example, the Component has two Component Configuration Properties: 1) Product Code List and 2) Catalog ID. Further, we will assume that this Component allows the Product Code List to be configured at the Component Rule-level.
When this Component is being configured, the Power User is able to configure all available Component Configuration Properties (i.e. Product Code List and Catalog ID). If the Power User allows rules to be defined for this Component, Business Users will be able to specify the Product Code List for each Component Rule which will override Product Code List specified at the Component level. However, Business User will not be able to configure the Catalog ID for each rule that uses this Component. This is because the Catalog ID is not configurable at the Component Rule-level.
There may be times when the business user needs to configure the Component to perform different work based on some context. For example, the business user may want to fetch a different list of products based on the customer's country. This is where Component Rule-level Configurations come in.
There are three types of Roles in the DX Engine:
- Power User
- Business User
- Query User
Conscia's DX Engine provides a Role-based Access Control (RBAC) system that allows you to control what each Role can do in the DX Engine. This includes what resources each Role can access and what operations each Role can perform on those resources. For example, you can create a Role that can only read Environments and another Role that can create, update and remove Environments.
While there are several Roles in the DX Engine, generally speaking, there are three types of two types of users that will use the DX Engine:
- Power Users - These are technical users that will configure the DX Engine to orchestrate the necessary logic. They will create Environments, Components, Component Rules, etc.
- Business Users - These are the users that will use the DX Engine to configure Component Rules for based on the Power Users' configurations.
Resources
The following resources are used when specifying permissions for a Role in the DX Engine:
| Resource | Description |
|---|---|
| Environment | An Environment contains all resources. |
| Component Tag | Components may have zero, one or more Component Tags that can be used to logically group of Components. |
| Component Rule Tag | Individual Component Rules may have Component Rule Tags that can be used to logically group of Component Rules. |
The full list of resource hierarchy is as follows:
Roles
| Name | Resource(s) | Permission |
|---|---|---|
| engineCustomerEditor | N/A | Create, update and remove any resource under the specified Customer. |
| engineCustomerReader | N/A | Read any resource under the specified Customer. |
| engineEnvironmentAdmin | N/A | Create, update and remove Environments. Create, update and remove any resource under the specified Environment(s). |
| engineEnvironmentEditor | Environment(s) | Update the specified Environment(s). Create, update and remove any resource under the specified Environment(s). |
| engineEnvironmentReader | Environment(s) | Read the specified Environment(s). Read any resource under the specified Environment(s). |
| engineComponentAdmin | Environment(s), Component Tag(s) | Within the specified Environment(s), create, update and remove Components and fully manage those Components' Rules. Those Component's must belong to one of the specified Component Tags. For any accessible Component, rules can created, updated and removed. |
| engineComponentEditor | Environment(s), Component Tag(s), Component Tag(s) | Within the specified Environment(s), update any Component that has one of the specified Component Tags. For any accessible Component, rules can created, updated and removed. |
| engineComponentReader | Environment(s), Component Tag(s) | Within the specified Environment(s), read any Component that has one of the specified Component Tags. Rules can be read but not altered. |
| engineComponentRuleAdmin | Environment(s), Component Tag(s), Component Rule Tag(s) | Within the specified Environment(s) and Component(s), create, update and remove Component Rules that have one of the specified Component Rule Tags. |
| engineComponentRuleEditor | Environment(s), Component Tag(s), Component Rule Tag(s) | Within the specified Environment(s) and Component(s), update any Component Rule that has one of the specified Component Rule Tags. |
| engineComponentRuleReader | Environment(s), Component Tag(s), Component Rule Tag(s) | Within the specified Environment(s) and Component(s), read any Component Rule that has one of the specified Component Rule Tags. |
| engineComponentRuleExperienceEditor | Environment(s), Component Tag(s), Component Rule Tag(s) | Within the specified Environment(s) and Component(s), update the Rule-level Configuration for Component Rules that have one of the specified Component Rule Tags. |
| engineQuery | Environment(s) | Query |