The permission system in FireStart works as follows:
- Process Portal and Client use the same permissions.
- By default, a user has no permissions, which means they don't see any models or workflows.
- Denials overrule permissions. For example, if you authorize a user for scope A and in addition to that, you deny sub-scope B, then the user will only see models directly under A but won't have access to the sub-scope B.
- You cannot set permissions for tasks. If a user wants to participate no permissions have to be set. Who receives the task can be configured in the process itself by assigning a user in charge or roles.
Permissions can be set by the administrator of the FireStart Client. You can find the Permission Settings in Menu - Preferences, and there you choose Permissions.
The following can be displayed here:
- Image
- Name
- Login Name
- Permissions
Now you have to click Add so that the dialog for creating a user permission opens.
After that, you switch to the Permissions tab and with a click on Scope Allow Permission, you can choose for which scope you want to permit the user.
Note that the scopes are split by the designers. If you have scopes with the same name, be careful to choose the scope within the intended designer.
With a click on the OK Button, the wizard closes, and you have an entry in Permissions. The default permission is Read Published, but with a click on the entry, you can modify the default value. Permission levels and optional permissions can be selected to your likes in the pop-up.
Sometimes it might also be important that a user can see the process but should not have access to the executions. In that case, the Viewable executions drop-down can be used.
- View no executions: the user does not see any workflow instances
- Started by user: the user can view all workflows he started. If the workflow is started via service call/event or the name changes, the user might not be recognized as the current user and therefore does not have access to the workflow.
- All permitted: the workflow inherits permissions of the model, so the user can view all workflow instances of processes he has access to.
After you finished click Apply to save changes and then Close the dialog.
The permission entry has been made. But with a double-click, the granted permissions can be changed at any time. The moment the permission is displayed, the user gains the right for writing.