Roles and Permissions

From QPR ProcessAnalyzer Wiki
Jump to navigation Jump to search

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 groups' by assigning roles to them. Roles are a collection of permissions. Permissions are fixed in QPR ProcessAnalyzer allowing certain operations to be done. Some roles are project roles meaning that role (and its permissions) is applicable only for that project. Roles can also be global which gives rights to all projects in the system. Users belonging to a group, have all the roles assigned to that group.

Roles and Permissions

By default, QPR ProcessAnalyzer system contains 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).

Global roles Project roles
Permission Allowed operations Administrator Create projects SQL Scripting Administrator Designer Analyzer Viewer
Open dashboards
(GenericRead)
  • View project's and model's information (name, description, configuration etc.)
  • List datatables and view their contents
  • Open dashboards (queries made by the dashboards are still restricted by the permissions)
  • Run queries for models
  • See own private filters, all published filters and the model default filter (not allowed to create/modify/delete filters)
Tick.gif
Tick.gif
Tick.gif
Tick.gif
Tick.gif
Save filters
(Filtering)
  • Create, modify and delete own filters (private and public, but not model default)
  • Publish own private filters for other users (but not set the model default filter). Published filters are still user's own, so other users cannot modify them.
Tick.gif
Tick.gif
Tick.gif
Tick.gif
Design dashboards
(EditDashboards)
  • Create, modify and delete dashboards in the project.
Tick.gif
Tick.gif
Tick.gif
Tick.gif
Create models
(GenericWrite)
  • Create and modify models, datatables and design diagrams
  • Import data to datatables, modify/remove rows in datatable, add/modify/remove columns in datatable
Tick.gif
Tick.gif
Tick.gif
Manage filters
(ManageViews)
  • View, create, modify and delete all filters in the model (also other users' private filters).
  • Set the model default filter.
Tick.gif
Tick.gif
Manage project
(ManageProject)
  • Modify project settings (such as name, description, and configuration).
  • Move project
Tick.gif
Tick.gif
Delete models
(DeleteModel)

As a project specific permission:

  • Moving models to recycle bin (soft delete)
  • Delete datatables (for datatables deletion is always permanent)

As a global permission:

  • Open bin and (permanently) delete models and projects
Tick.gif
Tick.gif
Manage scrips
(ManageScripts)
  • Create, modify and delete scripts in the project.
Tick.gif
Tick.gif
Manage operations
(ManageOperations)
  • View the Task log
  • Terminate in progress tasks run by any user
Tick.gif
Manage users
(ManageUsers)
  • Manage users, groups, roles and permissions (note: with this permission, user can assign any permissions to itself).
  • Change any user password.
Tick.gif
Create projects
(CreateModel)
  • Create projects (user gets project Administrator role for the created project).
Tick.gif
Tick.gif
SQL scripting
(RunScripts)
  • Run SQL scripts (note: expression scripts don't have separate permission).
Tick.gif

User Management Concepts

User management schema.png

User management in QPR ProcessAnalyzer is based on the following concepts (which are also illustrated in the diagram on the right):

  • User: Each person using the system should have an own user account. When a successful authentication has been made a session is created for a certain user. In addition to groups, roles can be assigned directly to users.
  • Group: Group contain selected roles and also selected users are assigned to the group, giving the roles to those users. Groups make managing users easier.
  • Role: Role contains specific permissions and thus giving certain kind of rights in the system. There are commonly used roles available in QPR ProcessAnalyzer, and additionally new roles can be created for customized use cases. Roles can be divided into two types:
    • Global role are used to give rights in the entire QPR ProcessAnalyzer system.
    • Project role are used to give rights in a certain project. When assigning projects roles, the project is also defined.
  • Permission: Permission defines what user can do (e.g. read, create, modify, delete) to certain kinds of objects. Permissions are fixes in the system, i.e. new permissions cannot be added by users.

The diagram also includes term role assignment which links one user/group (either of those), one project, and one role together.

(In the diagram, 0..N means that an entity is linked to none, one or several other entities, 1..N means that an entity is linked one or several other entities, and 1 means that the linkage is always to a single entity.)

Dashboard Permissions

  • View dashboard: EditDashboards for the project.
  • Create dashboard: EditDashboards for the project.
  • Edit dashboard: EditDashboards for the project.
  • Move dashboard: EditDashboards for the original project and for the target project.
  • Delete dashboard (permanently): EditDashboards for the project.

Model Permissions

  • View model: GenericRead for the project.
  • Create model: GenericRead and GenericWrite for the project.
  • Import model from pacm file: GenericRead, GenericWrite and ManageViews for the project.
  • Change model properties (e.g. name): GenericRead and GenericWrite for the project.
  • Move model: GenericRead and DeleteModel for the source project, and GenericRead and GenericWrite for the target project.
  • Delete model (to bin): GenericRead and DeleteModel for the project.
  • Delete model (permanently): global DeleteModel.
  • Copy model: GenericRead and GenericWrite for the project.
  • Initiate model loading: GenericRead for the project (*).

(*) The model loading might also require other permissions, e.g. access to the datatables or permissions required by the commands in the loading script. Models are not loaded using the permissions of the initiating user, but instead models are loaded in the following security context: GenericRead and GenericWrite for the project, global RunScripts. Models might also be loaded automatically during the server startup and this behavior ensures consistency regardless on how the model was loaded.

Project Permissions

  • View project: GenericRead for the project. (There are separate permissions for viewing dashboards/models/datatables/scripts in the project.)
  • Create project: global CreateModel, and GenericRead for the parent project (if creating a child project).
  • Change project properties (e.g. name): GenericRead and ManageProject for the project.
  • Move project: global CreateModel permission, ManageProject for the moved project, GenericRead for the original parent project, and GenericRead for the target parent project (if target is not root level).
  • Delete project (to bin): ManageProject and DeleteModel for the project.
  • Delete project (permanently): global DeleteModel and ManageProject permission for the project.
  • Copy project: Global CreateModel permission, and GenericRead and ManageProject for the copied project.

Note: Projects hierarchy doesn't generally affect the permissions, e.g., to see a project, permissions to its parent project are not required.

Datatable Permission

  • List datatables, view datatable properties and data contents: GenericRead for the project.
  • Create datatable: GenericWrite for the project.
  • Change datatable properties, import data to datatable, modify/delete datatable rows, add/modify/delete datatable columns: GenericWrite for the project.
  • Move datatable between projects: GenericWrite and DeleteModel to source project, GenericWrite for target project, and global CreateModel.
  • Delete datatable (permanently): GenericWrite and DeleteModel for the project.

Filter Permissions

  • View own private filters, all published filters, and model default filter: GenericRead for the project.
  • View all filters: ManageViews for the project.
  • Create filter: Filtering for the project.
  • Edit own filters: Filtering for the project.
  • Edit all filters: ManageViews for the project.
  • Publish own filters: Filtering for the project.
  • Publish all filters: ManageViews for the project.
  • Delete own filters (permanently): Filtering for the project.
  • Delete any filters (permanently): ManageViews for the project.
  • Set model default filter: ManageViews for the project.

Note: When a filter is published, the filter still has owner which is applied for the permissions.

Script Permissions

  • View, call and run expression script: GenericRead for the project.
  • Create, edit and delete expression script: ManageScripts for the project.
  • View, call and run SQL script: global RunScripts and GenericRead for the project.
  • Create, edit and delete SQL script: global RunScripts and ManageScripts for the project.