It would be a great feature if user roles could be more flexible so that users can have the right amount of access.
For example, an account owner should be given the option to allow a user to be a Station Supervisor AND a Table Supervisor at the same time. Currently, only administrators have permission to be both. The administrator role in this scenario would allow for too much access.
Please allow for more flexibility on defining user roles.
@jacob.dahlgren - Thanks for your suggestion on this. I would be more than happy to hear more about other use-cases/insights you might have on this topic.
Let me know & feel free to book a time on my calendar for a quick 30 min chat.
Thanks,
Sagar
Feel free to reach out to me, the account owner. I agree with the request wholeheartedly and Jacob did a great job of explaining the scenario if in the request, I think, but happy to discuss further.
@Kirklana, @jacob.dahlgren, I’m doing user research on how people manage access to Stations. this is tangentially related to User Roles, but I think you could still have some valuable insight. feel free to set up time via Calendly - Sam Feller if you’re willing to talk more!
@SamFromTulip, @Kirklana, @jacob.dahlgren, did you have talk ?
We are strongly waiting for this new user role “Tulip Table Supervisor”+ “Station Supervisor”.
Our company want each department to assign few members which have this new role.
We want to limit the members who could edit the table, and that member also knows well about Tulip station management.
However, we do not want that member to edit connectors so “Administrator” is not an option.
That is why we need new role.
Hey @ta-aoki -
@Viktor is the Product owner for user management and he has been hard at work collecting all the missing features when it comes to user management. We are getting towards the end of the project scoping to start addressing these issues, and from there it will be executed by the engineering teams. On of the biggest part of this work is to be able to create your own user groups with whatever names and roles best fit your needs.
It sounds like this functionality is exactly what you need. Is there any other features around user management you feel we are missing?
Pete
APIs for user management of both the user and the custom fields associated.
Hey @Kirklana -
This is something I ran into fairly recently too. There is a number of feature requests around user management through the API. User management needs to be more accessible from other systems, and at more scale. It was the needs of instances managing hundreds or thousands of users that drove us to start this work around user management, and supporting scale is one of the primary objectives.
Pete
@Pete_Hartnett
Thank you. OK, I will wait for the flexible user roles to be released.
I faced one surprise recently that “Tulip Table Supervisor” and “Application Builder” cannot assign their own Display Device on the player. Is this intended limitation ?
Even the “Viewer (with Player Access)” can assign their own Display Devices, so I think both “Tulip Table Supervisor” and “Application Builder” should also be able to assign their own Display Device on the player.
Could you please consider the specification change in near future?
Hey @ta-aoki -
Here is a good guide on the different levels of access for each role:
I can talk to the team who manages that permissions level to see if this is something we could change in the short term. Unsure if there are implications that I am unaware of. For example, if another customer is using “Application Builder” user roles because they can’t assign display devices, we wouldn’t want to pull the rug out from under them. This is exactly why we are looking to make this list of permissions configurable on the instance level.
Pete
Also, in order to create Custom Widgets you need to be an account owner. Except when you go to install a widget which I think it allows anyone to install it…
But yes! Better role controls please!
Totally right @mellerbeck -
One of the big reasons for this project is to allow stuff like custom widgets to be more accessible, while not creating compliance issues.
Once a custom widget is installed anyone can use it, it just cannot be edited.
Pete
In the short term, as @mellerbeck referenced above I think there’s a separate ask here to even just create a dedicated “custom widget developer” role in the current roles model.
At the moment we have to put any custom widget developers on a tulip instance dedicated for that purpose, with a full compliment of our IoT infrastructure stack to be able to properly test talking to our data. Not only does this make for more setup work, but it keeps our custom widget developers from being able to really work along with citizen Tulip developers, making for a bit of a clunky workflow.
Could a new role be created in the current Tulip roles model for custom widget development, so its fate isn’t bound to the rollout of the flexible roles this thread is about? Happy to submit this as a separate feature request if need be.
Thanks!
Hey @aaronbroussard -
What other access would this CW developer role have access to? A few options:
Table:
App Editor
Dashboards
Account settings
These are kinda just the core functions that come to mind, but there is a whole lot more (like connector stuff, Machine monitoring stuff, vision stuff, station stuff, etc).
We are kinda apprehensive to field requests for additional user types as stopgap solutions. Kicking that can is what got us to 20 user types that don’t quite fit anyone.
Pete
I second the importance of this topic. The lack of appropriate roles for certain user slows down our development because we can’t pick and chose what a single user is allowed to do.
Maybe a page for the account owner that can check the box on what each user is allowed to do like this…
You hit the nail on the head around how we think about how we want to approach this.
For each user, you could choose any/all of the different key product features to enable or disable, and then that users set of access permissions could be stored as a dedicated user role and applied to other users.
This gets a little tricky with Workspaces, which is a function intended to enable Tulip across multiple facilities. In an example case Bill might have one set of permissions in facility 1, but a different set in facility 2. We need to elegantly support this in UI, along with the ~100 key product features that should be toggle-able.
Pete.
I agree, but I would do it in the age old fashion of users belonging to groups and groups being assigned permissions.
I agree with mellerbeck. If we did it through permission groups, in the future we could automate provisioning and deprovisioning through Identity Management with AD groups etc. allowing us to follow more of the standardized workflows IT has for onboarding and approvals in the enterprise. I do like Alan’s idea as well, I would just want those permissions to be assignable to groups and the individual accounts assigned to the group.
