1

Currently re:dash allows you to fork someone else’s query and continue working on it. If you improve their query it would be nice to then merge your changes back into their query as the original query may have been embedded in other sites or added to dashboards.

1 Like
2

How about an alternative in the form of allowing multiple users to edit a query?
I know it’s not the same, but maybe it can be good enough interim solution and easier to implement.

We actually had this feature enabled, but it was half baked and allowed anyone to edit any query and it was missing proper tracking or conflict resolution. If I had to do it again, I would implement it with the following guidelines:

  • The query creator can decide who else can edit his query - either by a user by user basis or by selecting a group.
  • We will use optimistic locking to make sure you don’t override others’ changes. No need for anything fancy in case of conflict - just notify the user of a possible conflict and let him figure out what to do (I think this was the implementation in Confluence, at least in the past).
  • Peewee doesn’t have built-in support for optimistic locking, but someone posted in their issues a reference implementation we can use (one other reason to consider switching away from Peewee).
  • Bonus points: start tracking revision history and allow to revert to some point in time. We can start with tracking and later add the UI.
1 Like
3

Once we have this for queries, if we do it properly, it will be easy to apply to dashboards too (I’m referring to #1028).

4

This would be sufficient for us I think.

5

Collaborative Editing of Queries

(I’m going to repeat information from previous messages, but trying to make an order)

“Product”

  1. How do we allow users to edit a query?
  • Easy solution: anyone who can create a new query with this data source, can edit existing queries for this data source.
  • More complex solution: allow giving permissions for a query based on users/groups. Permission can be - view/edit. This is the Holy Grail, but we can definitely start with the easy solution.
  1. What issues we need to handle when allowing collaborative editing?
  • Change tracking: currently we only track who created the query and who updated it last. We need proper revision tracking, to see all the changes someone made. We can start with a changes table that will track: object_id, object_type, change_type (“title changed”, “schedule changed”, “query changed”, …), user, change (JSON representation of what changed with before/after values). We could reuse the existing evens mechanism for this, but I have a feeling it might be better/easier to use a dedicated table/model. But I’m open to additional opinions.
  • Conflicts resolution: as mentioned, we should start with optimistic locking, and just notify the user that he might be overriding someone’s changes.

Technical Overview

  1. As before, we should have a feature flag for this feature (we probably should use the same one) with the default value being false.
  2. There are two places where we implement restrictions on who can edit a query: in the API (redash/handlers/queries.py) and in the UI (query_source.js). Whatever logic we pick, we need to apply it in both places. We should avoid duplicating the logic by deciding if a user can edit a query when returning the query resource in the API.
  3. Implementing the change tracking should be simple (we can utilize Peewee’s dirty_fields attribute to know what changed). The real challenge will be implementing the UI for it, but we can defer this to later.
  4. Optimistic locking: I’m considering switching to SQLAlchemy, which has this as a feature. So ideally we would’ve switched and used their implementation, but I assume this will be out of the scope of your work, so we can implement it on top of peewee (see some reference here). The API should return an error in case of “collision” and the UI should show a prompt for the user to decide if override. Then we need a flag for the API to force write the changes (in case the user answers “yes”).

[To be continued… @rohan if you have questions in the meantime, please ask]

6

Are we planning on implementing it anytime soon. This would boost the collaboration which we can get in the team and minimize dependency

7

It’s already implemented, but disabled by default. To enable it, you need to set the value of the REDASH_FEATURE_SHOW_PERMISSIONS_CONTROL environment variable to true.

8

If you need help or have questions, please email us directly at support@discourse.org.

9

Hi @arikfr
I changed REDASH_FEATURE_SHOW_PERMISSIONS_CONTROL to true
but we couldn’t allow users who are in same group to modify their queries/dashboards

i don’t see the request option to allow users to edit

redash version 8.0.0

10

Please check out this segment of our docs and let us know if you still have issues. This hasn’t been controlled by an environment variable for some time.

1 Like