Super Admins should have access to everything

[RADSr]

Note: As always - I'll hang my head in shame if I'm wrong 😉   

Super Admins should have access to everything - and in fact the documentation says they do  ...  but they don't.

I got this from support:

---------

The users who have “Super-Role” role, have permission to do anything in Incorta, they can also see all resources even if it is not shared with them, this case apply to everything except the Dashboards.
Even if you are a user with super-role permission, you can only access dashboards if and only if it is shared with you or your group, this is because dashboards might have sensitive data.

----------   

Obviously this is silly - a super admin can query any data a dashboard author can, so "sensitive data" is available either way.   The only thing this restriction does is make it more difficult for a super admin to work on dashboards/insights w/out first having the owner make an exception to their sharing scheme.

[mrossPM2]

Completely agree that the Super Role should grant access to everything to ensure there's full visibility to everything being done in the environment.

[ayakandil]

Hello @RADSr , @mrossPM2 I hope you are doing well .. 

We would love to help you reach the ultimate experience.. that being said, let me clarify the behavior for you and ask for your feedback .. 

Data itself might not be useful unless it is used in a specific way/format, for example, imagine the following scenario : there could be a table containing all the numbers a company won from sales deals, listing those numbers might not be considered sensitive data and hence listing those number might not be an issue (for some), but building reports comparing those numbers and seeing how the company perform through the years and building prediction reports might be a "confidential/crucial" information that indicate/tells how a company is performing, such information could cause the company to collapse if stock holders got terrified by such information and sell their stocks causing dramatic impact on the company’s valuation.

After stating the previous example, I am still interested in better understanding your use case :

1. Why do you need to give users with super-role permission access to all dashboards? .. in other words : what are you trying to achieve? Are you looking for dashboard management from the perspective of deletion, sharing, transferring ownership, path management and such..? OR Are you looking for users with super-role to edit these dashboards?

Answering the previous question would help us in decision making, there are multiple paths we could follow, for example : we could allow users with super-role permission to view dashboard metadata, but not the dashboard data/reports 

Looking forward to hearing from you to better understand the use case

[mrossPM2]

Hello @ayakandil 

I would primarily expect to use the super role for dashboard management as you outlined in your response. Thinking from a content migration perspective, I as an admin need to be able to see what I intend to migrate. There are two cases where not seeing all of the dashboards can be problematic. If a user wants to promote a dashboard from Dev to Prod, but the admin can't see the dashboard, then it can't be moved. Conversely, if a whole folder is being migrated from Dev to Prod, but the admin is not aware that a user has created dashboards or subfolders in that top level folder that are still a work in progress, the admin would be inadvertently promoting content that isn't ready for production.

As an implementation consultant that is usually working with companies that are new to Incorta, I want to be able to use the admin role to build out the content folder structure following best practices. If the super role allows me to see all content, I can monitor to make sure people aren't creating one-off folders or dashboards outside the intended folder structure.

I could see a case where a very hands on Incorta admin might be asked to help a dashboard developer to solve a problem with a dashboard. If the admin can edit the dashboard without requiring the developer to manipulate the sharing access, that would make things easier.

I would envision that most Incorta customers might only have one or two super admins, so I don't think this type of access would be widely handed out. Someone has to own the application, and that person (or small team) should have visibility into everything that is taking place in the platform.

[RADSr]

@ayakandil ,

@mrossPM2  has a good response above, but I'll add a couple things:

1) I don't want to quibble semantics, so I don't care if it's the super admin group or another group w/ the capability to see all.

2) The super admins can already ( per your example ) see sales won and build predictive results.  They can do anything with any data stored in Incorta.   

3) I assume that the same people administering Incorta Analytics have CMC credentials - which means they **already** have access to all the metadata and via a simple XML edit can copy any dashboard.

4) A toggle for a super admin between seeing all and just seeing their own objects ( and those share with them ) might be helpful but 

5) Asking an admin to administer an environment to which they do not have full visibility is asking them to solve a puzzle with missing pieces.

6) Lastly, and a bit tangential, you ask "OR Are you looking for users with super-role to edit these dashboards?"    It would be *very* helpful ( I'll post it independent of this thread ) to divorce the "edit" action from "being able to see the authoring" of a dashboard.   I have plenty of dashboards I don't want people to be able to "edit" ( i.e. don't change my stuff ), but don't mind at all if they look at the authoring ( i.e. I have a formula that does that -- take a look ).  

[dylanwan]

A user with a superuser role can access the dashboard created and owned by other users via impersonating as the user. The dashboards are created and organized by the owners. dashboards and folders can be created by different users under the same name as they may not see each other dashboards.  When they are all granted to the superusers, I am afraid that it won't be manageable. The action of impersonating users is subject to the auditing, including both the permissions as well as the usage.   When sensitive data have leakage, the system knows who has the access and who had accessed the data.

Incorta metadata dashboards were provided for Incorta admin to monitor the usages including the dashboard show the audit.csv.  Incorta metadata dashboards can also let the admin users to see how the data is granted. to the users and groups. 

PII and sensitive HR data, such as payroll, cannot be simply granted to all admin and admin do not need to view them until they really need to, such as the migration case  @mrossPM2 mentioned.

[RADSr]

@dylanwan  -

I hear you, I could then change my product enhancement request so that super admin users should be able to impersonate other super admin users.

... or another group - I'm not hung up on *which* group has the proper complete access to administer the environment, just that there is one.

But there ought not be a situation where a designated person in charge of the environment cannot see all of the objects within that environment. 

[RADSr]

Another use case from right now at this very moment.

In production, a member of the super admin group has authored a dashboard and shared with everyone w/ view access.

That dashboard has a filter which needs to be updated to be accurate for the exec team.

The authoring super admin user is not available.

I - also a super admin user - cannot help get this business critical information into the hands of the business users making the the business users ( and ME! ) critical of this fundamental flaw in super admin capabilities.   

[RADSr]

I'm bumping this again as it is *again* hindering my workflow.

A fellow super admin has authored a dashboard.   That super admin is on super PTO  ( I assume it is super because I'm an optimist ).

I need that dashboard.

My options are 1) export the tenant and start hacking away at XML or 2) wait.    

As the owner of the cluster this simply should not be.