Tableau Server - Factors Affecting What Users Can Do

Tableau Server Permissions continue to confuse people.

I encountered this discussion in the Tableau Community recently: Reporting on Permissions for Server Projects in which the participants are trying to figure out how to create custom admin views to see who can view which Projects. Like many of these discussions it ranges out from its initial focus to contemplate broader Permissions questions.

Rather than trying to cover everything to do with permissions in this post, mostly because it's really complex, convoluted and difficult, almost impossible to come up with a succinct description, I'm going to use this opportunity to post this link to a diagram mapping the Tableau Server landscape identifying the elements that affect who can see what and what they can do with what they can see.

The information is accurate and complete, as far as I've been able to get it, with the notable exception that it doesn't include Web Edit capabilities. If and when anyone finds any deficiencies—inaccuracies, missing elements, something that's not clear, etc., please leave a comment and I'll correct the map.

Things to be aware of.

The following address some of the points in the discussion noted above, along with others worth noting. I'll keep adding to them as time goes by, depending upon time, best intentions, inclination, other interesting things coming up, etc. I'll also incorporate useful points provided in the post's comments, along with attribution, so if you're add anything and want credit please identify yourself (anonymous doesn't get nearly the credit he/she deserves).

Tableau's approach to Permissions is different from other approaches. And not in a good way.

Although Tableau's approach to providing ways to control access to and interaction with objects and contents uses terms that are familiar, it's very much its own animal.
The surface similarities lend an aura of familiarity that leads to expectations of how it's going to work, and consequently approaches to working with and managing objects, content, and the Users' interactions, that aren't in line with Tableau's reality. And this causes very substantial cognitive conflicts that can be difficult to recognize, much less overcome.

It's not you.

Learning about Tableau's Permissions and how they work is hard.
Internalizing this knowledge is harder still.

Don't be worried or discouraged if working with Permissions isn't smooth and easy out of the gate. For most of us it's a struggle to absorb things to the point of being reasonably comfortable with predicting how things will work and puzzling out why they're not working the way we think they should.
Don't give up. You still have us.

Permissions are attached to Tableau Server objects, not users or groups.

Permissions are attached to Projects, Workbooks, Views, and Data Sources.
Permissions connect Users and Groups to these content objects.
There's a tendency to think of Permissions being assigned to Users or Groups, this can lead to difficulty in interpreting how Permissions work and figuring out why things aren't working the way one thinks they should.

There's more to it than Permissions. Lots more.

Permissions aren't the only thing controlling what users can see and do.
License levels, admin status, publishing right granted or not, content ownership, site membership, group membership, individual identity, and whether a workbook is published with tabs showing all get involved.

Not Allowed is Denied

Any Permission that is not explicitly granted to a user somewhere, somehow is effectively denied.

"Inherited" means "Not Configured Here"

Inherited is a horribly bad word as it's used in the documentation and Tableau Server UI. It implies that there is an active process that assigns something. While there is, in a very narrow technical sense something that -could- be called inheritance in Tableau Server it's not what people who don't already know it think of inheritance being, and in this it misleads almost everyone who needs to know what's going on (and this sentence is far less confusing than inheritance).

Permissions get assigned to objects when they're created or published.

There's always a default Permissions set that is available to be assigned to content when it's created—Projects, or Published—Workbooks/Worksheets and Data Sources.
It's possible to override the default Permissions when publishing Workbooks and Data Sources.

Permissions can be changed on anything that carries them.

Anyone who has access to the object and is permitted to do so can change the object's Permissions. This is an extremely powerful ability and makes effectively administering Tableau Server possible.
However, it takes experience and skill to manage Permissions well—it's really easy to make a real hash of things, so be careful and test afterwards.

Changing Permissions on something DOES NOT change the Permissions on the things it contains.

Changing Project Permissions does not change the Permissions on the Workbooks and Data Sources in it.
Changing Permissions on a Workbook does not change the Permissions set on the published views in it (if any have been set, and this is a topic all on its own).

Admins can do anything.

No real surprise here, admins can do anything with anything, so it's best to make sure your admins understand the consequences of what they're doing. Most don't.

Owners can do anything with their content.

Whomever published something is its owner by default, and can do whatever they want with it. Subject to the permissions of other objects that may be involved, an Owner can't move a Workbook into a Project for which they don't have the proper Permissions.
  (exercise for the reader: what Permission lets someone publish or move a Workbook into a Project?)
Ownership is a frequently overlook property. The owner of a thing can change its Permissions, which can lead to confusion.
Ownership can be transferred, and this can really throw spanners into the works.

Puzzling out why someone can or cannot see or do something can get extremely complicated and vexing.

The number of things that can be involved is large, and their interactions can be really hard to untangle. There's a process I go through, but it's not really a recipe I can write down, more like an exploration of a jungle when there's lots of potential dangers lurking in the understory waiting to trip you up.
OK, it's not that mysterious - I essentially work through the map identifying what's involved until I get to the solution point.

Roles are not very useful, and can be profitably ignored.

Roles are nothing more than preconfigured sets of Permissions that can be attached en masse.
They're useful in the very narrow circumstances where there's a Role that matches the exact set of Permissions that suit your needs. In my experience with quite a few clients this is almost never the case.
Any set of Permissions is a Role, which would be OK if there was some way to create and manage custom sets of Permissions and give them meaningful names, but there isn't. Any set of Permissions that isn't one of the standard Roles is named "Custom", which makes it impossible to identify what the Permissions are without digging down and looking at them manually, which imposes a needless burden on whomever is trying to figure this out.

The ability to set Permissions is a Permission.

Anyone who can set Permissions on an object can grant other people or groups the ability to also set Permissions on that object. In general this is a bad idea and should be discouraged.

Tableau 9 could change everything.

From what I've seen so far Tableau Server 9's Permissions monitoring and management abilities and clarity and ease of use has improved leaps and bounds. It's very different from previous approaches.
I haven't really had the chance to dig into it yet, but will and hope to be delighted.