mcoles
commented
4 years ago Just adding a couple notes here based on conversations I keep having with folks who ask about this proposed work
Permissions changes are not currently tracked The database does not audit permission changes. It only tracks current state permissions, in the next_gen_permissions table. The only place I can find actual records of permissions changes is in the VizPortal logs that Tableau Server generates. You'd be looking for "setExplicitPermissions" in the log text, which would give you the user who made the change, and the date/time of the change...but not what item they changed permissions on, nor what the change was. You could infer the item they changed it on by looking for earlier log records under the same sessionID, and look for /views or /workbook or /datasource, and find the ID value that way. It's pretty awkward, and not at all conducive to answering analytical questions.
Thus, if you truly want to audit permissions changes, you'd need to build out your own ETL process for it, snapshotting diffs every day into your own data warehouse solution. And if you needed to see who performed the changes, you'd need to do nasty log-parsing exercises and marry that data to the warehouse as well. It's technically possible, but not really feasible for most organizations.
Permissions are stored only explicitly
The next_gen_permissions table stores explicit permissions that users and groups have on various items (projects, workbooks, data sources, etc). These are effectively "rules"--not the final word on whether a user has access to a given resource or not. To determine that, you've got to look at all the explicit permissions on the item, along with the user's role, their group memberships, and then resolve all of those into what the effective permissions for the user would actually be (see "Evaluate permission rules" at https://help.tableau.com/current/server/en-us/permissions.htm ).
And that creates a huge problem, because, for sizable Server deployments, joining the tables to determine every user in every group, for every item published to Server, results in millions or billions of rows. I've tried multiple techniques to reduce the rows, or make the performance bearable. Multi-table extracts, removing the "All Users" group from consideration, the new "noodle" data modeling capabilities, you name it. Each solution had the same problem: terrible performance. The only way I think you could resolve it is by restricting your queries to a single workbook / data source / whatever, or possibly to a single user. And doing that drastically reduces the number of questions you could ask of this data.
Perhaps it's enough to answer most questions, simply knowing the individuals and the counts of users in each group that have been assigned permissions on a given workbook. That'd be able to answer broad questions about permissions management, auditing (do more than 50 people have access to this? how many workbooks deviate from their Project permission defaults? how many Projects have individuals assigned permissions directly, rather than groups?). But it would not be able to answer specific questions about whether a given individual has access to a given workbook.
saurabhkumar004
rickymedrano
We get a lot of requests for a data source to help folks author dashboards that expose permissions. It'd be great to collect some use cases in the comments here so we can build the best version possible.