Privileges in WEBCON BPS 2019 Standalone (Part 3)

Introduction

In previous articles, individual types of permissions at the application layer were discussed and tested. This time, we’ll look at data level permissions. As part of the applications created in WEBCON PBS, there will definitely be different roles for individual groups of employees. Therefore, WEBCON BPS allows the granting of different types of rights at different levels of generality.

Types of privileges

Within WEBCON BPS we can distinguish 5 types of rights:

• Read only (can’t view attachments) – Privilege thata llow access to all elements of the process with read-only restrictions. The user cannot edit the data on the form. In addition, he does not see attachments. A user with such privilege is able to see these workflow instances in the reports
• Read only – Privilege is analogous to the above, except that attachments can be viewed
• Modification (can’t delete) – With these privileges, the user has the right to modify all elements (regardless of the step they are in). The user also sees the paths, but if they are not configured differently, they do not end tasks for currently assigned people
• Launch new workflow instances – These privilege allow the user to register new workflow items. Thanks to this, a person also sees the buttons used to start a given workflow.
• Administration – The highest possible level of permissions. A user with such privileges can:
  • Start all associated workflow elements
  • Delete registered workflow elements
  • See technical attributes
  • Edit workflow elements regardless of the step they are in
  • Complete the tasks of currently assigned people
  • Edit all visible attributes on the form (even those for read-only, and technical form fields)
  • View the full history of the document (along with technical form fields and full logs of the action)
  • Check and modify privileges for a specific workflow element
  • Delegate tasks for the given item

Permission levels

Privileges can be granted at many levels – on a process level, workflow-form type association or for a single instance of a workflow. Permissions can be assigned to individual users or groups of people. It also can be assigned in the context of belonging to individual entiti in a company.

Please note that final user privilages are the sum of permissions granted.

Privileges for the process

Granting privileges at this level means that they will apply to all types of forms and workflows created int his process. It should also be remembered that the rights granted at this level are permanent (they cannot be removed with the “Remove privileges” action).

Permissions can also be narrowed down to items registered in the context of business entities created in the system. If there are at least 2, a separate tab will be available for each of them in which you can define the appropriate permissions. The “General” section defines permissions for all companies. Bookmarks are available in the process level configuration and document connection to the workflow.

For example, people in the “Launch new workflow instances” field can start all workflows (with any for type) configured in this process, regardless of the configuration of privileges at other levels. However, they will not have read access to the other instances of the process except those registered by themselves.

Privileges on associated form types

At this level, the privileges granted are limited to associated form types with the workflow. The “Associated forms types” tab in the workflow configuration is intended for their management. On the left there is a list with all document types defined within the process. A ticked checkbox means that the type is associated with the workflow. You can define permissions for each of them separately.

For example, giving access to all workflow instances and attachments permissions for a specific group of people will allow access to all instances of the workflow, but restricted only to the indicated type of form (in this particular case above only Management group may see Confidential documents).

Workflow instance privileges

Privileges at this level apply to one workflow instance and are granted during its processing. Examples of permissions at this level are:

• Read-only privileges after registering an item for the author of a workflow instance
• Privileges granted to the person receiving the task (first for modification and after its execution – for reading)
• Privileges granted by “Add privileges” action

These rights can be modified by people with administrative rights.

“Add privileges” & “Remove privileges” actions

There are actions used to manage permissions. Thanks to them, you can grant privileges depending on the course of the workflow (taking into account, for example, attribute values). By default, permissions added using actions are removed when you go to the next step.

• Level – Indicate the type of authorization to grant
• Select people – There are 3 ways to indicate people who the change is about:
  • Always to – allows you to manually select people or groups
  • Dynamic – allows you to choose form field from the dropdown list
  • SQL query – allows you to specify people using an SQL query
• Should privilege expire on the next step? – checking will remove privileges after going to the next step
• Select elements – defines for which workflow instances the privileges are to be granted
  • Dynamic – allows you to choose the value from the dropdown list
    • Child
    • Current
    • Parent
  • SQL query – allows you to specify people using an SQL query

Privileges for attachments

Usually, attachment permissions are the same as item permissions. The exception is the “Read only (can’t view attachments)” permission, where the user cannot see the related attachments. However, it is not possible to assign permissions only to an attachment (e.g. it is impossible to give permission to read an attachment without access to workflow instance form data).

Privileges VS tasks

At the moment when the user receives the task, he also receives 2 types of permissions:

• Edit privilege – user may edit the form at the step where the task was assigned
• Read only – after task completion user may open and see workflow instance regardless of the step in which it will be

Summary

As you can see, WEBCON BPS allows you to assign different types of permissions at different levels. It’s good to know how you can manage the process privileges. WEBCON administrators should know that users who performed the task still have readings to the given workflow instance. In addition, there should be remembered that it is good practice for every user to receive the minimum privileges needed to complete a task.

In the 4th part of this series, I will show how privileges are stored in the database and how they work.

Featured image: Business vector created by rawpixel.com – www.freepik.com