Description

After disabling the create cluster action for ROSA and OSD when users don't have permissions (OCMUI-3165), we realized that there are other actions that could need the same treatment.

We already found the same problem with machine pools (OCMUI-2914) and disconnected clusters (OCMUI-3371). Those tickets are now moved in this epic.

This epic aims to identify all actions that could be enabled or disabled based on user roles/permissions across the whole app and to fix them. 

This spreadsheet was created to describe the relations between UI features and roles.

For a list of all relevant roles and their bindings to permissions, see the ‘role bindings’ tab in the spreadsheet.
For a mapping of UX approaches for access-gating per interaction type, see the ‘UX patterns’ tab in the spreadsheet.

Acceptance criteria

New functionality

• users can click 'Add break-glass credentials', under cluster-details 'access control' tab, only if they have the 'create' permission on the 'ClusterBreakGlassCredential' resource
• users can click 'Edit machine pool', under cluster-details 'machine pools' tab, only if they have the 'update' permission on the 'MachinePool' resource
• users can click 'Register cluster', in the cluster-list page, only if they have the 'create' permission on the 'Subscription' resource (tracked with OCMUI-3371)
• users can view the 'Cluster list' and 'Cluster archives' tables' contents, only if they have 'list' permission on the 'Subscription' and 'Cluster' resources
• users can view the 'Break-glass credentials' table contents, only if they have 'list' permission on the 'ClusterBreakGlassCredential' resource
• users can view the 'Identity providers' table contents, only if they have 'list' permission on the 'IDP' resource
• users can view the 'Machine pools' table contents, only if they have 'list' permission on the 'MachinePool' resource
• users can view the 'Cluster transfer ownership' table contents, only if they have 'list' permission on the 'ClusterTransfer' resource

Updates or fixes to existing functionality

• users can open the 'actions' dropdown in 'cluster details' page, only if they have sufficient permissions on all individual items
• users can click any of these cluster 'actions' dropdown items, 'only if they have the 'update' permission on the 'Cluster' resource: 'Edit display name', 'Edit load balancers and persistent storage', 'Delete cluster', 'Hibernate cluster', 'Resume cluster from hibernation', 'Archive cluster', 'Unarchive cluster', 'Edit/Add Console URL'
• users can click the 'Transfer cluster ownership' item of the cluster 'actions' dropdown, only if they have the 'create' permission on the 'ClusterTransfer' resource
• users can click the 'Cancel ownership transfer' items of the cluster 'actions' dropdown, only if they have the 'update' permission on the 'ClusterTransfer' resource
• users can click the 'Edit machine pool' item of the cluster 'actions' dropdown, only if they have the 'update' permission on the 'MachinePool' resource
• users can click 'Revoke break-glass credentials', under cluster-details 'access control' tab, only if they have the 'update' permission on the 'ClusterBreakGlassCredential' resource
• users can click 'Edit Delete Protection', under cluster-details 'overview' tab, only if they have the 'update' permission on the 'ClusterDeleteProtection' resource
• users get consistent experience across both 'Edit delete protection' and 'Edit Channel group' fields, under cluster-details 'overview' tab; when permissions are missing, the edit pencil icon should be disabled with a tooltip
• users can click 'Install add-on', under cluster-details 'Addons' tab, only if they have the 'create' permission on the 'ClusterSelfManagedAddon' resource
• users can click 'Uninstall add-on', under cluster-details 'Addons' tab, only if they have the 'delete' permission on the 'ClusterSelfManagedAddon' resource
• users can click 'Create trial cluster', 'Create cluster OSD', 'Try it on Azure', 'Try it on IBM', 'Create cluster ROSA', in the cluster-types page, only if they have the 'create' permission on the 'Cluster' resource (tracked with OCMUI-4010)

Common

in respect to any of the above items (new or updates):

• any control that users can't interact with due to permissions is disabled
• any such disabled control shows a tooltip, elaborating the 'disabled' reasons
• any list that users can't access due to permissions is emptied out, and shows an 'empty view' with a message elaborating on the reasons

Mockups/Design

no new mockups; we rely on existing best practices or common design patterns.
for edge cases and special considerations on accessibility, specific solutions were devised by the PatternFly team.

any UI controls that are tied to restricted operations are disabled based on user permission. specifically:

• disable controls that open dialogs, with an infotip (unless the dialog is also used to view and not just create/update data, in which case always keep the control enabled)
• in dropdowns, disable individual items. disable the trigger button only if all items are not allowed
• don't disable navigation controls that lead to external links; external systems will handle access
• don't disable the action-menu trigger button in table rows; disable individual menu items
• if an expandable panel calls a BE service operation upon expand, hide it
• block wizard entrypoints; disable any links or buttons leading to it, and block its route with a back-redirect
• disable buttons or links which navigate to form pages (like the 'add IDP' pages), and block the page route
• disable controls inside high-level container pages (e.g. 'cluster list', 'cluster archives'), and replace any data contents with an empty-view and a message

for extra details, see UX patterns.

Out of scope

• org' capabilities; only controls that are tied to authorization-related access should be handled (i.e. roles, permissions)
• route-blocking for cluster-details pages. the UI already handles that; drilling down on a link of a restricted cluster from the cluster list will result in a back-redirect to the cluster-list page (with an alert being shown)

Testing implications

• E2E testers will need to set up dedicated RH-portal accounts, both internal and external (i.e. ones with non-redhat email addresses), with lesser permissions. this will pertain both manual runs and automated-tests setup
• for testing 'cluster viewer' role negative-flows, some tweaking will need to be done at the org level, specifically, the 'default access' group will need to be updated by an admin user to exclude 'list' permissions from this role (see RBAC user-access configuration on redhat docs)
• many areas will be covered, across the overview page, cluster-list, cluster-details, the wizards, access-requests, etc.

Implementation notes

• we can use the provider-consumer pattern (via ‘context’ in react, or a higher level context provider), to control components based on grant permissions
• use aria-disabled rather than disabled attribute on the triggering element, to avoid preventing the element from receiving focus, so that tooltips can be triggered by user interaction. whenever that attr' is applied, unbind any component handlers explicitly (see this thread for more details)
• ATM, ClusterDeleteProtection resource is not yet available via AMS API, although it is declared in the roles/permissions definitions (at uhc-account-manager repo). in case it’s not available by the time of implementation, we will hard-code that value in our codebase temporarily, rather than relying on the API type-definitions. (related slack thread)
• when 'list' permissions are missing, the subscriptions/clusters API endpoints will return successfully with an empty response. it’s the UI's job to send a request to authorization API endpoints (e.g. self_access_review), prior to that. the UI could then infer whether it should show a permission-related message (e.g. in a table view)
• some charts:
  • mapping of UI controls that are tied to OCM API endpoints: controls-services-endpoints-data.csv, controls-services-endpoints-graph.svg
  • mapping of UI navigation elements that are pointing to OCM related actions: controls-navigation-data.csv, controls-navigation-graph.svg

More information needed

• we may need a tech-writer, to help phrasing any new 'disable reasons' we might find - tho they can be inferred from existing cases