Roles and Permissions: Difference between revisions

From QPR ProcessAnalyzer Wiki
Jump to navigation Jump to search
Line 75: Line 75:
* Run scripts
* Run scripts


Note that scripts are in one of the following contexts: '''project''', '''model''', '''user''' and '''system'''. To view scripts that are in ''project'' or ''model'' context, user needs to have the ''GenericRead'' for the related project. Only the user itself can view scripts that are in the user's own context (users with ''ManageScripts'' permission can see scripts in other users context). All users with ''RunScripts'' can see scripts in the ''system'' context.
Note that scripts are in one of the following contexts: '''project''', '''model''', '''user''' and '''system'''. To view scripts that are in ''project'' or ''model'' context, user needs to have the ''GenericRead'' for the related project. Only the user itself can view scripts that are in the user's own context (users with global ''ManageScripts'' permission can see scripts in other users context). All users with ''RunScripts'' can see scripts in the ''system'' context.
||[[File:Tick.gif|center]]|| ||[[File:Tick.gif|center]] ||[[File:Tick.gif|center]]|| || ||
||[[File:Tick.gif|center]]|| ||[[File:Tick.gif|center]] ||[[File:Tick.gif|center]]|| || ||
|-
|-

Revision as of 09:48, 21 March 2019

QPR ProcessAnalyzer has a role-based access control, where all operations require appropriate rights in order to be executable. rights are given to users and user groups by assigning users or groups to roles, where roles are a collection of permissions. Permissions are fixed in QPR ProcessAnalyzer and there is a fixed list of operations behind a permission what user can do. Roles can be bound either to projects or be global, which means that that role (and its permissions) is applicable for all the contents in the system. Users belonging to a user group, have always all the roles assigned to that user group.

Global and Project Roles

There are two types of roles in QPR ProcessAnalyzer:

  • Global roles are used to give rights in the entire QPR ProcessAnalyzer environment.
  • Project roles are used to give rights in a certain project. When assigning projects roles, the project needs to be defined.

When using the Manage Users dialog, global roles are assigned when <All> is selected from the project list. Projects roles are assigned, when a project is selected in the list.

By default, QPR ProcessAnalyzer environment contains global and project roles that are shown in the following table (roles are as columns). The roles have been mapped to certain permissions that are also shown in the following table (permissions are as rows). It's possible to create new roles in QPR ProcessAnalyzer.

Global roles Project roles
Permission Allowed operations Administrator ModelCreator RunScripts Administrator Designer Analyzer Viewer
GenericRead
  • View project's and model's information (name, description, configuration etc.) and data (cases, events, attributes etc.)
  • Run analyses for model and view the analysis results
  • See user's own private filters, all published filters and the model default filter (not allowed to create or modify filters)
Tick.gif
Tick.gif
Tick.gif
Tick.gif
Tick.gif
Filtering
  • Create filters
  • Modify and delete user's own private filters
  • Publish filters for other users (but not set the model default filter). Published filters are still user's own, so other users cannot modify them (except if user has the ManageViews permission).
Tick.gif
Tick.gif
Tick.gif
Tick.gif
GenericWrite
  • Edit model information (but not possible to create or delete models)
  • Create, modify and delete filters for model
  • Import data to model (requires also ManageIntegrations permission). There may be model specific restrictions for maximum number of events, case attributes and event attributes. These restrictions are ignored for users having global CreateModel permission with no limits. In addition, there may be effective activation limits.
Tick.gif
Tick.gif
Tick.gif
CreateModel
  • This permission is applicable only for the global roles.
  • Create projects, models for projects and data tables. When a project is created, the creator gets project Administrator role for the project (giving full permissions to the project).
  • When creating a data table, data table size restrictions (maximum number of rows and columns allowed by user's roles) are copied from user and stored for the data table.
Tick.gif
Tick.gif
DeleteModel
  • Moving model to recycle bin (deleting) (also ManageProject permission is needed)
  • Delete data tables
Tick.gif
Tick.gif
ManageViews
  • View, edit and delete all filters in the model (also other users' private filters)
Tick.gif
Tick.gif
ManageProject
  • Modify project information (name and description) (also GenericRead permission is needed)
Tick.gif
Tick.gif
ManageIntegrations
  • View, edit and delete data tables (requires also GenericRead permission for the project)
  • Import data to model (requires also GenericWrite permission)
Tick.gif
Tick.gif
ManageReports
Tick.gif
Tick.gif
ManageOperations
  • View operations from all users in the Operation Log
  • Terminate in progress operations run by any user
Tick.gif
Tick.gif
ManageUsers
  • Administrate users and groups, e.g. create new users and groups, and add users to groups

This permission is applicable only for global roles, because users and groups are not project specific objects.

Tick.gif
RunScripts
  • View scripts code and other script properties.
  • Run scripts

Note that scripts are in one of the following contexts: project, model, user and system. To view scripts that are in project or model context, user needs to have the GenericRead for the related project. Only the user itself can view scripts that are in the user's own context (users with global ManageScripts permission can see scripts in other users context). All users with RunScripts can see scripts in the system context.

Tick.gif
Tick.gif
Tick.gif
ManageScripts
  • Create, modify and delete scripts. Note also the script context described in the RunScripts section.
Tick.gif
Tick.gif

Notes:

  • In addition, there is an Evaluator role, which is similar to the ModelCreator role, but it has additional restrictions described in Additional Restrictions for Evaluator Role.
  • ModelCreator and Evaluator roles will get the project Administrator role for the projects that they create, giving full rights for the created projects.
  • Users with global Administrator or ModelCreator role can always import new data into any model without restrictions. Note, however, that a user cannot import more data than what is allowed by the product activation limits.

Group Roles

Administrator (Group) Member Hidden Member
Add/Remove Group Members
Tick.gif
Tick.gif
Tick.gif
Create Users to Group
Tick.gif
Add/Remove Project Access Rights of a User
Tick.gif
Tick.gif
Open Model Accessible to Group Members
Tick.gif
Tick.gif
Tick.gif
See Unhidden Group Members
Tick.gif
Tick.gif
See Hidden Group Members
Tick.gif

If a group member is a project Administrator, the user can add and remove project specific access rights for the group or for any individual member of the project.

Additional Restrictions for Evaluator Role

Evaluator has the following additional restrictions:

  • Maximum number of models: 10
  • Maximum number of event in a model: 1000
  • Maximum number of event attributes in a model: 1000
  • Maximum number of case attributes in a model: 1000
  • Maximum number of data tables: 10
  • Maximum number of rows in an data table: 1000
  • Maximum number of columns in an data table: 1000

Note: When an Evaluator role user creates a project, the project inherits these restrictions. Thus the restrictions are effective for all imports to that model, no matter which user is performing the import.

Scripting Permissions

For viewing script definitions and running scripts, global RunScripts permission is needed. All scripts linked to the current context are available provided that the current user has permission to see the scripts in the context. The required permissions by context are:

  • System context: No additional requirements.
  • Project context: GenericRead permission for the project.
  • Model context: GenericRead permission for the project of the model.
  • User context: If the script is linked to current user, then no additional requirements. If the script is linked to a group the current user belongs to, no additional requirements. If the script is linked to other users or user groups, global ManageScripts permission is required.

For script creation, modification, deletion and export, the following permissions are needed depending on the script context:

  • System context: Global ManageScripts and RunScripts
  • Project context: project ManageScripts and global RunScripts
  • Model context: project ManageScripts and global RunScripts
  • User context: Global RunScripts and if the script is linked to a user group the user belongs to, GroupAdministrator user group role is required.

If Hide Script Details is set for the script, only users with modify permissions for the script can see the script code and log.

Importing Data Permissions

Data can be imported into a data table with project GenericWrite and ManageIntegrations permissions. CreateModel permission is required if the user is overwriting existing data in the data table, i.e. not appending. User may never import more data than is allowed by product's activation. Data table specific data quotas are ignored for users that have unrestricted global CreateModel permission. Users that have restricted global CreateModel permission or users that don't have any global CreateModel permission may only import the amount of data into a data table specified in data table's own restrictions.

Permissions for Other Operations

  • Add a model into project: CreateModel permission for the target project. Model is moved into target project and all old permissions are replaced by the permissions for the target project.
  • Create a new model into existing project: Global CreateModel and CreateModel permission for the target project
  • Move a model from a project to another: GenericWrite and DeleteModel permissions for the source project and CreateModel permission for the target project
  • Restoring a project from recycle bin: Global GenericRead, CreateModel and ManageProject permissions
  • Deleting a project from the database: Global DeleteModel permission and ManageProject permission for the project
  • Creating a copy of a project: Global CreateModel permission and GenericRead and ManageProject permissions for the project

See Also