Add documentation on permissions model

This commit is contained in:
Arik Fraimovich 2016-04-17 09:45:52 +03:00
parent a98c45f649
commit 6db399893b
2 changed files with 35 additions and 1 deletions

View File

@ -5,7 +5,6 @@ Usage
:maxdepth: 2
:glob:
usage/maintenance.rst
usage/*

View File

@ -0,0 +1,35 @@
Permissions Model
#################
In version 0.9.0 we introduced a new permissions model based on groups. Each user by default joins the ``Default`` group, but
can be a member of any number of groups.
Group membership defines the actions you're allowed to take (although currently there is no UI to edit group action permissions),
but also what data sources you have access to (for this we have UI).
How does it work?
=================
* Each user belongs to one or more groups. By default each user joins the ``Default`` group. So the common
data sources, should be associated with this group.
* Each data source will be associated with one or more groups. Each connection to a group will define,
whether this group has full access to this data source (view existing queries and run new ones) or view only access,
which allows only viewing existing queries and results.
* Any dashboard can contain visualizations from any data source (as long as the creating user has access to them). When
a user who doesn't have access to some visualization (because he doesn't have access to the data source) opens a dashboard,
he will see that there is a visualization there but won't see the details.
.. figure:: https://cloud.githubusercontent.com/assets/71468/12002946/dc5032ca-ab16-11e5-90e7-aae9234a596b.png
Dashboard widget with a visualization the user doesn't have access to.
In current implementation all the users see a list of all the dashboards. Once `pull request #957 <https://github.com/getredash/redash/pull/957>`__
gets merged, we will filter out dashboards from the list that the user has no access to any of their widgets.
What if I want to limit the user to only some tables?
=====================================================
The idea is to leverage your database's security model, and hence create a user with access to the tables/columns you
want to give access to. Create a data source that is using this user and then associate it with a group of users who need
this level of access.