Case Level Permissions: Difference between revisions

From QPR ProcessAnalyzer Wiki
Jump to navigation Jump to search
No edit summary
 
(177 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Each QPR ProcessAnalyzer model has '''model JSON settings'''. These JSON settings contain configurations and settings related to the model. The model needs to be reloaded into memory for the changed settings to take effect. See how to [[Project_Workspace_in_QPR_ProcessAnalyzer_Excel_Client#Model_Properties|change model JSON settings]].
In addition to [[Roles_and_Permissions|project level permissions]], it's possible to set '''case level permissions''' for models, where visibility can be defined for each case separately based on rules. Usually the rules are based on case attribute values. Case level permissions are effective for all users, but users who have the '''GenericWrite''' permission, can change the case permissions setting for a model and thus change the case permissions.


The below defined settings are available.
== Setting up==
Case level permissions are configured in the model properties (can be opened in the models list in the header) in the '''Case Level Permissions''' tab. The following settings are available:
* '''Initialization expression''': [[QPR_ProcessAnalyzer_Expressions|Expression]] that is run only once and can be used as initializing needed objects. This expression can be used to improve performance when part of the Case or EventLogKey expressions are common and thus they don't need to be calculated again for every Case separately.
* '''Permissions expression''': Expression determining which cases the accessing user can see. The expression is evaluated for each case (in the case context). If the evaluation results ''true'', the case is visible for the user; otherwise not. The evaluation is done when no existing eventlog if found based on the ''Eventlog key'' and a new eventlog needs to be generated. This expression is mandatory for the case level permissions to work
* '''Eventlog key expression''': Expression used to generate a uniquely identifying string for the eventlogs when the case level permissions are in use. If a cached eventLog with the same key already exists in the system, that eventlog is used instead of creating a new.


== Case Permissions ==
== Configuration examples ==
This section specifies data security restrictions for objects within the QPR ProcessAnalyzer model (i.e. limit visibility). If the Permissions section hasn't been defined, all the model data is visible to all users having '''GenericRead''' permission for the project in which the model resides ([[User Roles and Permissions in QPR ProcessAnalyzer|more information about roles and permissions]]). Permissions defined in this section, are only available when using the [[Installing QPR ProcessAnalyzer Server#Configure_Web_Service_to_use_In-Memory_or_In-Database_processing|In-Memory core]].
Visibility of cases is limited in a way that only those users can see cases belonging to a group which name is same as the ''Region'' (case attribute).
* Initialization expression: '''let groupNames = OrderByValue(CurrentUser.GroupNames)'''
* Permissions expression: '''Region.In(groupNames)'''
* Eventlog key: '''StringJoin("_", groupNames)'''


{| class="wikitable"
Cases are only visible for users whose user name is same as the ''Account Manager'' (case attribute):
!'''Property'''
* Initialization expression: '''let userName = CurrentUser.Name'''
! '''Description'''
* Permissions expression: '''Attribute("Account Manager") == userName'''
|-
* Eventlog key: '''CurrentUser.Id'''
|Initialization
 
|[[QPR_ProcessAnalyzer_Expressions|Expression language]] expression used to make an initial calculation for all the other expressions within this same permissions context. This expression can be used to improve performance when part of the Case or EventLogKey expressions are common and thus they don't need to be calculated again for every Case separately. See the examples below of using the Initialization expression.
Cases where ''Region'' case attribute is ''Dallas'' will only be visible for users belonging to group ''GroupA'' (and ''New York'' for group ''GroupB''):
|-
* Initialization expression: '''let groupNames = CurrentUser.GroupNames'''
||Case
* Permissions expression: '''(Region == "Dallas" && "GroupA".In(groupNames)) || (Region == "New York" && "GroupB".In(groupNames))'''
||[[QPR_ProcessAnalyzer_Expressions|Expression language]] expression determining which users can see each Cases. The expression is evaluated within the context of each Case. If the evaluation results '''true''', the Case is visible for the user. Otherwise the Case, its Events and case and event attributes are not visible. This setting implements case level security restrictions.
* Eventlog key: '''If("GroupA".In(groupNames), "_A", "_") + If("GroupB".In(groupNames), "_B", "_")'''
|-
 
||EventLogKey
User ''qpr'' can only see cases where ''Region'' is ''Dallas'', and all other users can see all cases:
||[[QPR_ProcessAnalyzer_Expressions|Expression language]] expression used to uniquely identify all the unique event logs created by case permission filters. If a cached EventLog with the same key is already in the system, that EventLog is used instead of creating a new. The new EventLog is created by applying the Case expression to filter the Cases users have rights to.
* Initialization expression: '''let userName = CurrentUser.Name'''
|}
* Permissions expression: '''(userName == "qpr" && Attribute("Region") == "Dallas") || userName != "qpr"'''
* Eventlog key: '''CurrentUser.Id'''
 
== Use case ==
Case level permissions can be implemented with the principle illustrated in the image below. ''Users'' already belong to certain ''groups'' in the user management, and ''cases'' have certain ''case attribute values'' which is part of the loaded process mining data. Additionally, the linkage between case attribute values (of a certain case attribute) and groups needs to be defined when this security feature is configured. The image below illustrates the chain between ''users'' and ''cases'', how certain users are able to see certain cases when viewing analyses from a QPR ProcessAnalyzer model.
 
[[File:CasePermissions.png|800px]]


=== Example usecase for case permissions ===
Example: There are groups G1, G2 and G3. Case permissions have been set as follows:
There are groups G1, G2 and G3. Case permissions have been set as follows:
* group G1 can only see cases where (case attribute) Region is Dallas
* group G1 can only see cases where (case attribute) Region is Dallas
* group G2 can only see cases where Region is Austin
* group G2 can only see cases where Region is Austin
Line 65: Line 77:
There is no way for a user to be aware of the existence of cases that the user doesn't have rights to.
There is no way for a user to be aware of the existence of cases that the user doesn't have rights to.


=== Configuration examples for case permissions ===
[[Category: QPR ProcessAnalyzer]]
In this example, visibility of cases is limited in a way that only those users can see the cases belonging to a user group which name is same as the Region (case attribute).
<pre>
{
  "Permissions": {
    "Initialization": "Let(\"groupNames\", OrderByValue(CurrentUser.GroupNames))",
    "Case": "Region.In(groupNames)",
    "EventLogKey": "StringJoin(\"_\", groupNames)"
  }
}
</pre>
 
In this example, cases are only visible for users whose user name is same as the Account Manager (case attribute).
<pre>
{
  "Permissions": {
    "Initialization": "Let(\"userName\", CurrentUser.Name)",
    "Case": "(Attribute(\"Account Manager\") == userName)",
    "EventLogKey": "CurrentUser.Id"
  }
}
</pre>
 
In this example, cases having "Region" case attribute of "Dallas" will only be visible for users belonging to user group "GroupA" (and "New York" for group "GroupB").
<pre>
{
  "Permissions": {
    "Initialization": "Let(\"groupNames\", CurrentUser.GroupNames)",
    "Case": "(Region == \"Dallas\" && \"GroupA\".In(groupNames)) || (Region == \"New York\" && \"GroupB\".In(groupNames))",
    "EventLogKey": "If(\"GroupA\".In(groupNames), \"_A\", \"_\") + If(\"GroupB\".In(groupNames), \"_B\", \"_\")"
  }
}
</pre>
 
== Data sources ==
{| class="wikitable"
!'''Property'''
! '''Description'''
|-
|Cases
|
{| class="wikitable"
!'''Property'''
! '''Description'''
|-
||DataSourceType
||Data source type, where to fetch the Cases data. Currently only supported value is '''odbc'''.
|-
||OdbcConnectionString
||ODBC connection string to use to fetch the Cases data. Connection strings can be found in https://www.connectionstrings.com.
|-
||OdbcQuery
||ODBC query to use to fetch the Cases data.
|-
||Columns
||Column name mappings for QPR ProcessAnalyzer data model. Only supported mapping for Cases is '''CaseId'''. Example:
<pre>
{
  "CaseId": "Name"
}
 
</pre>
All unmapped columns are imported as case attributes.
|}
 
|-
||Events
||
{| class="wikitable"
!'''Property'''
! '''Description'''
|-
||DataSourceType
||Data source type, where to fetch the Events data. Currently only supported value is '''odbc'''.
|-
||OdbcConnectionString
||ODBC connection string to use to fetch the Events data. Connection strings can be found in https://www.connectionstrings.com.
|-
||OdbcQuery
||ODBC query to use to fetch the Events data.
|-
||Columns
||
Column name mappings for QPR ProcessAnalyzer data model, i.e. which columns in the fetched data are for. Supported mappings for Events are '''CaseId''', '''EventType''' and '''Timestamp'''. Example:
<pre>
{
  "CaseId": "Case",
  "EventType": "Event Type",
  "Timestamp": "Start Time"
}
</pre>
All unmapped columns are imported as event attributes.
|}
|}
 
=== Load QPR ProcessAnalyzer models from ODBC datasources ===
 
Follow the instruction below to install '''Microsoft Access Database Engine 2016 Redistributable''' to get ODBC drivers for Microsoft Access (*.mdb and *.accdb) files, Microsoft Excel (*.xls, *.xlsx, and *.xlsb) files, Microsoft SQL Server, and text files (it needs to be installed in the same computer where the QPR ProcessAnalyzer service is running):
# Go to https://www.microsoft.com/en-us/download/details.aspx?id=54920 and click Download.
# Select whether to use the 32bit or 64bit (X64) version (it's likely the 64bit version).
# Double-click the executable file on your hard disk to start the setup program.
# Follow the instructions on the screen to complete the installation.
 
Error codes for troubleshooting are accessible from [https://docs.microsoft.com/en-us/sql/odbc/reference/appendixes/appendix-a-odbc-error-codes?view=sql-server-2017| ODBC Error Codes].
 
In this example, data is loaded from a CSV files that is accessible from though the file system (in this examples cases are store to path C:\. Example of path to csv file would be C:\\TestData\\.
<pre>
{
  "DataSource": {
    "Cases": {   
      "DataSourceType": "odbc",
      "OdbcConnectionString": "Driver={Microsoft Access Text Driver (*.txt, *.csv)};DefaultDir=<path to csv file location>;Extensions=asc,csv,tab,txt",
      "OdbcQuery": "SELECT * FROM [ModelCaseAttributes.csv]",
      "Columns": {
        "CaseId": "Name"
      }
    },
    "Events": {
      "DataSourceType": "odbc",
      "OdbcConnectionString": "Driver={Microsoft Access Text Driver (*.txt, *.csv)};DefaultDir=<path to csv file location>;Extensions=asc,csv,tab,txt",
      "OdbcQuery": "SELECT * FROM [ModelEventData.csv]",
      "Columns": {
        "CaseId": "Case",
        "EventType": "Event Type",
        "Timestamp": "Start Time"
      }
    }
  }
}
</pre>
 
In this example, data is loaded from an SQL Server table.
 
<pre>
{
  "DataSource": {
    "Cases": {
    "DataSourceType": "odbc",
    "OdbcConnectionString": "Driver={SQL Server};Server=<hostname>;DataBase=<database name>;Trusted_Connection=True;",
    "OdbcQuery": "SELECT MOD_CREATED_BY FROM PA_MODEL",
    "Columns": {
      "CaseId": "MOD_CREATED_BY"
    }
    },
    "Events": {
      "DataSourceType": "odbc",
      "OdbcConnectionString": "Driver={SQL Server};Server=<hostname>;DataBase=<database name>;Trusted_Connection=True;",
      "OdbcQuery": "SELECT MOD_NAME, MOD_CREATED_DATE, MOD_CREATED_BY FROM PA_MODEL",
      "Columns": {
        "CaseId": "MOD_CREATED_BY",
        "Timestamp": "MOD_CREATED_DATE",
        "EventType": "MOD_NAME"
      }
    }
  }
}
</pre>

Latest revision as of 19:30, 11 December 2021

In addition to project level permissions, it's possible to set case level permissions for models, where visibility can be defined for each case separately based on rules. Usually the rules are based on case attribute values. Case level permissions are effective for all users, but users who have the GenericWrite permission, can change the case permissions setting for a model and thus change the case permissions.

Setting up

Case level permissions are configured in the model properties (can be opened in the models list in the header) in the Case Level Permissions tab. The following settings are available:

  • Initialization expression: Expression that is run only once and can be used as initializing needed objects. This expression can be used to improve performance when part of the Case or EventLogKey expressions are common and thus they don't need to be calculated again for every Case separately.
  • Permissions expression: Expression determining which cases the accessing user can see. The expression is evaluated for each case (in the case context). If the evaluation results true, the case is visible for the user; otherwise not. The evaluation is done when no existing eventlog if found based on the Eventlog key and a new eventlog needs to be generated. This expression is mandatory for the case level permissions to work
  • Eventlog key expression: Expression used to generate a uniquely identifying string for the eventlogs when the case level permissions are in use. If a cached eventLog with the same key already exists in the system, that eventlog is used instead of creating a new.

Configuration examples

Visibility of cases is limited in a way that only those users can see cases belonging to a group which name is same as the Region (case attribute).

  • Initialization expression: let groupNames = OrderByValue(CurrentUser.GroupNames)
  • Permissions expression: Region.In(groupNames)
  • Eventlog key: StringJoin("_", groupNames)

Cases are only visible for users whose user name is same as the Account Manager (case attribute):

  • Initialization expression: let userName = CurrentUser.Name
  • Permissions expression: Attribute("Account Manager") == userName
  • Eventlog key: CurrentUser.Id

Cases where Region case attribute is Dallas will only be visible for users belonging to group GroupA (and New York for group GroupB):

  • Initialization expression: let groupNames = CurrentUser.GroupNames
  • Permissions expression: (Region == "Dallas" && "GroupA".In(groupNames)) || (Region == "New York" && "GroupB".In(groupNames))
  • Eventlog key: If("GroupA".In(groupNames), "_A", "_") + If("GroupB".In(groupNames), "_B", "_")

User qpr can only see cases where Region is Dallas, and all other users can see all cases:

  • Initialization expression: let userName = CurrentUser.Name
  • Permissions expression: (userName == "qpr" && Attribute("Region") == "Dallas") || userName != "qpr"
  • Eventlog key: CurrentUser.Id

Use case

Case level permissions can be implemented with the principle illustrated in the image below. Users already belong to certain groups in the user management, and cases have certain case attribute values which is part of the loaded process mining data. Additionally, the linkage between case attribute values (of a certain case attribute) and groups needs to be defined when this security feature is configured. The image below illustrates the chain between users and cases, how certain users are able to see certain cases when viewing analyses from a QPR ProcessAnalyzer model.

CasePermissions.png

Example: There are groups G1, G2 and G3. Case permissions have been set as follows:

  • group G1 can only see cases where (case attribute) Region is Dallas
  • group G2 can only see cases where Region is Austin
  • group G3 can only see cases where Region is either Austin or New York

QPR ProcessAnalyzer model contains the following cases:

Case name Region (case attribute) Groups can see
A Dallas G1
B Dallas G1
C Austin G2, G3
D New York G3
E New York G3
F New York G3

Thus, when viewing analyses, a user see that the model contains the following cases:

  • If the user belongs to group G1 only, the user can see cases A and B (2 cases)
  • If the user belongs to group G2 only, the user can see case C (1 case)
  • If the user belongs to group G3 only, the user can see cases C, D, E and F (4 cases)
  • If the user belongs to groups G1 and G2 only, the user can see cases A, B and C (3 cases)

There is no way for a user to be aware of the existence of cases that the user doesn't have rights to.

Retrieved from "https://wiki.onqpr.com/pa/index.php?title=Case_Level_Permissions&oldid=19560"