Please allow us to present, for your entertainment and edification, the one, the only, the Tableau Server Role Permissions:
One of the tricky parts of working with Tableau Server is getting the Permissions straight. Tableau's Roles are part of the mix, and can be useful in some circumstances (the whens and whereofs are themselves a topic begging for exploration and explanation, but that's for another time).
Understanding how different Roles' Permissions are configured can be difficult—like many parts of Tableau they're described individually, but with no consolidated documentation that brings them all together so that they can be seen at a glance and compared with one another. Until now.
Tableau Public-published Workbook
This workbook brings the Roles, their Permissions, and the Permissions' objects into a single view, helpful for achieving the holistic view necessary for understanding and employing them when it makes sense to. Comments and observations are below.
Screen Shots Tableau Server's presentation of the Roles' permissions.
Observations and Comments
- None of the Roles' Permissions are ever set to Deny.
- It's not clear from Tableau's documentation but unless a Permission is explicitly Allowed for an object it is effectively Denied - this makes using positive Allow-only Permissioning to be an effective strategy. (I'll be writing more on this)
- Using Roles is reasonable as long as the Role's Permissions matches the set you need for the object, otherwise they need to be masked out and this introduces complexity that can be more confusing than if the Role wasn't used in the first place.
- The name "Custom" for the 'Role' that's really 'Not one of the preconfigured ones" is unfortunate, in a number of different ways. It at least implies that there is -A- Custom role, when in fact what needs to be signaled is that there's a possibly unique blend of Permission configurations in effect for this User/Group for this object.
- The lack of Role creation and management is a huge deficiency. It would be far, far easier, cleaner, and faster to configure Tableau Server to specific requirements if it were possible to create true custom Roles and apply them when and where they're needed. It would also make the whole system much more transparent—Tableau Server Admins would have a much easier time of understanding what Permissions are actually in effect, making it that much easier to support the business stakeholders who can't see what they're supposed to, or can see something they shouldn't.
For example, it would be very nice to have a Role for viewing that allowed filtering but not the ability to see underlying data. - "Inherited" is a singularly bad name for what really is "Not Configured Here". One of the problems to using "Inherited" is that it means something to the great majority of people who see it very different from its meaning in Tableau Server, way is itself poorly explained and difficult to puzzle out.
I hope this is helpful. There's plenty more to explore and explain about Permissions, and I hope to one day get a good, concise explanation out into the world.
References
This is a Great Information.. Thanks.
ReplyDelete