spiff-arena/docs/installation_integration/admin_and_permissions.md

Admin and Permissions

Permissions can be defined and managed at different levels such as process groups, individual processes or users.

Setting up Admin in Config (YAML)

In order to initiate the creation of a process model, it is necessary to configure the terraform_deployed_environment.yml file by including at least one Admin user.

Git Repository - Config file

groups:
  admin:
    users: [admin@spiffworkflow.org]

permissions:
  admin:
    groups: [admin]
    allowed_permissions: [create, read, update, delete]
    uri: /*

:class: info

The "uri" field defines the target resource for these permissions, which is set to "/*". This indicates that the permissions apply to all resources within the system.

Groups

The "groups" section defines a group called "admin." This group is intended for users who have administrative privileges within the system. In this example, the "admin" group consists of a single user with the associated email address. Multiple groups can be added.

Permissions

The "permissions" section specifies the permissions and access control rules for the "admin" group. The "admin" permission set allows members of the "admin" group to perform actions such as create, read, update, start and delete or all. The "allowed_permissions" field lists the specific actions that are permitted for the "admin" group.

Permissions allowed:

• create

• read

• update

• delete

• start

• all

Site Administration

Once the basic configuration setup is completed, specifying admin rights, you generally won't require additional permissions for designing processes and using the site. However, there might be certain situations that call for access control beyond the site or group level. In such cases, you have the flexibility to define and tailor admin requirements in a more detailed manner to fulfill specific needs.

Step 1: Create Process Group

From the main menu select 'Procesess' and click on the 'Add a process group' button.

Complete the Process Groups form, by entering the

• Name (ensuring it reflects admin and permissions)
• Identifier (which must be unique)
• Description.

Once the required fields are filled, the form can be submitted.

The new Process Groups tile will be available under the Process Groups view.

Step 2: Add Process Model

• Select 'Add a process model' and complete the following form fields:
• Name: Provide a descriptive name for the process model.
• Identifier: Enter a unique identifier for the process model.
• Description: Provide a brief description of the process model, outlining its purpose or functionality.
• Notification Type: Specify the type of notification related to the process model.
• Notification Address: Enter the address or destination where the notification should be sent.
• Metadata Extraction Path: Specify the key and path or location where metadata extraction should occur within the process model.

Make sure to accurately fill in all the required fields in the Process Model form to ensure proper configuration and functionality.

Step 3: Upload Workflows

All the required workflows can be downloaded from Github - set-permissions

Select to upload all downloaded files to the newly created Process model.

Upload the following files permissions.bpmn - Primary file groups_permissions.dmn users_to_groups.dmn

the Process Model view should now include all uploaded files.

Step 4: Understand the Process Models

Read more about DMN tables and how they work here.

Users to Groups

Assess the roles and responsibilities of users within your organization or system. Look for common patterns or similarities in their job functions and tasks related to specific processes or process groups.

Add a user email under the users 'column' and the group name under 'groups' and dont forget to add double quotes.

Based on DMN functionality, leaving the "*" column empty means that all rules ('When') will be triggered without specifyin a condition. Read more about DMN tables to understand how the rules engine can be utilized for many different scenarios.

Group Permission

Now that the groups have been identified their permissions can be set by adding the group name under the "permissions_group" column.

• To determine a user's capabilities within the permissible scope, you can define specific permissions. These permissions can be combined in a sequence if multiple apply to a particular rule. For instance, ["read", "start"] indicates that the user can perform both reading and starting actions. Alternatively, [All] can be employed to grant unrestricted access.
• The hit policy is set to "Collect" which means that all conditions that are true will be applied. Read more about DMN tables and hit policies here.
• The permission URL can be configured to define the user's access privileges. Our objective is to streamline the process by minimizing the necessity of being familiar with the complete set of permission URLs. In most instances, utilizing BASIC and ELEVATED permissions, as well as PM/PG, should be sufficient. However, it is also feasible to directly incorporate any API URL into the permissions.

In truth what you are doing is writing an expression. In this case it would read that if the variable 'permissions_group' type string is equal to 'permissions' variable of type string then set the 'permission_url' equal to the associated value.

If you find coding more familiar and preferable to constructing DMN tables, you may notice similarities between this DMN table and the shared permission configuration file. This similarity can help clarify or make it easier for you to understand the DMN table structure and its relation to the permission configuration. 

Step 5: Start Process

To ensure that User Groups and Permissions take effect, it is necessary to run the process at least once. Whenever changes are made to any of these diagrams, like adding a user group or permission, the process should be started and completed successfully in order for the changes to be applied.