@@ -15,7 +15,7 @@ Now that you have some groups, you’ll want to control their data access by goi
You can set various levels of permissions on a data source, from querying access to managing the database connection.
-[Data access](#data-access)
-[Native querying](#native-querying)
-[Native querying](#native-query-editing)
-[Download results](#download-results)\*
-[Manage data model](#manage-data-model)\*
-[Manage database](#manage-database)\*
...
...
@@ -28,38 +28,47 @@ You can click on any cell in the permissions table to change a group’s access
### Unrestricted access
Members of the group can access data from all tables (within all namespaces/schemas, if your database uses those), including any tables that might get added to this database in the future.
Members of the group can create questions using the graphical query builder on data from all tables (within all namespaces/schemas, if your database uses those), including any tables that might get added to this database in the future. To grant a group the ability to write native/SQL questions, you must additionally set [Native query editing](#native-query-editing) to **Yes**.
### Granular access
**Granular access** allows administrators to explicitly set access to tables or schemas within a database. In practice, this means that:
**Granular access** allows administrators to explicitly set data access to tables or schemas within a database, with "data access" here meaning the ability to create questions using the graphical query builder. In practice, this means that:
- Admins can set the groups access to individual tables to either **Unrestricted**, **No self-service**, or **Sandboxed** access.
- Admins can set the group's access to individual tables to either **Unrestricted**, **No self-service**, or **Sandboxed** access.
- If a new table gets added to this database in the future, the group won't get access to that new table. An administrator would need to explicitly grant access to that table.
Note that [Block](#block-access) access is unavailable for individual tables/schemas. Block is a database-level setting; you can only block the entire database.
### No self-service access
**No self-service** prevents people in a group from creating new ad hoc queries or questions based on this data, or from seeing this data in the Browse Data screen. Groups with this level of access can still see saved questions and charts based on this data in Collections they have access to.
**No self-service** prevents people in a group from using the graphical query builder to create new questions that query that database, or from seeing this database in the Browse Data section of your Metabase. Groups with No self-service access can still see saved questions that query this data if they 1) have access to the appropriate collection, and 2) aren't in a group with [blocked access](#block-access) to the database.
### Block access
{% include plans-blockquote.html feature="Block access" %}
**Block** ensures people can’t ever see the data from this database, regardless of their permissions at the Collection level. So if they want to see a question in a collection that have access to, but that question uses data from a database that's been blocked for that person's group, then they won't be able to see that question.
**Block** ensures people in a group can’t see the data from this database, regardless of their permissions at the collection level.
Even if a question is in a collection that the group has access to, but that question queries a database that is blocked for that group, people in that group won't be able to view that question _unless_ they're in another group with the relevant data permissions. Essentially, what Block does is make collections permissions insufficient to view a question.
If a person in that blocked group belongs to _another_ group that _does_ have the corresponding data access, that more privileged access will take precedence (overruling the block), and they'll be able to view that question.
"Corresponding data access" here refers to whether the saved question was created using the graphical query builder, or the native/SQL editor, as the required permissions to overrule a block differ depending on how the question was created.
Keep in mind people can be in multiple groups. If a person belongs to _another_ group that _does_ have access to that database, that more privileged access will take precedence (overruling the block), and they'll be able to view that question.
- If the question was created using the [graphical query builder](../users-guide/04-asking-questions.md), the person would also need to be in a group with **Unrestricted data access** or **Sandboxed access** to the relevant database (or table) to view that question.
- If the question was created using the [native/SQL editor](../users-guide/writing-sql.md), the person would need to be a member of a group with both **Unrestricted data access** and **Native query editing** set to **YES** to view that question.
### Table permissions
When you select [Granular access](#granular-access) for a database, you'll be prompted to set permissions on the tables (or schemas) within that database. Here you'll have two or three options, depending on your Metabase plan.
When you select [Granular access](#granular-access) for a database, you'll be prompted to set permissions on the tables (or schemas) within that database. Here you'll have some options, which differ depending on your Metabase plan.
#### Unrestricted access to the table
Groups with unrestricted access can ask questions about this table and see saved questions and dashboard cards that use the table.
Groups with unrestricted access can use the [graphical query builder](../users-guide/04-asking-questions.md) to ask questions about this table.
#### No self-service access to the table
Groups with no self-service access to a table can’t access the table at all. They can, however, view questions that use data from that table, provided the group has access to the question's collection.
Groups with no self-service access to a table can’t access the table at all. They can, however, view questions that use data from that table, provided the group has access to the question's collection, and they're not in a group with [blocked access](#block-access) for that table's database.
#### Sandboxed access to the table
...
...
@@ -67,11 +76,11 @@ Groups with no self-service access to a table can’t access the table at all. T
Sandboxed access to a table can restrict access to columns and rows of a table. Check out [data sandboxing][data-sandboxing].
## Native querying
## Native query editing
Members of a group with Native query editing set to Yes can write new SQL/native queries using the [native query editor](https://www.metabase.com/docs/latest/users-guide/writing-sql.html). This access level requires the group to additionally have Unrestricted data access for the database in question, since SQL queries can circumvent table-level permissions.
People who aren't in groups with Native query editing permissions will still be able to view the results of questions created from SQL/native queries, but not the code itself. They also won't see the **View the SQL** button in the query builder.
People in a group without Native query editing permissions will still be able to view the results of questions created from SQL/native queries (though just the results, not the query), provided they 1) have collection access to the question, and 2) the question doesn't query a database that is [blocked](#block-access) for that group.
## Download results
...
...
@@ -114,4 +123,4 @@ This setting defines whether a person can edit the connection settings for the d
