Role Management

Limitations

• Custom roles are available only in the Quick BI Professional Edition.

• The open API for roles currently supports only predefined system roles. Support for custom roles is planned for a future release.

Feature overview

1. Predefined user roles: Quick BI provides several predefined user roles. You can remove the default predefined roles and reassign users to custom roles.

   • At the organization level, Quick BI provides three predefined organization roles: organization administrator, permission administrator, and general user.

   • At the workspace level, Quick BI provides four predefined workspace roles: workspace administrator, workspace developer, workspace analyst, and workspace viewer.

2. Custom roles: You can create custom organization-level and workspace-level roles and assign multiple roles to a user to meet your business needs.

3. Functional permissions: You can define functional permissions for each role.

4. Resource permissions: You can centrally authorize access to resources at both the organization and workspace levels.

Feature access

On the Quick BI homepage, navigate to the role management page as shown in the following figure.

Organization roles

1. Create an organization role.

   On the role management page, create an organization role as shown in the following figure.

   

2. Configure functional permissions.

   On the role management page, configure the functional permissions for the role as shown in the following figure.

   

   Organization Management: includes workspace management, Enterprise Security (Centralized Authorization, Collaborative Authorization Configuration, and Data Security), Intelligent O&M, Appearance Configuration, Report Configuration, and Map Configuration.

   Enterprise Applications: includes Exploratory Analysis, Metric Watch, Subscription Management, Self-Service Data Retrieval, Resource Package Management, and dataset (Use).

   Note

   The "dataset (Use)" permissions for an organization role and a workspace role are cumulative. A user gains access if they have this permission in either role.

   Open Integration: includes AccessKey ID/AccessKey Secret (AK/SK), open API, Data Service, embedded analytics, Custom Visualization, and Custom Template.

   Note

   • By default, a new organization role includes functional permissions for Exploratory Analysis, Metric Watch, Subscription Management, Self-Service Data Retrieval, open API, Data Service, and embedded analytics. You can add or remove permissions for these and other modules.

   • You cannot modify the functional permissions of predefined organization roles.

     • The organization administrator has the highest privileges in an organization and can manage all features. It includes permissions for workspace management, Enterprise Security (Centralized Authorization, Collaborative Authorization Configuration, Data Security), Intelligent O&M, Appearance Configuration, Report Configuration, Map Configuration, Exploratory Analysis, Metric Watch, Subscription Management, Self-Service Data Retrieval, Resource Package Management, dataset (Use), AccessKey ID/AccessKey Secret (AK/SK), open API, Data Service, embedded analytics, Custom Visualization, and Custom Template.

     • The permission administrator role includes permissions for Enterprise Security, Exploratory Analysis, Metric Watch, Subscription Management, Self-Service Data Retrieval, dataset (Use), open API, Data Service, and embedded analytics.

     • The general user role includes permissions for Metric Watch, Subscription Management, Self-Service Data Retrieval, open API, Data Service, and embedded analytics.

3. Add users to a role.

   • On the role management page, add users to the role as shown in the following figure.

     

     After you click Add User, the selected users appear in the Role Members list. You can use the user type filter to quickly view users of a specific type, or continue selecting users from the list on the right.

     

   • You can switch to the User Group tab to select members from multiple user groups and add them in batches.

     

     You can expand a user group (①), select all users in the current user group (②), or select specific users from the user group (③).

     

     After you click Add User, the selected users appear in the Role Members list.

4. Remove users from a role.

   • In the Role Members list, hover over the user, click the icon in the upper-right corner, and click OK in the Unassign organization role dialog box.

     

   • You can also remove users in batches as shown in the figure.

     

5. Change user roles in batches.

   1. In the Role Members list, open the Batch Change Roles page as shown in the following figure.

      

   2. On the Batch Change Roles page, select the new role under Change to and click OK.

      

Workspace roles

1. Create a workspace role.

   On the role management page, create a workspace role as shown in the following figure.

   

2. Configure functional permissions.

   On the role management page, configure the functional permissions for the role as shown in the following figure.

   

   Note

   • By default, a new workspace role has view permissions for all modules. You can grant or revoke permissions for different modules, including create (edit) permissions, and use permissions for datasets and data sources.

   • You cannot modify the functional permissions of predefined workspace roles.

     • The workspace administrator has create (edit), use, and view permissions for all modules. This role has the highest level of permissions within the workspace and can manage other members' permissions and assets.

     • The workspace developer has create (edit), use, and view permissions for all modules.

     • The workspace analyst has create (edit) and view permissions for Data Portal, dashboard, data screen, spreadsheet, ad hoc analysis, and Self-Service Data Retrieval modules. This role also has view permissions for Data Entry and data sources, as well as use and view permissions for datasets.

     • The workspace viewer has view permissions for all modules.

3. Add users to a role.

   The Role Members list is empty for a newly created role. Add users from the Workspace Members and Information page.

   

   • Navigate to the Workspace Members and Information page and add users to the role as shown in the following figure.

     

   • On the Add Workspace Member page, select the Members and their Workspace Roles.

     You can add Users and User Groups as members.

     

     For more information, see Add a workspace member.

   • After you click OK, the users are added to the workspace.

     

   • The added users now appear in the Role Members list on the role management page for the corresponding workspace role. You can filter by user type to quickly view users of that type.

     

4. Remove users from a role.

   On the workspace management > Workspace Members and Information > Member Management page, click the icon next to the user to remove them.

   

   For more information, see Delete a workspace member.

Use case 1: Custom data screen administrator

Learn how to use a custom role to define an employee's permissions and restrict BI feature access to their designated scope.

Background

John, an employee in the marketing department, needs to use data screens for presentations but should not access other features.

Procedure

If you are a new customer, assign the appropriate role to John by following these steps:

1. As shown in the figure, create a workspace. In this example, the workspace is named "Marketing Presentation Workspace".

   

2. Create a workspace role named "data screen admin".

   

   Configure this custom role with create (edit) permissions for data screens and use permissions for datasets and data sources.

   

3. On the Workspace Management page, add John to the "Marketing Presentation Workspace" and assign him the "data screen admin" role.

   

Now, John can only see and use the data screen module, limiting his access to BI features relevant to his duties.

If you are an existing customer:

John's current permissions: He is a member of the workspace with the general user organization role and the workspace developer role. He can see all functional modules in the workspace and can create and edit all assets.

Assign the appropriate role to John by following these steps:

1. Create a workspace role named "data screen admin".

   

   Configure this custom role with create (edit) permissions for data screens and use permissions for datasets and data sources.

   

2. On the Workspace Members and Information page, change John's role from "workspace developer" to "data screen admin".

   

Now, John can only see and use the data screen module, limiting his access to BI features relevant to his duties.

Use case 2: Custom Intelligent O&M engineer

Learn how to use a custom role to grant an employee Intelligent O&M permissions, restricting their access to operations and maintenance features within a designated scope.

Background

Jane is responsible for system operations and needs to monitor performance logs without accessing business data. Create a custom role for her with only Intelligent O&M permissions.

Procedure

1. Go to Organization Management > User Management > role management, and click the icon to create a custom organization role. You can set a custom role name, such as "Intelligent O&M engineer".

2. Select the newly created Intelligent O&M engineer role. In the functional permissions list on the right, select the Intelligent O&M permission. Users assigned this role can then view all organizational data, including audit logs and data lineage analysis.

3. In User Management, find the user Jane and assign her the Intelligent O&M engineer organization role.

4. When Jane logs in to Quick BI, she will see the Intelligent O&M menu under Organization Management, which includes Monitoring, audit log, Statistical Analysis, Performance Analysis, and data lineage analysis.

Permission priority

The following two scenarios explain the logic of permission priority.

• Scenario 1:

  • Existing permissions: John is a member of Workspace A. He has the general user organization role and the workspace developer role. He can see all functional modules in Workspace A and can create or edit assets such as dashboards, spreadsheets, data screens, data sources, and datasets.

    

  • Permission change

    • An organization administrator creates a new workspace role named dashboard no-access. This role has no create (edit) or view permissions for the dashboard module, as shown in the following figure.

      

  • On the Workspace Members and Information page, the administrator changes John's role from workspace developer to the dashboard no-access role.

  • As a result, John can no longer see the dashboard entry in Workspace A or perform any dashboard operations. His dashboard permissions in this workspace are revoked.

    

This shows that functional permissions override resource permissions.

• Scenario 2:

  • Existing permissions

    • John is a member of Workspace A. He has the general user organization role and the workspace analyst role.

    • He can see all directories in Workspace A but cannot manage data sources or datasets. He can only manage reports that he created himself.

    • Additionally, John has been granted edit permissions for three specific reports created by another user, Alex, in Workspace A.

  • Permission change

    • On the Workspace Members and Information page, the administrator changes John's role from workspace analyst to dashboard admin.

    • The dashboard admin role has the following functional permissions.

      

    • Now, John can only see dashboards in Workspace A. He can manage his own reports and the three reports for which Alex granted him permissions.

      

This shows that functional permissions are constrained by resource permissions.