Manage Access to UI Features¶
In general, users will get access to most UI features based on their permissions on related objects.
For example users who have access to create and manage any ROLE
object will see the roles page in the UI.
These UI features may require additional configuration:
- Insights Page
- Users Page
- Workspace
Admins can control access to these UI features by granting groups access to the special feature access roles – e.g. okera_user_details_role
.
Access to the Home Page¶
What appears on the home page varies, based on your user roles and permissions. These might even affect the type of Home page you see: the Call-to-Action Home page or the User Profile Home page. Okera admins can see all features, but other users can only see what they have permissions to see. For more information, see the Home Page Access Reference.
Access to the Insights Page¶
Users automatically get access to the Insights page if they are granted VIEW_AUDIT
on any data objects.
However, they also need to be granted access to the Okera audit logs view to use the Insights page and to query the underlying audit logs.
Note that users with access to visuals on the Insights page only see audit logs for the objects for which they have been granted VIEW_AUDIT
permissions.
In the example below, any user with the marketing_steward_role
will see visuals for the marketing
database.
GRANT VIEW_AUDIT on database marketing to ROLE marketing_steward_role;
GRANT SELECT ON TABLE okera_system.git stating_audit_logs to ROLE marketing_steward_role;
Access to the Users Page¶
To grant access to the Users page, simply grant the okera_user_details_role
to any users or groups that need access.
GRANT ROLE okera_user_details_role to GROUP marketing_stewards;
Access to the Workspace¶
By default, access to the Okera Workspace is granted to all users (it is granted to okera_public_role
).
To limit access to the Workspace page to specific users:
- Revoke access to the Workspace page by removing it from
okera_public_role
. Use the Roles page in the Okera Portal or run the DDL:REVOKE SELECT ON TABLE okera_system.ui_workspace from ROLE okera_public_role;
- Edit your cluster configuration, and set the value of
GRANT_WORKSPACE_TO_PUBLIC_ROLE
tofalse
.
You can then grant the okera_workspace_role
to the specific groups or users you want to have access to the Workspace.