Rank and column permission special scenarios

1. Problem description

Administrators can set row and column permissions to enable different users to view different data. However, if row and column permissions are set for departments, roles, and users at the same time, or if association relationships are used, complex settings may occur and the expected results may not be achieved. .

2. Solutions

This article describes some special scenarios of row and column permissions.

1. Departments, roles, and users set row permissions at the same time, and then take the "or" relationship

•  Permission Settings

Example: User Alice is both the head of the development department and the head of technical support, and also belongs to the common role, then set the permissions of the data table on these four (the head of the development department, the head of technical support, the common role, and the user Alice).

1) Set department row permissions for Alice, and the head of the development department sets the "Brand Description" field in the retail industry > brand dimension table to belong to "ZIPPO", as shown in the following figure:

Retail Industry > Brand Dimension table set by the Technical Support Minister belongs to "New Balance". As shown below:

3) Set the role row permissions for Alice, and set the "Brand Description" field in the " Retail Industry > Brand Dimension" table to "HANG TEN" for common roles. As shown below:

4) Set user row permissions for Alice. User Alice sets the "Brand Description" in the Retail Industry > Brand Dimension table to belong to "O.C.T.MAMI". As shown below:

•  Effect View

Alice's account logs in to the data decision-making system, and the final result is that the four row permission conditions take an "or" relationship, as shown in the following figure:

Note: If the use/management/authorization permissions have been set individually for the user, a yellow portrait icon will appear after the permissions are set. At this time, if you need to restore the inheritance of department/role permissions, you need to click the Restore Inherited Permissions button. A prompt box will pop up, "Are you sure to clear the user's individual permission settings for Directory and restore inheritance for department/role permissions", click OK. As shown below:

2. After setting the row permissions in the department, role, and user section, take "or" with the configured row permissions

•  Permission Settings

Example: User Alice is both the head of the development department and a common role, and the row permissions of the data table are set on these three (the head of the development department, the common role, and the user Alice).

Note: Partially set row permissions.

1) Set department permissions for Alice, and the head of the development department sets the "Brand Description" field in the retail industry > brand dimension table to belong to "ZIPPO", as shown in the following figure:

2) Set role permissions for Alice, and the "Brand Description" field in the " Retail Industry">Brand dimension table in the general role setting belongs to "HANG TEN". As shown below:

3) Set user permissions for Alice. User Alice sets the "brand dimension" use permissions, but does not set row permissions. As shown below:

Note: The real-time data selection of extracted data is only available in the version after 2020-09-01.

•  Effect display

The final result is that the configured row permissions take an "or" relationship, and roles and users without row permissions are not included in the OR relationship, as shown in the following figure:

3. The authority at the department level is "and" first, and the authority between different departments is "or"

Example: The hierarchical relationship of the company's departments is test group - product line 1, product line 2, development team - product line 1, product line 2, as shown in the following figure:

Sample Data: Employee Information Form.xlsx

•  Permission Settings

1) Add the employee information table as shown below:

2) User Alice is both a member of the test team of product line 1 and a member of the development team of product line 1, assigns the Package permission to the entire test group, and sets the row permission to employee information table. Department = test group, as shown in the following figure :

3) Assign the permission of Package to the product line 1 group under the test group, and add the row permission to the employee information table. Group = product line 1, as shown in the following figure:

4) Assign Package permissions to the entire development team, and add row permissions as employee information table. Department = Development team, as shown in the following figure:

5) Assign the Package permission to product line 1 under the development group, and add the row permission to the employee information table. Group = product line 1, as shown in the following figure:

•  Effect View

Alice logs in to view the "Employee Information Form", Alice can see the data of the product line 1 test group and the product line 1 development group, as shown in the following figure:

(First take and according to the authority between the department levels, and then take or between different departments)

4. Set row permissions for tables with associated relationships , and the main table can filter sub-tables (effective across business packages)

•  Permission Settings

Example: There are three tables: "Product Name Dimension Table", "Contract Fact Table", "Contract Receipt Fact Table", and the relationship is shown in the following figure:

2) Add "Product Name Dimension Table" and "Contract Fact Table" to business package A, add "Contract Receipt Fact Table" to business package B, and add "Product Name Dimension Table" and "Contract Receipt Fact Table" ” to set permissions, as shown in the following figure:

3) The administrator sets the "Contract Fact Table" row permission for the business package A, and the purchased product is equal to "1", as shown in the following figure:

•  Effect View

1) Ordinary user Alice logs in to view, the main table "Product Name Dimension Table" of "Contract Fact Table" can see all the data, and will not be affected by row permissions, as shown in the following figure:

2) "Contract Fact Sheet" and the sub-table "Contract Payment Fact Sheet" as "Contract Fact Sheet" can only see the data of the purchased product equal to 1, which is affected by the row permissions of the main table, as shown in the following figure:

5. Multiple master tables set row permissions to take "and" relationship

•  Permission Settings

Example: There are three tables: "Product Name Dimension Table", "Contract Fact Table", "Customer Dimension Table", and the relationship is shown in the following figure:

Note: "Product Name Dimension Table" and "Customer Dimension Table" are the main tables of "Contract Fact Table".

1) For the "Product Name Dimension Table", set the row permission product ID greater than or equal to 5, as shown in the following figure:

2) Set row permissions on the "Customer Dimension Table", the province belongs to Shanghai, as shown in the following figure:

3) Set the use permission for the "Contract Fact Table", but do not set the row permission, as shown in the following figure:

•  Effect View

Alice logs in to view the "Contract Fact Table". The "Contract Fact Table" can only see the relevant data under the customer ID whose product ID is greater than or equal to 5 and the customer province is Shanghai. As shown below:

1. When switching from the "Usage Authority" of the business package to the "Administration Authority", the column authority needs to be reconfigured

For example, if you set the row permissions and column permissions when only the service package usage permissions are enabled, and then enable the management permissions of the service package, the previously set row permissions will still take effect, while the column permissions need to be reconfigured.

2. Column permission setting or relationship between departments and roles The principle of maximum column permission user

•  Permission Settings

Example: User Alice belongs to both technical support and common roles.

1) Set the column permission of "Contract Fact Table" in the business package A for the technical support department, and select the fields contract amount, contract payment type, and contract type, as shown in the following figure:

2) Set the column permission of "Contract Fact Table" in the business package A for the common role, select the field contract type, whether it has been delivered

The contract signing time, as shown in the figure below:

3) At this point, set the column permissions for the user dimension, and select the "Purchased Products" field of the "Contract Fact Table", as shown in the following figure:

•  Effect View

When viewing the interface of user Alice's "Contract Fact Sheet", only the "Purchased Products" field is displayed, then the user's column permissions are completely determined by the user's settings, and the department role settings no longer affect the user, as shown in the following figure Show: