Control access to individual Tulip assets

Product Suggestions
1

Hi,
I had the chance to test the new Custom User Roles feature today and I thing it will work beautiful for most use cases. But what I was missing from the beginning was the possibility to totally lock user out of views.
I think the most restriktiv setting, e.g. for tables, should not be to view them, but to not see them at all. (even better would be to differentiate which tables or apps a user can see. But that’s a different product suggestion, I guess :wink: )

Best,
Stanislaw

2

Appreciate the feedback, Stanislaw. One reason that we have hesitated to implement the “cannot view” permission for a table is that a user could still create an app, add an interactive table, and view the table through the app. So there are really at least three parts to it:

  1. Restricting ability to view individual tables through the Tables UI
  2. Restricting the ability to add tables to an app (so a person cant just create an app and view it themselves
  3. Restricting permissions to view individual apps as well (so a person doesnt just view an app that already exists and references the table)
  4. (possibly)- Changing the way that users can create Station so they can create stations to view their own apps but not other peoples apps (so that they don’t just create a station, open the app that has the table and view the table)

Does that sound accurate? Or are there certain items in the list above that you think would be sufficient to prevent people from viewing tables?

3

What happened to Alans idea? Even though I can create a custom user role for everyone I would prefer to have generic user roles (e.g. app editor, table editor, widget editor, …) and assign multiple user roles to one user to create specific user roles.

4

Hi Oliver, I understand. We wanted to get the first version of the feature out, and make sure it was successful in a simpler form, before considering more intricate systems.

Can you share why this is important to you? That would help me understand if permission sets would be the right solution, or if another feature we are already planning would help solve your problem.

5

Hi Kevin,

let’s consider the following example:

  • Person 1:
    • Create, edit & archive apps
    • Create, edit & archive tables
    • Create, edit & archive widgets
  • Person 2:
    • Create, edit & archive apps
    • Create, edit & archive tables
    • Create, edit & archive connectors
    • Create, edit & archive widgets

Currently, I have to create a custom user role for each person. I would prefer the option to define the four user roles of person 2 and assign three of them to person 1. Therefore, I don’t have to create a new role if another person needs a different set of access rights.

6

Understood. Question for you- are the high level “create/edit/archive” roles sufficient for you for Tables and Connectors? Or would you like more fine-grained control than that, including control of access to individual tables and connectors?

I want to make sure I understand the root of the problem here.

7

Currently, there is no need to restrict the access to specific connectors, but in case of tables it would be helpful. The following options would be best:

  • view, edit & archive alle tables + create new tables
  • view & edit specific tables
8

Understood. We are currently making our roadmap on how we want to improve our permissions system, and this is helpful feedback.

9

If you are considering a feature to limit specific tables to be edited by specific users, I also want a feature to limit specific tables to be edited by specific Apps.

10

I would also like to be able to create a user who can only view

  1. Analysis
  2. Analysis and table
    and all other components set to “cannot view”
1 Like