Multitenant Report - Configuration

Multitenant report is an Omniscope Evo feature that allows users to create a tailored experience for different report viewers by restricting the subset of records according to the user's credentials. A guide on how to setup multitenant report can be found in this article. 

As part of setting up this scenario you will need to provide the configuration to the report via a report input with some well structured data. This article will describe the format of this data, and the semantics of each field, as well as the mechanism which the report variant is chosen.

The configuration input is read as a sequence of "report variant". Each report variant is a collection of conditions and effects.

For example consider the case where for the users members of the group "sales and accounting" we want the report to only show records where the field [department] equals to "sales". In this case group of authenticated users being equal to  "sales and accounting" is the condition whereas the application of the filter group = sales for the report records is the effect.

In order to apply a report variant all conditions must be satisfied. If all conditions are satisfied then all effects will be applied.

A condition field which is not present, or left blank, will be considered as a satisfied condition.

N.B. Not every field described below has to be present in the configuration, but fields that are not valid configuration fields are not allowed. Missing conditions will be considered always satisfied.

Multitenant configuration format

Conditions:

• GROUP This column is a condition on the group of the report's visitor (see image below). It will match if the value of the cell is the same as the name of the group the authenticated user is a member of. It can be left empty meaning any group (or even no group).
  
  
• USER This column is a condition on the user name. It will match if the value of the cell is the same as the name of the user. It can be left empty meaning any user. When using OpenID connect for authentication the user's email will be matched against values of the USER column.
  
  
• SCENARIO This is a condition over optional scenario section in the URL accessing the report. This will allow a tailored experience of the same report based on the URL serving the report.
  The scenario should be set in the url by indicating the (encoded) id of the scenario, preceded by /s/ and by the report block name
  For example in the URL: http://192.168.0.25/File.iox/r/MyReport/s/myScenario the report is "MyReport" and the scneario is "myScenario". In order for the report to be served successfully the value myScenario must appear under the scenario column in the multi tenant configuration.
  If left empty in the configuration, it will not match any scenarios. In versions older than 2021.1 Rock, an empty If left empty in the configuration, it will match any value.

Effects

• FILTER The [filter] field is an effect that will specify filtering criteria. This can be useful to power the report using only some of the records in input (e.g., only those records where the field department is equal to sales).
  If left empty, or the field is not present in the configuration, then no filtering will take place (showing all the records in the report).
  Filters can be represented using two formats - Simple and JSON.  Each format can be used to represent a filter for all report inputs, or for a specific input (for example apply the filter department = sales for the first input of the report, but the filter country = UK for the third input). You cannot mix the two filter formats within the same cell (but you can use different formats in different records).
  
  N.B. Filters can only be applied to report input data sources and not to derived data sources (available on individual report level from the Report data sources)
  
  Simple filter format This represents the filter as a pair : <fieldName> = <value>.      <fieldName> needs to be an existing field in the report data source . Note that this format only supports text fields!
  
  If a single filter is defined, then it will take effects on all the report inputs.
  
  If your report has multiple inputs and you want to specify a different filter for each input, then you can comma separate multiple entries associated with each input.
  For example the value "department = sales, , country = UK" is interpreted as department = sales for the first report input, no filter for the second report input, and country = UK for the third input. Note how there is no filter for the second input, and as such the filter for the second input has been left empty ", ,".
  
  JSON format: This is a more advanced format for cases where the Simple format is not powerful enough. This format will allow you to define filters on all fields types, combination of filters, as well as operators other than equal.
  You can find more details about this format in the Query Apis section In the view designer tutorials. Some examples of filters represented in this format can be found at the bottom of this article.
  If different filters should be applied to different inputs, a json array can be used (again the position in the array will identify the report input the filter should be applied to).

Miscellaneous

• NOTES A free [notes] field can be used to describe the report variant. It has no effect in terms of report customisation. 

How Omniscope decides which report variant to apply

Omniscope will look at the multi tenant configuration records, and will try to match the user credentials against each record. 

For example, when the user "sally", member of the sales and accounting group, wants to visualise the report, Omniscope will look for a record where the USER field condition (if any) is satisfied for the user sally, and the GROUP condition is satisfied for the value "sales and accounting". The following records will all match those conditions:

So, how does Omniscope determine which scenario to apply when sally accesses the report ? 

The answer is the first variant that matches all the conditions. Omniscope will scan each variant from top to bottom looking for a match. When a matching variant is found, it will stop looking, and will apply the effects to the report. In this case, the filter department = sales will be applied to every report input.

If no match is found, than the user will not be able to access the report, and he/she will be asked to provide a different set of credentials

Some examples of Filter using the Json Format

Records where the field [department] is equal to "sales":

{

    "type": "FIELD_VALUE",

    "inputField": "department",

    "operator": "EQUALS_IGNORE_CASE",

    "value": "sales"

}

Records where the field [department] is equal to "sales" and [country] is  UK:

{

    "type": "AND",

    "filters": [

        {

            "type": "FIELD_VALUE",

            "inputField": "department",

            "operator": "EQUALS_IGNORE_CASE",

            "value": "sales"

        },

        {

            "type": "FIELD_VALUE",

            "inputField": "country",

            "operator": "EQUALS_IGNORE_CASE",

            "value": "UK"

        }

    ]

}

Records where the field [department] is equal to "sales" or [years seniority] is greater than 3:

{

    "type": "OR",

    "filters": [

        {

            "type": "FIELD_VALUE",

            "inputField": "department",

            "operator": "EQUALS_IGNORE_CASE",

            "value": "sales"

        },

        {

            "type": "FIELD_VALUE",

            "inputField": "years seniority",

            "operator": ">",

            "value": 3

        }

    ]

}

Records where department is "sales" for the first input, and filter all the records from third second input:

[

    {

        "type": "FIELD_VALUE",

        "inputField": "department",

        "value": "sales"

    },

    ,

    {

        "type": "OR",

        "filters": []

    }

]

Some examples of multi tenant variant definition