Old access roles
Deprecated since platform version 1.16.0
Old access roles
Access to a process definition
You can restrict access to process definitions by user roles. This can be done by setting the desired operation permissions on a process definition.
Start by adding the needed roles in the database. These need to match the roles configured in the identity provider solution. Each role can have one or more permissions defined on it. Permissions can be applied to all users or only to the owner of the specific resource (for example the person that started the process instance).
After saving a new process definition, you can also save specific user roles for it to restrict user access. Access rights can be defined on the following operations that can be performed on a process definition:
- starting a new instance of the process definition
- viewing the instance of that process definition
Here's an example of setting operation permissions for a process definition:
{
"START": ["PROCESS_START"],
"VIEW": ["PROCESS_VIEW", "PROCESS_VIEW_ALL"]
}
where START and VIEW are the possible operations to be performed on the definitions and PROCESS_START, PROCESS_VIEW, PROCESS_VIEW_ALL are permissions stored in the database.
Access to actions from process definitions
Operation permissions can also be set on specific nodes in order to restrict the access to the actions defined on that node. This can be done similarly to setting operation permissions on process definitions. The operation name to be used for nodes is NODE_RUN.
As nodes also hold the definitions for the user interface, deciding which user role can see a certain UI template can also be done by using node permissions. The templates linked to a node can only be viewed by a user that has the NODE_RUN permission on that node, if the access on that node is restricted.
Access to a process definition
You can restrict access to process definitions by user roles. This can be done by setting the desired operation permissions on a process definition.
Start by adding the needed roles in the database. These need to match the roles configured in the identity provider solution. Each role can have one or more permissions defined on it. Permissions can be applied to all users or only to the owner of the specific resource (for example the person that started the process instance).
After saving a new process definition, you can also save specific user roles for it to restrict user access.
Access rights can be defined on the following operations that can be performed on a process definition:
- starting a new instance of the process definition
- viewing the instance of that process definition
Here's an example of setting operation permissions for a process definition:
{
"START": ["PROCESS_START"],
"VIEW": ["PROCESS_VIEW", "PROCESS_VIEW_ALL"]
}
where START and VIEW are the possible operations to be performed on the definitions and PROCESS_START, PROCESS_VIEW, PROCESS_VIEW_ALL are permissions stored in the database.
Access to actions from process definitions
Operation permissions can also be set on specific nodes in order to restrict the access to the actions defined on that node. This can be done similarly to setting operation permissions on process definitions. The operation name to be used for nodes is NODE_RUN.
As nodes also hold the definitions for the user interface, deciding which user role can see a certain UI template can also be done by using node permissions. The templates linked to a node can only be viewed by a user that has the NODE_RUN permission on that node, if the access on that node is restricted.