With viflow 8, permissions are introduced in viflow for the first time. These permissions can be used for the modellers and the users of the WebModel.
This document describes what options are available and how they should be used.
- What options do the permissions offer?
- A distinction is made between object and function authorizations
- Possible options for permissions
- Possible object permissions
- Inheritance of permissions
- Interrupt inheritance chain
- How should permissions be assigned?
What options do the permissions offer?
The permissions can be assigned either to individual users or to the newly added user groups. A combination is also possible.
A distinction is made between:
- Object permissions 1
refer to individual folders or the entire process model
- Function permissions 2
always refer to the entire process model
Both types of permissions have been combined in the properties window under the item Permissions.
The following options can be assigned to the respective permissions:
- not set 3
The value inherited from a higher level applies. If no value is set,the corresponding function is not supported, but can be overwritten by allow.
- Deny 4
The corresponding function is explicitly denied and cannot be overwritten by allow.
- Allow 5
The corresponding function may be used.
Important: Deny always overwrites Allow – therefore one should be very careful with this. For example, if a user is in a group and a function is denied to this group, the user can no longer be allowed to use this function by clicking on Allow.
The following options exist for object permissions:
- Create 1
Adding objects and folders is prevented. This option has no effect on graphics, or other objects that have no child objects. An exception is moving.
- Delete 2
Deleting (moving to the recycle bin) is prevented
- Edit 3
The properties of the object can no longer be edited. If it is agraphic, it cannot be edited. For folders, adding and removing new
objects and folders is also denied.
- Edit permissions 4
The permissions of the respective object cannot be edited – the tab disappears.
- View 5
The object cannot be viewed. The object or folder disappears from the view in the respective views – in the case of graphics, opening is prevented.
Attention: Assigned permissions affect modelling in viflow and also viewing in the WebModel. When logging into the WebModel, the user is automatically checked for assigned permissions. If the user cancels the authentication, he is logged in as user „anonymous“. Appropriate permissions can also be assigned here.
Inheritance of permissions:
- Groups/Users: A user inherits from his groups and each group inherits from superordinate groups. This concerns object and function permissions.
- Objects: An object inherits from its parent object. This only affects object permissions. Important: this does not affect structure views/structures at any time!
Interrupt inheritance chain
(Object) permissions always affect the folders, the object structure and thus also the subordinate folders. If you do not want this inheritance, you can interrupt it with Interrupt inheritance chain. The permissions of the superordinate folder are then copied once. Afterwards, the permissions assigned at the higher level no longer have any effect.
Example: If you assign (object) permissions to the process model in the overview and do not want them to be inherited by processes, select Interrupt inheritance chain for the Processes folder. Now the permissions are set once. This inheritance affects the Processes folder and the folders below it. From now on, permissions that were set at a higher level are no longer applied to the Processes folder (and the folders below it).
In addition, there are permissions that can restrict functions in viflow. These are summarised for users or groups under the item Permissions – Process Model:
- Import from other sources
- Open main version#
- Merge master shapes
- Change options
- Empty recycle bin
- Clean up process model
- Import process model
- Add/delete language
- Import translations
- Import Visio file
- Export WebModel
- Manage WebModel
How should permissions be assigned?
Basically, it is not necessary to work with permissions. It is also possible to model normally without any restrictions – the WebModel can also be used normally.
If you decide to use permissions it is important to think about a concept beforehand – what really makes sense and/or what needs to be restricted? You should not „over-organise“ yourself here, otherwise there is a risk of losing control and dealing with the process model becomes unnecessarily complicated.
In the default setting, the group Everyone is defined. Every existing and newly added user and every added group is automatically included in this group. In this way, rights can be easily transferred to all users and groups.
Attention: If you are working in a database, you should lock the database before changing the assigned permissions. This ensures that the changes are transferred cleanly.
As a general rule:
You should never think at the structural level, but always at the level of the corresponding folders. Basic permissions can also be assigned directly to the entire process model via the Overview.
Important: The person responsible for the process model should always grant themselves the allow rights as an extra member of a group or as an individual user. If you forget to do this or set the rights to deny, you risk being locked out!
At the highest level in the process model, you can first prohibit all users from using the corresponding functions by setting them to not defined. Then, authorisations should be successively assigned to the individual users or user groups.
The user anonymous transfers the object permissions to all users of the WebModel without a user ID - the so-called anonymous WebModel.
Note: Permissions that have been inherited are not displayed directly. Explicitly set permissions are displayed by means of an icon. Only set permissions are displayed.
If you want to see which permission applies to the respective object, you must click on the permission itself. Now it is displayed below which permission applies here and where it was inherited from.