BI studio permissions

Effective permission management in Axelor BI Studio is essential for controlling access to features and ensuring secure, consistent usage. Administrators can define which users or groups have access to specific resources, view data, and perform actions. This guide provides a comprehensive overview of managing permissions in Axelor BI Studio.

Types of Permissions

Permissions in Axelor BI Studio are categorized as follows:

  • Dashboard Access: Grants users the ability to view or interact with specific dashboards.

  • Dashboard Creation and Modification: Allows users to create, edit, or delete dashboards.

  • Data Source Access: Controls access to various data sources within Axelor BI Studio.

  • Query Execution: Enables users to run queries on connected databases and view results in reports or dashboards.

  • User and Role Management: Provides access to administrative tools for adding, modifying, or removing users, as well as managing their roles and permissions.

  • Data Download and Export: Allows users to export reports and results in various formats (CSV, Excel, PDF, etc.)

Role Management

Roles in Axelor BI Studio help organize permissions by assigning specific privileges to groups of users. While the platform includes predefined roles, administrators can create custom roles to meet the organization’s specific needs.

  • Predefined Roles: Axelor BI Studio includes basic roles such as Administrator, Gamma, Alpha, etc. each with a predefined set of permissions.

  • Custom Role Creation: Administrators can create custom roles to meet specific needs. For example, a Marketing Manager role might have access to marketing reports but not to user management.

  • Role Assignment: Roles can be assigned to individual users or groups, ensuring structured access based on responsibilities within the organization.

Assign Permissions to a Role

Permissions can be assigned in a granular manner to each role, allowing administrators to grant specific rights, such as:

  • Access to specific dashboards: Users can be granted or denied access to particular dashboards based on their role.

  • Access Control on Data Sources: Administrators can define who can access certain data sources, with either read-only or write permissions.

  • Permissions on Visualizations: Some visualizations may require additional permissions, such as modifying filters or adding new dimensions and measures.

User Administration

Administrators can manage Axelor BI Studio users through an administrative dashboard, where they can:

  • Add User: Add new users by entering their basic information (name, email, etc.)

  • Edit User: Modify user details, assign new roles, or adjust permissions.

  • Delete User: Remove users from the platform when necessary.

  • User Activity Tracking: Monitor user activity to see who is accessing what and when.

Data Permission Models

Axelor BI Studio provides tools to configure data access permissions by:

  • Data Views: Grant or restrict access to specific views (tables, charts, etc.) based on the user’s role.

  • Data Filters: Administrators can set dynamic filters to restrict the display of certain data based on the logged-in user.

Default Roles

Admin

Admin users have all possible rights, including the ability to grant or revoke rights for other users and modify their slices and dashboards.

Alpha

Alpha users have access to all data sources but cannot grant or revoke access for other users. They are also restricted to modifying only the objects they own. Alpha users can add and modify data sources.

Gamma

Gamma users have limited access. They can only consume data from sources they’ve been granted access to via an add-on role. They can access slices and dashboards created from the data sources they have access to. Currently, Gamma users cannot edit or add data sources. They are primarily content consumers, although they can create slices and dashboards. Additionally, when Gamma users view the list of dashboards and slices, they will only see objects they have access to.

sql_lab

The sql_lab role grants access to SQL Lab. Note that while Admin users have access to all databases by default, Alpha and Gamma users must be granted access to each database individually.

Public

To allow non-logged-in users to access certain features of Superset, you can use the PUBLIC_ROLE_LIKE configuration parameter and assign it to another role whose permissions you want to inherit.

For example, by setting PUBLIC_ROLE_LIKE = "Gamma" in your superset_config.py file, you are giving the Public role the same set of permissions as the Gamma role. This is useful if you want to allow anonymous users to view dashboards. However, explicitly assigning permissions to specific datasets is still required, meaning you need to edit the Public role and manually add public data sources to that role.

Reader

A role in BI Studio with permissions to fetch, embed, and import dashboards and slices.

RLS: Row Level Security

Using Row Level Security filters (in the Security menu), you can create filters that are assigned to a specific table and a set of roles.

For example, if you want Finance team members to only access rows where department = "finance", you can:

  • Create a Row Level Security filter with the condition department = "finance".

  • Assign this filter to the Finance role and the table. The condition field, which can contain arbitrary text, is added to the WHERE clause of the generated SQL query.

  • For instance, you could create a filter for the last 30 days with a condition like: date_field > DATE_SUB(NOW(), INTERVAL 30 DAY).

  • Multiple conditions can also be applied, such as client_id = 6 AND advertiser="foo".

  • All relevant Row Level Security filters will be combined behind the scenes (with the SQL clauses joined using AND statements). This means that it’s possible to create a situation where two roles conflict, effectively limiting a subset of an empty result.

For example, the filters client_id = 4 and client_id = 5 applied to a role will result in a query as client_id = 4 AND client_id = 5, which can never be true.