Skip to content

Complete redo of permissions in Redash #3284

Description

@arikfr

This is a first draft to describe this project. We invite interested parties to share their thoughts. As we progress with better planning this, I will update the issue description and add relevant sub issues for the steps.


Up until now, access to data in Redash was governed by access to the data source which the data came from. It made sense as a good default, especially if we want to promote data democracy. However, it introduces many challenges in less trivial use cases, for example:

  • You want to share high level revenues KPIs dashboard with everyone, but give access to the raw data only to a limited group of people.
  • You want to share a few dashboards with your investors without giving them access to all your data.

Today, you can share a single query using the embed link or a whole dashboard using the share link. This is currently limited only to queries/dashboards without parameters, as the latter requires access to run any query on the underlying data source.

The goal of this project is to redo our permissions model and introduce safety to parameters execution, to support sharing a query or dashboard with anyone users choose - internal or external.

This is a huge change in how Redash works and will be implemented in steps:

  1. Add support for "feature detection", to allow for the application to decide whether a specific object can be shared or not. We will start with disabling current sharing options (embed/shared link) when the object uses parameters.
  2. Add support for safe execution of parameters: Move parameters merging to the backend and make it safe #2904
  3. Add query results API that is referenced through the query itself.
  4. Add support for sharing queries/dashboards with other users, through the current permissions dialog.
  5. Add support for a public link/access to an object, which will replace the current share/embed features in queries/dashboards.
  6. Add an API to create shareable links for objects with some parameters predefined (to allow Embedded Analytics use cases).

Some things to consider:

  • What happens with an object that was shared already when you add a parameter?
  • Add a concept of workspaces/teams instead of groups? So anything you create in this workspace has some default permissions? Relevant: Allow users to edit other's queries and dashboards #2397.
  • Until now you had to create data sources of type Query Results, URL, CSV, etc for to purpose of managing permissions. But once we have permissions decoupled from data sources, we can have all these data source types as built in types, so you can use them to load data into Redash and then decide who you share it with. (related discussion)
  • Query's query_hash is incorrect for queries with parameters #1909 is somewhat related here.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions