Allocate Some Data Rights In the Data Table

1. Version 

2. Application scenarios

Assigning data table permissions supports setting data table permissions for users individually, but administrators sometimes need to assign different data permissions under the same data table to different users, so that different users can view different content under the same data table.

3. Function introduction

FineBI provides a way to set row and column permissions for data tables.

4. Scope of use

The scope of use of row and column permissions is:

• Database Table

• SQL dataset

• Self-service datasets of data processing nature 

• Data processing user-added Excel datasets

Note: For BI projects of version 5.1.16 and later, when the sub-administrator assigns row and column permissions downward, the row and column permissions are not restricted (same as the administrator), and the current table and its 1 table with usage permissions can be selected.

Examples from this chapter:

There is a data table "Store Dimension" under the "Data Preparation > Industry Data > Retail Industry" business package.

The user eoco is assigned the viewing authority of the "store dimension" of the data table, but eoco can only view the data of stores whose "area of which they belong" is "southeast", and whose "property of store" is "owned store".

1. Assign data usage rights

The administrator logs in to the data decision system, clicks "Manage > Permission > General Permission Configuration", and selects the rights carrier "Department/Role/User". In this example, the user eoco is selected.

Select the "Data Authorization" tab, and configure the"Use" permission for the "Industry Data > Retail Industry > Store Dimensions" data table for eoco. As shown below:

2. Set row permissions

At this point, eoco can use all the data in the "Store Dimension" table, click the "Permission" button behind the data table, select "Row Permission", and click "Add Condition", as shown in the following figure:

• Add Condition 1:      "Belong to (field value)" and "Southeast Area" in the "Area" field of the "Store Dimension" table.

• Add Condition 2:      "Store Nature" field "Belong to (field value)" and "Own Store" in the "Store Dimensions" table.

Note 1: Row permissions cannot be set directly for groups /service packages, but only for a single data table.

Note2:versions earlier than 5.1.10 , setting row permissions can only select the table itself and its main table. For details of the main table, see: Association View5.1.10 and later versions, add configuration conditions for row permissions, select "belongs to/does not belong" to the login information field to choose from: system user name, user table, 1-side table of user table, and N-side table of user table (New N-side table); In addition, the field where the logged-in user is located cannot select the self-service dataset of data analysis nature.

Note 3: Since real-time data does not support cross-database fusion analysis, if the "Register Information Field" and "Data Table for Setting Row Permissions" are real-time data tables obtained from two databases respectively, row permissions cannot be set.

3. Effect preview

User eoco logs in to the Decision-making System, clicks "Data Preparation > Industry Data > Retail Industry", selects the "Store Dimension" table, and can only view the "District" as "Southeast Region", and the "Nature of Store" as "Own Store" ” store data. As shown below:

4. Notes

1) If you need to bind the permissions to the system user name, please refer to: View the corresponding data according to the login information for details .

2) The underlying table is set with row permissions.

• If permission inheritance is not selected for the self-service dataset, there is no change.

• If permission inheritance is selected for the self-service dataset, the permissions from the underlying table are directly inherited, and there is no need to reconfigure permissions based on the current table fields.

For details, see: Permission inheritance .

3) If the user's data permission sets the row and column permission restrictions for a specific table, even if the corresponding table usage permission is turned off, the row and column permission restrictions will still take effect. You must remove row and column permissions before turning off table permissions.

For example, user Zhang San belongs to both role A and department B.

At first, only the permission to see the specified row was restricted to role A. Later, the permission to delete the row was not allowed, and the permission of role A was directly closed.

At this time, even if department B's permission to this table is opened without restriction, Zhang San will still be restricted by the row permission.

Column permissions can directly control whether the corresponding authorized personnel can use a field under the data table. For example, for ordinary sales personnel, they want to use the "Sales Details" data for data analysis, but they do not need to view all the gross profit data of the company. Information, you can select column permission control to cancel the permission to view and use some fields for sales staff.

Examples from this chapter:

There is a data table "Sales Details" under the "Data Preparation > Industry Data > Retail Industry" business package.

Assign user eoco the viewing authority of the data table "Sales Details", but restrict eoco from viewing a column of data "gross profit".

1. Assign data usage rights

The administrator logs in to the Decision-making System, clicks "Manage  > Permission > General Permission Configuration", and selects the rights carrier "Department/Role/User". In this example, the user eoco is selected.

Select the "Data Permission" tab to configure the "Use" permission for the "Industry Data > Retail Industry > Sales Details" data table for eoco. As shown below:

2. Set column permissions

At this point eoco can use all the data of "Sales Details".

Click the "Permission" button to enter the permission detailed setting interface, select "Column Permission", and all data tables and fields that can be used by the salesperson in this business package are displayed.

Since ordinary salespeople do not need to view gross profit data, click the "Sales Details" table, uncheck the "Gross Profit" field, and click "OK" to save. As shown below:

3. Effect preview

User eoco logs in to the data decision system, clicks "Data Preparation > Industry Data > Retail Industry", and selects the "Sales Details" table.

eoco can only view sales data except gross profit, which realizes the field restriction effect of column permissions. As shown below:

4. Notes

1) If the user's data permission sets the row and column permission limit for a specific table, even if the corresponding table use permission is turned off, the row and column permission limit will still take effect. You must remove row and column permissions before turning off table permissions.

For example, user Zhang San belongs to both role A and department B.

At first, only the permission to see the specified row was restricted to role A. Later, the permission to delete the row was not allowed, and the permission of role A was directly closed.

At this time, even if department B's permission to this table is opened without restriction, Zhang San will still be restricted by the row permission.

2) If the administrator builds a "Sales Details" dashboard and hangs it in a directory that Wang Wei has permission to view, the dashboard uses "Sales Details" as the data source.

When the table component in the dashboard loses the column permission, *** will be displayed under the field of the table, and if the chart component loses the column permission, it shows that you cannot view the component data temporarily.

After setting the column permissions, Wang Wei has no right to view the "gross profit" field, and the display effect of "sales details" on the dashboard is shown in the following figure:

3) Since real-time data does not support cross-database fusion analysis, if the "Login Information Field" and "Data Table for Setting Column Permissions" are real-time data tables taken from two databases respectively, the column permissions cannot be set.

Ⅳ. Precautions

1. Upgrade Compatible Solutions

• You have use/administration/authorization rights before the upgrade, and you still have the rights after the upgrade.

• Before the upgrade, the column permissions of the business package are set, and the column permissions are changed to the table after the upgrade.

• Before the upgrade, if the row permissions are set in the service package where the table is located and there is no associated relationship, then the row permissions are configured to a single table after the upgrade.

• If a scenario in which the main table of a business package filters multiple sub-tables is implemented, the filter conditions will be reused on multiple sub-tables that were originally filtered by permissions after the upgrade.

  
  

2. Mobile data sheet

• If the permissions of the data table are configured separately before the move, the permissions remain unchanged after the move.

• If the permissions of the business package and group that store the data table are inherited before the move, the new parent permissions will be inherited after the move.

• The move does not change the configuration of row permissions, and column permissions follow the above rules.