UI Workflow Master Ticket

[kimlisa]

Description

UI workflow break down. For issue: #4028

https://app.avocode.com/revisions/77400993/comments/?design=52149182

Basic workflow features

Frontend:

• Create a access requests tab on side nav under activity
• List ONLY the logged in users request
• Create new requests
  • Display roles requestable to select
• Assume approved requests

Backend requirement:

• GET list of requests
• Retrieve list of roles requestable

Extend basic features

Frontend:

• Add filters in list view
• View requests
  • Delete this request with confirmation dialogue
  • Display approval threshold required
• Submit review requests
  • Allow reviewer to override rules will not be part of 6.0
  • DENY or APPROVE
  • Optional review message input
• Extend Create new requests
  • Able to type input/list suggested reviewers username to select

Backend requirement:

• DELETE a request
• PUT update a request
• get list of suggested reviewers for a request

Implement Banner for assumed roles

https://app.avocode.com/revisions/77435353/?design=52233887

• Create a banner that details role assumed, expiration and provide switch back button that switches role back to default

[kimlisa]

Please review @alex-kovoy @benarent @klizhentas
I marked questions with QUESTION:

[alex-kovoy]

@kimlisa thank you for this master ticket! Lets start with the Admin experience which seems the most straightforward and I will answer your questions regarding other parts afterwards.

[klizhentas]

QUESTION: What should happen after clicking on it? Change access role btn text to assumed? Should one approval deny other requests? Can a user switch back and forth between multiple approved requests?

Let's change access role btn text to assumed. One approval or denial should not affect other requests. User can switch back only by using global "Switch back" mode. They can then assume another role from the same modal. They should be able to assume another roles if they click "Switch back" or if they use the same list.

[klizhentas]

Banner QUESTION: Which banner style am I going with?

Style 1

[klizhentas]

QUESTION: Revoking an approved request isn't a feature present in tctl atm, so this state might also just be view request button too.

Yes, let's ignore Revoke

[klizhentas]

@alexwolfe will post the latest designs in sketch.com next week here

[klizhentas]

@kimlisa @alex-kovoy this code should go in enterprise only repo

[alex-kovoy]

Style 1

@klizhentas the 2nd is more universal as it would work in the terminal/session player as well.

[klizhentas]

@alex-kovoy fair point. I am going with style 1 because it does not disrupt the vertical space. We will work on adding a state for the player as well.

[alex-kovoy]

After looking at it, taking a bit of a vertical space to handle this use case actually seems fine but if go with the 1st then we are claiming a horizontal space of the top nav which might be more useful for something else. What I like about the 2nd is that we can use it for other notifications by stacking them on top of each other, like notificats/alerts from SalesCenter about expired licenses/payments. Each would have close "x" button to dismiss and would work on every screen.

[klizhentas]

Add GRPC api method that returns the current user their context:

@fspmarshall this is required so that UI can know what roles the user can request

GetCurrentUserInfo() -> Info
type Info struct {
    CanRequest []roles
}

We need to discuss this a bit more before rolling it out

[kimlisa]

@alexwolfe @klizhentas ui update:

changing the expiry time is not a feature present, so i am leaving this one out too

[alex-kovoy]

Add GRPC api method that returns the current user their context:

@fspmarshall I just recall that we do have UserContext on the webapi level which we can use to return this information. If so, we can handle it ourselves.

[jeffjen]

Is the workflow related to only requesting access, not approving access?

[kimlisa]

@jeffjen you can also approve/deny access request in the UI