What types and options of authorization are there?

What types and options of authorization are there ?

The authorizations can either be assigned to individual users or to newly added user groups. A combination is also possible.

Types of Permissions

A basic distinction is made between:

• Object Permissions {{1}} relate to individual folders or the entire process model.
• Functional authorizations {{2}} always refer to the entire process model.

Both types of rights have been set in the properties window under Permissions summarized.

Possibilities of permissions

The following options can be assigned to the respective authorizations:

• Not specified {{3}}
  The value inherited from a higher level applies. If no value is set, the corresponding function is not supported, but can be overridden by allowing.
• Deny {{4}}
  The corresponding function is explicitly denied and cannot be overridden by allowing.

• Allow {{5}}
  The corresponding function may be used.
  
  
  
  Delete

  Important Note - Overriding Permissions

  Deny always overrides Allow , so be very careful with it. For example, if a user is in a group and that group is denied a feature, the user can no longer be allowed that feature by allowing.
  

object permissions

object permissions

The following options exist for object authorizations:

• To edit {{1}}
  The properties of the object can no longer be edited. If it is a graphic, it cannot be edited. In the case of folders, the addition and removal of new objects and folders are also denied.
• Edit Permissions {{2}}
  The permissions of the respective object cannot be edited - the register disappears.
• Consider {{3}}
  The object cannot be viewed. The object or the folder disappears from the view in the respective views – opening of graphics is prevented.
• Create {{4}}
  Adding objects and folders is prevented. This option has no effect on graphics or other objects that do not have sub-objects. An exception is moving.
• Extinguish {{5}}
  Deleting (moving to the recycle bin) is prevented.
  
  
  

Inheritance of Permissions

Inheritance of Permissions

• Groups/Users: A user inherits from their groups and each group inherits from parent groups.
  This affects object and function permissions.
• Objects: An object inherits from its parent. This only affects object permissions.
  Important: This does not affect structural views/outlines at any time!
  

break the chain of inheritance

(Object) authorizations always affect the folders, the object structure and thus also the underlying folders. If you do not want this inheritance, you can interrupt the inheritance chain with the function of the same name. The permissions of the folder above are then copied once. The authorizations assigned at a higher level then no longer have any effect.

Example: If you assign (object) authorizations to the process model in the overview and do not want them to be inherited by processes, you select Break inheritance chain in the "Processes" folder. Now the authorizations are set once. This inheritance affects the Processes folder and the folders below it. Effective immediately, permissions set at a higher level are no longer applied to the Processes folder (and folders below it).

In addition, there are authorizations that can restrict functions in viflow. These are summarized for users or groups under the item Authorizations - Process model:

• Import from other sources
• Open main version
• Merge Master Shapes
• change options
• empty trash
• Clean up process model
• Import process model
• Add/delete language
• Import translations
• Import Visio file
• Export web model
• Manage web model

How should permissions be granted?

How should permissions be granted?

First, at the top level in the process model, by setting it to Not set , you can disallow all users from using the relevant functionality. The individual users or user groups should then be given the appropriate authorizations one after the other.

The user anonymous transfers the object permissions to all users of the WebModel without a user ID - the so-called anonymous WebModel.