Skip to content
Snippets Groups Projects
Unverified Commit d0e03251 authored by Jeff Bruemmer's avatar Jeff Bruemmer Committed by GitHub
Browse files

docs - updated permissions (#17882)

parent 538a5e6c
No related branches found
No related tags found
No related merge requests found
Showing
with 194 additions and 68 deletions
## Setting Data Access Permissions
# Permissions overview
There are always going to be sensitive bits of information in your databases and tables, and thankfully Metabase provides a simple way to ensure that people on your team only see the data they’re supposed to.
### How permissions work in Metabase
## How permissions work in Metabase
Metabase uses a group-based approach to set permissions and restrictions on your databases and tables. At a high level, to set up permissions in your Metabase instance you’ll need to create one or more groups, add members to those groups, and then choose what level of database and SQL access those groups should have.
Metabase uses a group-based approach to set permissions. At a high-level, you can set permissions on two things: data and collections. **Data permissions** are about defining what raw data groups are allowed to use when creating new questions (i.e., self-service analytics). **Collection permissions** determine what existing dashboards and questions groups can see. On some plans, you can also sandbox data, which "filters" what data people can see when they view a particular questions, such as limiting the rows or columns they can see.
A user can be a member of multiple groups, and if one of the groups they’re in has access to a particular database or table, but another group they’re a member of does not, then they **will** have access to that database.
You can set permissions on:
In addition to setting permissions on your databases and tables, you can also [set access permissions on the collections](06-collections.md) where your dashboards, questions, and pulses are saved. Collection permissions can be set and edited from the collection itself, or the Admin Panel.
- [Databases connected to Metabase][data-permissions]
- [Tables and schemas in those databases][table-permissions]
- [Rows and columns of a table][data-sandboxing] (only on some plans)
- [Collections of questions and dashboards][collections]
### Groups
For plans that include [SQL Snippet Folders][sql-snippet-folders], you can also set permissions on those folders.
To view and manage your groups, go to the Admin Panel, click on the People section, and then click on Groups from the side menu.
To determine who has access to what, you’ll need to create one or more groups, choose which level of access that group has to different databases, collections, and so on, then add people to that group.
![Groups](images/groups.png)
#### Special default groups
You’ll notice that you already have two default groups: Administrators and All Users. These are special groups that can’t be removed.
### Key points regarding permissions
You’ll also see that you’re a member of the **Administrators** group — that’s why you were able to go to the Admin Panel in the first place. So, to make someone an admin of Metabase you just need to add them to this group. Metabase admins can log into the Admin Panel and make changes there, and they always have unrestricted access to all data that you have in your Metabase instance. So be careful who you add to the Administrator group!
The **All Users** group is another special one. Every Metabase user is always a member of this group, though they can also be a member of as many other groups as you want. We recommend using the All Users group as a way to set default access levels for new Metabase users. If you have [Google single sign-on](10-single-sign-on.md) enabled, new users who join that way will be automatically added to the All Users group.
Some key things to keep in mind when thinking about permissions in Metabase:
#### An important note on the All Users group
- Permissions are granted to groups, not people.
- People can be in more than one group.
- If a person is in multiple groups, they will have the most permissive access granted to them across all of their groups. For example, if they are part of three groups, and two of those groups don't have permissions to a database, but the third group they're in can query that database, then that person will have access to that database.
As we mentioned above, a user is given the _most permissive_ setting she has for a given database/schema/table across _all_ groups she is in. Because of that, it is important that your All Users group should never have _greater_ access for an item than a group for which you're trying to restrict access — otherwise the more permissive setting will win out. This goes for both data access as well as [collection permission](06-collections.md) settings.
## Groups
If you’ve set up the [Slack integration](09-setting-up-slack.md) and enabled [Metabot](../users-guide/11-metabot.md), you’ll also see a special **Metabot** group, which will allow you to restrict which questions your users will be able to access in Slack via Metabot.
#### Managing groups
From the Groups section, click the `Add a group` button to create a new group. We recommend creating groups that correspond to the teams your company or organization has, such as Human Resources, Engineering, Finance, etc. Click the X icon to the right of a group in the list to remove it (remember, you can’t remove the special default groups). By default, newly created groups don’t have access to anything.
Click into a group and then click `Add members` to add users to that group. Click on the X on the right side of a group member to remove them from that group. You can also add and remove users from groups from the People list using the dropdown in the Groups column.
To view and manage your groups, go to the __Admin Panel__ > __People__, and then click on __Groups__ from the side menu.
### Permissions view
Now that you have some groups, you’ll want to control their data access by going to the `Permissions` section of the Admin Panel. You’ll see an interactive table that displays all of your databases and all of your groups, and the level of access your groups have for each database.
![Permissions view](images/permissions.png)
You can click on any cell in the table to change a group’s access level. When you’re done making your changes, just click the `save changes` button in the top-right, and you’ll see a confirmation dialog summarizing the changes.
![Changing access level](images/change-access.png)
![Groups](images/groups.png)
At the database level, there are two different kinds of access you can set: data access, and SQL (or native query) access.
### Special default groups
#### Data access
Every Metabase has two default groups: Administrators and All Users. These are special groups that can’t be removed.
- **Unrestricted access:** 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.
- **Limited access:** can only access the tables that you explicitly select within namespaces/schemas you explicitly select. If a new table gets added to this database in the future, access to it will not automatically be given. Saved questions based on tables the user doesn’t have access to won’t show up in the list of saved questions, dashboard cards based on those questions won’t appear, and they won’t be able to ask new questions about those tables. If every card on a dashboard is hidden for a user, then that dashboard won’t be shown to them in the dashboard list.
- **No access:** can’t see anything based on data contained in this database. Won’t see saved questions based on tables contained in this database, and won’t be able to ask new questions about those tables.
#### Administrators
#### SQL (or native query) access
You’re a member of the **Administrators** group — that’s why you were able to go to the Admin Panel in the first place. To make someone an admin of Metabase, you just need to add them to this group. Metabase admins can log into the Admin Panel and make changes there, and they always have unrestricted access to all data that you have in your Metabase instance. So be careful who you add to the Administrator group!
- **Write raw queries:** can write new SQL/native queries using the SQL editor. 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.
- **No access**: can't view, write, or edit SQL/native queries. Users 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 when composing custom questions in the notebook editor.
#### All users
If you select `Limit access` for one of your databases, your view will change to show the contents of that database. If the database utilizes namespaces or schemas, you’ll see a list of all the schemas in the database, and the level of data access each group has for them. Similarly, if you select `Limit access` on one of your schemas, you’ll drill down a level and see all the tables within it. From these views, you can navigate back by using the breadcrumb links in the top-left, and you can always drill down into a database or schema using the link under its name in the left column.
The **All Users** group is another special one. Every Metabase user is always a member of this group, though they can also be a member of as many other groups as you want. We recommend using the All Users group as a way to set default access levels for new Metabase users. If you have [Google single sign-on](10-single-sign-on.md) enabled, new users who join that way will be automatically added to the All Users group.
![Table permissions](images/table-permissions.png)
As we mentioned above, a person is given the _most permissive_ setting she has for a given database/schema/table across _all_ groups she's in. Because of that, it's important that your All Users group should never have _greater_ access for an item than a group for which you're trying to restrict access — otherwise the more permissive setting will win out. This goes for both data access as well as [collection permission](06-collections.md) settings.
Data access levels for schemas follows the same pattern as for databases:
### Managing groups
- **Unrestricted access:** can access all tables in this schema, including any tables that might get added in the future.
- **Limited access:** can only access the tables that you explicitly select.
- **No access:** can’t access any tables in this schema.
#### Creating a group and adding people to it
Lastly, data access levels for tables are almost exactly the same as well:
From the Admin > Groups tab, click the **Add a group** button to create a new group. We recommend creating groups that correspond to the teams your company or organization has, such as Human Resources, Engineering, Finance, and so on. By default, newly created groups don’t have access to anything.
- **Unrestricted access:** can ask questions about this table and see saved questions and dashboard cards using this table.
- **No access:** can’t ask questions about this table or see saved questions or dashboard cards using this table.
Click into a group and then click `Add members` to add users to that group. Click on the X on the right side of a group member to remove them from that group. You can also add and remove users from groups from the People list using the dropdown in the Groups column.
_Note: you’ll notice that tables don’t have the option for limited access. If you need to set column-level or row-level data permissions, check out the [data sandboxing](https://www.metabase.com/docs/latest/enterprise-guide/data-sandboxes.html) feature of the [Enterprise Edition](https://www.metabase.com/enterprise/)._
#### Removing a group
For more, check out our [Guide to data permissions](https://www.metabase.com/learn/organization/organization/data-permissions.html).
To remove a group, click the X icon to the right of a group in the list to remove it (remember, you can’t remove the special default groups).
### A note about Pulses
## Further reading
Pulses act a bit differently with regard to permissions. When a user creates a new Pulse, they will only have the option to include saved questions that they have permission to view. Note, however, that they are not prevented from emailing that Pulse to anyone, or posting that Pulse to a Slack channel (if you have Slack integration set up), regardless of the recipients’ permissions. Unlike dashboards, where individual cards are blocked based on a user’s permissions, a Pulse will always render all of its cards.
Checkout our track on [Permissions][permissions] in Learn Metabase.
---
## Next: collections
Metabase lets you create and set permissions on collections of dashboards and questions. [Learn how](06-collections.md).
## Next: Data permissions
Metabase lets you [set permissions on databases and their tables][data-permissions].
[collections]: 06-collections.md
[dashboard-subscriptions]: ../users-guide/dashboard-subscriptions.md
[data-permissions]: data-permissions.md
[pulses]: ../users-guide/10-pulses.md
[data-sandboxing]: ../enterprise-guide/data-sandboxes.md
[permissions]: /learn/permissions/
[sandbox-columns]: /learn/permissions/data-sandboxing-column-permissions.html
[sandbox-rows]: /learn/permissions/data-sandboxing-row-permissions.html
[slack-integration]: 09-setting-up-slack.md
[sql-snippet-folders]: ../enterprise-guide/sql-snippets.md
[table-permissions]: data-permissions.md#table-permissions
\ No newline at end of file
## Creating Collections for Your Saved Questions
# Collection permissions
![Collection detail](images/collections/collection-detail.png)
Collections are a great way to organize your dashboards, saved questions, and pulses, and to decide who gets to see and edit things. Collections could be things like, "Important Metrics," "Product Team," "Marketing KPIs," or "Questions about users." Collections can even contain other collections, allowing you to create an organizational structure that fits your team. You can also choose which user groups should have what level of access to your collections (more on that below).
Metabase starts out with a default top-level collection which is called "Our analytics," which every other collection is saved inside of.
Metabase starts out with a default top-level collection which is called __Our analytics__, which every other collection is saved inside of.
This page will teach you how to create and manage your collections. For more information on organizing saved questions and using collections, [check out this section of the User's Guide](../users-guide/06-sharing-answers.md).
### Creating and editing collections
If a user has Curate access for a collection, they can create new sub-collections inside it and edit the contents of the collection. From the detail view of any collection, click on the `Create a collection` button to make a new one. Give your collection a name, choose where it should live, and give it a description if you'd like.
![Create collection](images/collections/create-collection.png)
......@@ -16,6 +17,7 @@ If a user has Curate access for a collection, they can create new sub-collection
By default, new collections will have the same permissions settings as the collection it was created in (its "parent" collection), but you can change those settings from the Edit menu.
### Pinning things in collections
![Pins](images/collections/pinned-items.png)
One great feature in Metabase is that you can pin the most important couple of items in each of your collections to the top. Pinning an item in a collection turns it into a big, eye-catching card that will help make sure that folks who are browsing your Metabase instance will always know what's most important.
......@@ -23,10 +25,11 @@ One great feature in Metabase is that you can pin the most important couple of i
Any user with curate permissions for a collection can pin items in it, making it easy to delegate curation responsibilities to other members of your team. To pin something, you can either click and drag it to the top of the page, or click on its menu and choose the pin action. (Note that collections themselves can't be pinned.)
### Setting permissions for collections
Collection permissions are similar to [data access permissions](05-setting-permissions.md). Rather than going to the Admin Panel, you set permissions on collections by clicking on the lock icon in the top-right of the screen while viewing the collection and clicking on `Edit permissions`. Only Administrators can edit collection permissions. Each [user group](05-setting-permissions.md) can have either View, Curate, or No access to a collection:
- **Curate access:** the user can edit, move, and archive items saved in this collection, and can save or move new items into it. They can also create new sub-collections within this collection. In order to archive a sub-collection within this collection, they'll need to have Curate access for it and any and all collections within it.
- **View access:** the user can see all the questions, dashboards, and pulses in the collection. If the user does not have permission to view some or all of the questions included in a given dashboard or pulse then those questions will not be visible to them; but any questions that are saved in this collection *will* be visible to them, *even if the user doesn't have access to the underlying data used to in the question.*
- **View access:** the user can see all the questions, dashboards, and pulses in the collection. If the user does not have permission to view some or all of the questions included in a given dashboard or pulse then those questions will not be visible to them; but any questions that are saved in this collection _will_ be visible to them, _even if the user doesn't have access to the underlying data used to in the question._
- **No access:** the user won't see this collection listed, and doesn't have access to any of the items saved within it.
![Permissions](images/collections/collection-permissions.png)
......@@ -35,12 +38,13 @@ If you want to see the bigger picture of what permissions your user groups have
![Full permissions grid](images/collections/permission-grid.png)
Just like with data access permissions, collection permissions are *additive*, meaning that if a user belongs to more than one group, if one of their groups has a more restrictive setting for a collection than another one of their groups, they'll be given the *more permissive* setting. This is especially important to remember when dealing with the All Users group: since all users are members of this group, if you give the All Users group Curate access to a collection, then *all* users will be given Curate access for that collection, even if they also belong to a group with *less* access than that.
Just like with data access permissions, collection permissions are _additive_, meaning that if a user belongs to more than one group, if one of their groups has a more restrictive setting for a collection than another one of their groups, they'll be given the _more permissive_ setting. This is especially important to remember when dealing with the All Users group: since all users are members of this group, if you give the All Users group Curate access to a collection, then _all_ users will be given Curate access for that collection, even if they also belong to a group with _less_ access than that.
### Permissions and sub-collections
One nuance with how collections permissions work has to do with sub-collections. A user group can be given access to a collection located somewhere within one or more sub-collections *without* having to have access to every collection "above" it. E.g., if a user group had access to the "Super Secret Collection" that's saved several layers deep within a "Marketing" collection that the group does *not* have access to, the "Super Secret Collection" would show up at the top-most level that the group *does* have access to.
To learn more, check out our Learn article on [working with collection permissions](https://www.metabase.com/learn/organization/organization/collection-permissions.html).
One nuance with how collections permissions work has to do with sub-collections. A user group can be given access to a collection located somewhere within one or more sub-collections _without_ having to have access to every collection "above" it. E.g., if a user group had access to the "Super Secret Collection" that's saved several layers deep within a "Marketing" collection that the group does _not_ have access to, the "Super Secret Collection" would show up at the top-most level that the group _does_ have access to.
To learn more, check out our Learn article on [working with collection permissions][working-with-collection-permissions].
### Personal collections
......@@ -49,13 +53,38 @@ Each user has a personal collection where they're always allowed to save things,
A personal collection works just like any other collection except that its permissions can't be changed. If a sub-collection within a personal collection is moved to a different collection, it will inherit the permissions of that collection.
### Archiving collections
Users with curate permission for a collection can archive collections. Click the edit icon in the top-right of the collection screen and select `Archive this collection` to archive it. This will also archive all questions, dashboards, pulses, and all other sub-collections and their contents. Importantly, this will also remove any archived questions from all dashboards and Pulses that use them.
**Note:** the "Our analytics" collection and personal collections can't be archived.
You can always *unarchive* things by clicking on the More menu from a collection and selecting `View the archive`, then clicking the un-archive button next to an archived item. Questions within archived collections are not individually listed in the archive, so if you want to unarchive a specific question from an archived collection, you have to unarchive that whole collection.
You can always _unarchive_ items. In the Collections list sidebar, at the bottom, click on __View archive__. Search for the item you'd like to unarchive (you'll either need to scroll down the page, or use the browser's find in page functionality, as archived items won't appear in Metabase's search results). Select the open box with an up arrow icon to "Unarchive this".
## Dashboard subscriptions
You don't explicitly set permissions on [dashboards subscriptions][dashboard-subscriptions], as the subscriptions are a feature of a dashboard. And access to dashboards falls under Collection permissions.
Here's what you can do with dashboard subscriptions based on Collection permissions for the collection the dashboard is in:
- **Curate access**: You can view and edit all subscriptions for the dashboard, including subscriptions created by other people.
- **View access**: You can view all subscriptions for that dashboard. You can also create subscriptions and edit ones that you’ve created, but you can’t edit ones that other people created. You can also unsubscribe from a subscription that somebody else created.
- **No access**: You can’t view any of the dashboard's subscriptions, including, for example, subscriptions you created before an administrator revoked your access to the collection.
### Metabot group
If you’ve set up the [Slack integration][slack-integration] and enabled Metabot, you’ll also see a special Metabot group when assigning permissions to collections, which will allow you to restrict which questions your users will be able to access in Slack via Metabot.
## A note about Pulses
If you're using [Pulses][pulses], we recommend switching to [dashboard subscriptions][dashboard-subscriptions].
Pulses act a bit differently with regard to permissions. When a user creates a new Pulse, they will only have the option to include saved questions that they have permission to view. Note, however, that they are not prevented from emailing that Pulse to anyone, or posting that Pulse to a Slack channel (if you have Slack integration set up), regardless of the recipients’ permissions. Unlike dashboards, where individual cards are blocked based on a user’s permissions, a Pulse will always render all of its cards.
---
## Next: sharing and embedding with public links
Want to share certain dashboards or questions with the world? You can do that with [public links](12-public-links.md).
[working-with-collection-permissisons]: /learn/permissions/collection-permissions.html
\ No newline at end of file
# Data permissions
This page covers permissions for databases and tables. If you haven't already, check out our [Permissions overview][permissons-overview].
## Permissions view
Now that you have some groups, you’ll want to control their data access by going to the **Permissions** section of the Admin Panel. You’ll see an interactive table that displays all of your databases and all of your groups, and the level of access your groups have for each database.
![Permissions view](images/permissions.png)
You can click on any cell in the table to change a group’s access level. When you’re done making your changes, just click the `save changes` button in the top-right, and you’ll see a confirmation dialog summarizing the changes.
### 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.
### Granular access
__Granular access__ allows administrators to explicitly set access to tables or schemas within a database. In practice, this means that:
- Admins can set the groups 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.
### 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.
### Block
{% include plans-blockquote.html %}
__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.
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.
### 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. 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.
Members in groups without native query editing access can't view, write, or edit SQL/native queries. People who are not 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 when composing custom questions in the notebook editor.
## 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.
### 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.
### 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.
### Sandboxed access to the table
Only available in paid plans, Sandboxed access to a table can restrict access to columns and rows of a table. Check out [data sandboxing][data-sandboxing].
## Permissions and dashboard subscriptions
You don't explicitly set permissions on [dashboards subscriptions][dashboard-subscriptions], as the subscriptions are a feature of a dashboard. Which means that What you can do j
If a person is in a group that has __Curate access__ to the collection containing the dashboard, they can view and edit all subscriptions for the dashboard, including subscriptions created by other people.
If a group has read-only access to a dashboard (based on its collection permissions), they can view all subscriptions for that dashboard. They can also create subscriptions and edit ones that they’ve created, but they can’t edit ones that other users created. (That last point is enforced by the BE only, the FE still needs to be updated to show the subscriptions as read-only.)
If a group has no access to a dashboard, they can’t view any of its subscriptions, including ones that they may have created in the past, prior to having access revoked.
If you have read-only access to a dashboard, you can also unsubscribe yourself from a subscription that somebody else created via the new page in account settings.
## A note about Pulses
If you're using [Pulses][pulses], we recommend switching to [dashboard subscriptions][dashboard-subscriptions].
Pulses act a bit differently with regard to permissions. When someone creates a new Pulse, they will only have the option to include saved questions that they have permission to view. Note, however, that they are not prevented from emailing that Pulse to anyone, or posting that Pulse to a Slack channel (if you have Slack integration set up), regardless of the recipients’ permissions. Unlike dashboards, where individual cards are blocked based on a person's permissions, a Pulse will always render all of its cards.
## Further reading
- [Guide to data permissions](https://www.metabase.com/learn/organization/organization/data-permissions.html).
- [Data sandboxing: setting row-level permissions][sandbox-rows]
- [Advanced data sandboxing: limiting access to columns][sandbox-columns]
---
## Next: Collection permissions
Metabase lets you create and set permissions on collections of dashboards and questions. [Learn how][collections].
[collections]: 06-collections.md
[dashboard-subscriptions]: ../users-guide/dashboard-subscriptions.md
[data-sandboxing]: ../enterprise-guide/data-sandboxes.md
[permissions-overview]: 05-setting-permissions.md
[pulses]: ../users-guide/10-pulses.md
[sandbox-columns]: /learn/permissions/data-sandboxing-column-permissions.html
[sandbox-rows]: /learn/permissions/data-sandboxing-row-permissions.html
[sql-snippet-folders]: ../enterprise-guide/sql-snippets.md
docs/administration-guide/images/change-access.png

30.9 KiB

docs/administration-guide/images/permissions.png

23.7 KiB | W: | H:

docs/administration-guide/images/permissions.png

223 KiB | W: | H:

docs/administration-guide/images/permissions.png
docs/administration-guide/images/permissions.png
docs/administration-guide/images/permissions.png
docs/administration-guide/images/permissions.png
  • 2-up
  • Swipe
  • Onion skin
docs/administration-guide/images/table-permissions.png

50.1 KiB

## Sandboxing your data
Data sandboxes are a powerful and flexible permissions tool in Metabase Enterprise Edition that allow you to grant filtered access to specific tables.
Data sandboxes are a powerful and flexible permissions tool in Metabase Enterprise Edition that allow you to grant filtered access to specific tables. If you haven't already, check out our [overview of how permissions work in Metabase][permissions-overview].
Say you have users who you want to be able to log into your Metabase instance, but who should only be able to view data that pertains to them. For example, you might have some customers or partners who you want to let view your Orders table, but you only want them to see their orders. Sandboxes let you do just that.
......@@ -47,9 +47,7 @@ Next we’ll see a worksheet that will ask us how we want to filter this table f
![Sandbox settings](images/sandboxing/select-user-attribute.png)
We’ll click Done, then we’ll click Save Changes at the top of the screen to save the changes we’ve made to our permissions. If we ever want to edit how this table should be filtered for users in this group, we can just click on the blue box and select “Edit sandboxed access.”
![Edit access](images/sandboxing/edit-sandboxed-access.png)
We’ll click Done, then we’ll click Save Changes at the top of the screen to save the changes we’ve made to our permissions. If we ever want to edit how this table should be filtered for users in this group, we can just click on the __Data access__ dropdown for that group and select __Edit sandboxed access__.
To test this out, we’ll open up a new incognito browser window and log in with our test user account. We’ll click on the Sample Dataset on the home page and then pick the Orders table. As you can see here, this user correctly only sees orders where the User ID column is equal to 1, because that’s what this user’s user_id attribute is.
......@@ -99,6 +97,21 @@ The filtering question that I'll create will exclude columns that I don't want t
![Filtering question](images/sandboxing/advanced-example-2-filtering-question.png)
And here's the code:
```
SELECT
id,
created_at,
product_id,
quantity,
total,
user_id
FROM
orders
[[WHERE user_id = {%raw%}{{cid}}{%endraw%}]]
```
Going back over to the Permissions section, when I open up the sandboxed access modal and select the second option and select my filtering question, I'll see an additional section which allows me to map the variable I defined in my question with a user attribute:
![Sandboxing options](images/sandboxing/advanced-example-2-sandboxing-options.png)
......@@ -147,4 +160,5 @@ Public questions and dashboards can't be sandboxed. Sandboxing works by filterin
The next section will explain [how to embed](full-app-embedding.md) interactive dashboards and charts, or even whole sections of Metabase within your app.
[permissions]: /learn/permissions/index.html
[permissions-overview]: ../administration-guide/05-setting-permissions.md
[troubleshoot-sandbox]: ../troubleshooting-guide/sandboxing.html
\ No newline at end of file
docs/enterprise-guide/images/sandboxing/advanced-example-2-filtering-question.png

48.7 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/advanced-example-2-filtering-question.png

210 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/advanced-example-2-filtering-question.png
docs/enterprise-guide/images/sandboxing/advanced-example-2-filtering-question.png
docs/enterprise-guide/images/sandboxing/advanced-example-2-filtering-question.png
docs/enterprise-guide/images/sandboxing/advanced-example-2-filtering-question.png
  • 2-up
  • Swipe
  • Onion skin
docs/enterprise-guide/images/sandboxing/advanced-example-2-sandboxing-options.png

90.7 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/advanced-example-2-sandboxing-options.png

228 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/advanced-example-2-sandboxing-options.png
docs/enterprise-guide/images/sandboxing/advanced-example-2-sandboxing-options.png
docs/enterprise-guide/images/sandboxing/advanced-example-2-sandboxing-options.png
docs/enterprise-guide/images/sandboxing/advanced-example-2-sandboxing-options.png
  • 2-up
  • Swipe
  • Onion skin
docs/enterprise-guide/images/sandboxing/change-access-confirm-modal.png

70.6 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/change-access-confirm-modal.png

156 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/change-access-confirm-modal.png
docs/enterprise-guide/images/sandboxing/change-access-confirm-modal.png
docs/enterprise-guide/images/sandboxing/change-access-confirm-modal.png
docs/enterprise-guide/images/sandboxing/change-access-confirm-modal.png
  • 2-up
  • Swipe
  • Onion skin
docs/enterprise-guide/images/sandboxing/edit-sandboxed-access.png

80.4 KiB

docs/enterprise-guide/images/sandboxing/edit-user-details.png

35.1 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/edit-user-details.png

136 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/edit-user-details.png
docs/enterprise-guide/images/sandboxing/edit-user-details.png
docs/enterprise-guide/images/sandboxing/edit-user-details.png
docs/enterprise-guide/images/sandboxing/edit-user-details.png
  • 2-up
  • Swipe
  • Onion skin
docs/enterprise-guide/images/sandboxing/grant-sandboxed-access.png

68.4 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/grant-sandboxed-access.png

228 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/grant-sandboxed-access.png
docs/enterprise-guide/images/sandboxing/grant-sandboxed-access.png
docs/enterprise-guide/images/sandboxing/grant-sandboxed-access.png
docs/enterprise-guide/images/sandboxing/grant-sandboxed-access.png
  • 2-up
  • Swipe
  • Onion skin
docs/enterprise-guide/images/sandboxing/select-user-attribute.png

139 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/select-user-attribute.png

283 KiB | W: | H:

docs/enterprise-guide/images/sandboxing/select-user-attribute.png
docs/enterprise-guide/images/sandboxing/select-user-attribute.png
docs/enterprise-guide/images/sandboxing/select-user-attribute.png
docs/enterprise-guide/images/sandboxing/select-user-attribute.png
  • 2-up
  • Swipe
  • Onion skin
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment