User Story

As a cluster administrator, I want to see and manage cluster requests for all my clusters in one view.  In addition, because managing cluster requests is closely tied and often done at the same time as viewing the cluster list, I want an easy way to quickly go between a list of all my clusters and my cluster requests.

More information:

Currently, users are getting confused and losing context when managing clusters. The "view cluster requests" link opens a new page, and access requests are shown in a hard-to-read inline alert. This makes the interface feel cluttered and makes it difficult for users to handle cluster-related tasks efficiently.

Acceptance criteria overview/summary:

• The current cluster list and a new cluster requests page will be show in tabs.  These two tabs will show information across all clusters
• The cluster requests tabs will have two sections: cluster access requests and transfer ownership requests
• On the cluster details, the Access requests tab will also have two parts: cluster access requests and transfer ownership requests but only show items for the given cluster
• Minor design changes to table design, modals etc

Acceptance criteria:

Cluster list/ Cluster access tabs

1. Cluster access requests for all clusters are viewed in a single screen. 
   • For each request the following is listed:
     • Cluster display name (as a link to the cluster details > overview tab)
     • Request Id
     • Status
     • Creation date
     • Option to view/approve/deny the request (see below)
   • The list of access requests are paginated using standard pagination options (see cluster list for an example)
   • The list can be sorted by cluster display name
2. Cluster transfer ownership requests for all clusters are viewed in a screen. 
   • For each request the following is listed:
     • Cluster display name (as a link to the cluster details > overview tab)
     • Status
     • Type
     • Version
     • Current owner
     • Transfer recipient
     • Option to view/approve/deny the request (see below)
   • The list of ownership transfer requests are paginated using standard pagination options (see cluster list for an example)
   • The list can be sorted by cluster display name
3. Both cluster access requests and cluster transfer ownership will be displayed on the same page. (Known as the Cluster requests page for the rest of the doc)
4. The user can easily switch between the cluster list and the cluster requests page.  (currently designed as tabs). This option to quickly switch will remain even if there is no data or if there is an error.
5. Information on the cluster list and the cluster requests page is viewable and actionable on multiple screen widths including extra large, large, medium, small, and extra small screen widths. 
6. Both the cluster list and the  cluster requests page are available by unique urls so they can be bookmarked in the browser
7. When viewing either the cluster list page or the  cluster requests page, the total sum of pending cluster access and transfer ownership requests will be displayed for all pagination pages. (Currently designed as PF label on the cluster access tab)
8. If there is an error retrieving data,  an error will be shown in the same area is requesting data.  For example there is an error retrieving the cluster list, an error will be shown above (if partial or old data is known) or instead of the cluster list (if no data is retrieved or known).  If there is an error retrieving the access requests, an error will be shown above (is partial data is known) or instead of the access requests (if no data is retrieved or known.). This should mimic current functionality.
9. The left navigation item "Cluster List" will be changed to "Clusters" and go to the cluster list page
10. If a user has no clusters, the current "Let's create your first cluster" page will be shown inside the cluster list tab.  This "Let's create ..." page will no longer have the "View cluster requests" link 

Cluster details

1. The "Access Requests" tab on the cluster details will have the same style and type of data as on the cluster requests page but only show requests for a single cluster.  This includes:
   1. Sum of pending requests on the tab
   2. A section showing the number of access quests
   3. A section showing the number of owner transfer requests
   4. Help text inside help popovers (instead of as informational paragraphs)
2. When viewing either the cluster details, the sum of pending cluster access and transfer ownership requests for the given cluster will be displayed. (Currently designed as PF label on the access requests tab)

Access Request modal

1. For all variants of the access request modal, the following fields will be shown as read-only text fields or plain text so the user can view and copy the entire value
   1. Access request ID
   2. Access request creation date
   3. Subscription ID
   4. Respond by date (Can be "–")
   5. Cluster ID
   6. Request duration (Can be "–")
2. Approved requests
   1. Includes all the field above (see #1) and the following as read-only:
      1. Service request ID (Can be "N/A")
      2. Approver username
      3. Approval date/time
   2. The button to open the modal is "Open"
3. Denied requests
   1. Includes all the field above (see #1) and the following as read-only:
      1. Service request ID (Can be "N/A")
      2. Denier username
      3. Denial date/time
      4. Justification text
   2. The button to open the modal is "Open"
4. Sender pending requests
   1. Includes all the fields above (see #1)
   2. The button to open the modal is "Retract"
   3. On the modal there is a button to "Retract", when pressed, it send an API request to cancel or retract the request
      1. On success, a notification is displayed (via useAddNotification) and the modal automatically closes
      2. On failure, an error is shown on the modal and the modal stays open
5. Recipient pending requests
   1. Includes all the field above (see #1) and the following as read-only:
      1. Service request ID (Can be "N/A")
   2. The button to open the modal is "Open"
   3. On the modal there are three buttons: Approve, Deny, Cancel
      1. If the user "clicks" on  Approve, an API request is sent to approve the request. 
         1. On success, a notification is displayed (via useAddNotification) and the modal automatically closes
         2. On failure, an error is shown on the modal and the modal stays open
      2. If the user "clicks" on Deny
         1. The user is required to enter a justification and click on "Deny" again.  Once they do so, and API call is made to send the denial and justification text
            1. On success, a notification is displayed (via useAddNotification) and the modal automatically closes
            2. On failure, an error is shown on the modal and the modal stays open

Transfer Ownership Request modal

1. For all variants of the access request modal, the following fields will be shown as read-only text fields or plain text so the user can view and copy the entire value
   1. Cluster display name
   2. Transfer creation date
   3. Cluster type (ROSA, OSD, etc)
   4. Cluster version (control plane)
   5. Current owner user name
   6. Transfer recipient
2. Approved requests
   1. Includes all the field above (see #1) and the following as read-only:
      1. Approver username
      2. Approval date/time
   2. The button to open the modal is "Open"
3. Denied requests
   1. Includes all the field above (see #1) and the following as read-only:
      1. Denier username
      2. Denial date/time
   2. The button to open the modal is "Open"
4. Sender pending requests
   1. Includes all the fields above (see #1)
   2. The button to open the modal is "Retract"
   3. On the modal there is a button to "Retract", when pressed, it send an API request to cancel or retract the request
      1. On success, a notification is displayed (via useAddNotification) and the modal automatically closes
      2. On failure, an error is shown on the modal and the modal stays open
5. Recipient pending requests
   1. Includes all the field above (see #1) and the following as read-only
   2. The button to open the modal is "Open"
   3. On the modal there are three buttons: Approve, Deny, Cancel
      1. If the user "clicks" on  Approve, an API request is sent to approve the request. 
         1. On success, a notification is displayed (via useAddNotification) and the modal automatically closes
         2. On failure, an error is shown on the modal and the modal stays open
      2. If the user "clicks" on Deny
         1. On success, a notification is displayed (via useAddNotification) and the modal automatically closes
         2. On failure, an error is shown on the modal and the modal stays open

Design:

Recipient view flow

Sender view flow

-----------------------------

Open Questions

Currently on the access request modal, a user can see the "last updated" date (and we could show time) but there is no corresponding feature in the current design.  This appears to be purposeful - but there is an open question if this was truly the intent.

For both access and transfer ownership requests there are additional "statuses" including:

• Canceled (cancelled by sender)
• Expired (request not approved/denied by end of the "respond by" date)
• Transferring (request is approved but the system is in process of transferring the ownership)

Examples of these statuses (and possibly more) are missing from the mock-ups.  Again, this seems purposeful, but the question remains as far as what these statuses translate to (Declined, Accepted, Pending) 

On the transfer ownership table, if a status is pending, there is the number of days left to accept/deny the request.  As of the current designs, the accept by date is not shown anywhere.  How will users know when they need to approve a cluster by?

On the design the recipient view, the cluster name is a link for both  access requests and transfer ownership requests tables.  On the transfer ownership, the cluster name/id is not a link.  Do we still want to show the link for the recipient of transfer request and sender of the access request even though there is a good chance they do not have access to view the cluster details?

Example of a recipient's list:

In a related question, in the cluster transfer mock-ups there is cluster data shown both on the cluster list and in the accept modal.  Currently we do not show cluster data if a user doesn't already have access to view that data.   Do we want to show cluster data before a transfer is initiated? 

Will this entire feature be enabled for all users at once (for example behind a feature gate or a special route) or will pieces be made available to all users as the work is completed?  – Pieces will be release incrementally where possible.  At this time, a feature gate does not appear necessary. 

There is an a current OSD transfer process.  What impact, if any, does this that process intersect, interfere, or duplicate the process/designs as part of this epic?

-----------------------------

Implementation details (eventually these details should be moved into individual stories once they are created and this section is deleted)

Cluster

The cluster list and the cluster requests pages are displayed as tabs.  When a user goes to either tab (by navigation, direct url etc), data for both pages (aka tabs) are loaded at the same time.  Data will automatically be refetched every 60 seconds. There is a refresh button above the tabs that will refresh all data. This is not in the design.

The sum of pending request (both access and ownership transfer) will be shown on the cluster request tab to the right of the tab name.  Note that if there are no requests the number "0" will be shown.

The cluster archives will not be displayed in a tab but will be a separate page and display/behave as it does today

When the use moves from the cluster list to the cluster requests, if possible all the filtering, sorting, and pagination settings will persist.  If that is not easily feasible we need to maintain current functionality where the cluster type and "view only my clusters" are remembered.

All alerts currently shown on the cluster list will be shown under the cluster list tab (and not be shown when the user switches to the cluster request page.

The exact urls for the cluster list and cluster requests needs to be determined.  Here is what Nir suggested:
I think it makes more sense to nest it

 inside "clusters", not "cluster list". This also means that the left nav item should be renamed to reflect that -> "Clusters" instead of "Cluster list".  So possible urls would be:

• /openshift/clusters => redirects to /openshift/clusters/list
• /openshift/clusters/list => goes to cluster list
• /openshift/clusters/requests => goes to requests
• /openshift/cluster-list => redirects to /openshift/clusters/list
• /openshift/cluster-request => redirects to /openshift/clusters/requests

Text for cluster access requests help bubble:

Access requests to customer data on Red Hat OpenShift Service on AWS clusters and the corresponding cloud accounts can be created by SRE either in response to a customer-initiated support ticket or in response to alerts received by SRE, as part of the standard incident response process.
Read more about Access Requests functionality

Text for the cluster transfer ownership requests help bubble:

Transfer cluster ownership so that another user in your organization or another organization can manage this cluster.

The current "View cluster requests" link on the cluster list will be removed.  The current "Cluster Requests" page should be removed.

If there is no data for the cluster list, cluster access requests, or cluster transfer ownership, the table header will be shown with a "no data is available" "empty state".  See https://www.patternfly.org/components/table#empty-state

If there are no cluster access requests OR cluster transfer ownership requests, the "Cluster requests" tab will still be available on the cluster list.  In this case, when viewing the cluster transfer tab, there will be 2 "no data is available" "empty state" components shown (one for each section).

The access requests  inline alert will remain unchanged.

-------------------------------

Old text (can be deleted)

User Story:

As a platform administrator, I want to see and manage cluster requests in the same view as the main cluster list, so that I can handle all cluster-related tasks in one place without having to navigate to different pages.

More information:

Currently, users are getting confused and losing context when managing clusters. The "view cluster requests" link opens a new page, and access requests are shown in a hard-to-read inline alert. This makes the interface feel cluttered and makes it difficult for users to handle cluster-related tasks efficiently.

Acceptance Criteria:

• The "Cluster list" view is converted into a tab.

• A new "Cluster requests" tab is created and placed next to the "Cluster list" tab.

• The old "view cluster requests" link is removed.

• All cluster access requests are now displayed clearly within the "Cluster requests" tab.

• The solution is verified to work correctly on different screen sizes.

Mockup / Design:

Access/ownership request current flows - Suggest new design -> Cluster requests tab

Recipient view flow

Sender view flow