Org Member Page - Three dots/ellipsis Buttons

[therealslimhsiehdy]

Issue description

A key part of member management is removing existing and invited users. To do this in our system we will have two places a user can go to remove someone, on the Member's table and in the Member profile page for a given user (invited or active). A user will click a drop down (the More actions or 3 dots icon) and this will allow someone to cancel an invitation or remove the user.

There are certain error states where a user shouldn't be removed/uninvited, so in these cases we will still show the option to remove them but clicking it will result in an error appearing on the screen.

Acceptance criteria

*figma for Member Management more action buttons
*figma for Member Profile more actions

• On the Member Management table3 dots/ellipsis icon shows on each member row, including rows for ones still in the invited state
• On the Member Profile table, the 3 dots/epllipsis icon matches the Member Profile figma

Complete both annotations linked above in their entirety, the following are some of the key AC in the annotation:

• Both the Member Profile page and the Member management page show the same errors when attempting to remove a user who cannot be removed
• The 3 dots drop down should result in a screen focus if it's accessed AND user can select only one of the triple dots at a time, follow the existing patterns on the Domains table
• For an invited member, when the 3 dots are clicked on the modal it should display "More Options > Cancel invitation"
• For an active member, when the 3 dots are clicked on the modal it should display "More Options > Remove member". This should delete their UserDomainRoles only for this portfolio + remove their UserPortfolioPermissions
• If the member manages 1 or more domains, follow the Figma modal "Member manages 1 or more domains" wording and display colouring
• If the member manages no domains, follow the Figma modal "Member manages no domains" wording and display colouring
• If the member has an in progress request, create an alert and follow wording and USWDS specifications per the Figma design "Member has in-progress domain request" -- in progress means anything Started, In review, Action needed.
• If the member is the only admin (see Figma for the 2 cases), and follow the Figma modal "Member is the only admin" for alert per USWDS specification + wording
• If member is the only domain manager on a domain show the error displayed here if some tries to remove them.
• An admin member, who doesn't meet any of the above error states, can remove themselves from a portfolio

Additional context

Links to other issues

• Blocked by Member Management Page (part 1) #2725
• Blocked by Manage Profile Page - "Editable" view AND "true read only" view #2789

[h-m-f-t]

@gabydisarli @AnnaGingle Can you take a look at the questions above and respond?

[gabydisarli]

1. Do we want to prioritize having a cancel status (allows Analyst to see what state it is in)? Can you add more clarity here? I'm not following
2. Does "in progress" mean anything that is not approved or rejected? Yes and I think we should not include Withdrawn as well. So in progress means anything Started, In review, Action needed
3. Are we missing a "view" of when we're about to remove a manager, who would be the last domain manager/sole domain manager that is left for a domain? Can you add more clarity here? I'm not following

[abroddrick]

@gabydisarli for 1:
This is not a blocking question on the ticket, it is more of a consideration for product on prioritization. We are adding in a cancel feature which makes multiple users in the same org able to cancel people's invitations. Adding in a cancel status on invitations would allow us to track invitations that have been canceled. There was a request for domain invitations to have this on django admin. Thus coupled with the knowledge that we want an audit log in the future, makes me think we should just go ahead and work in the invitation status of "canceled" into the model for domain invitation and portfolios. I would love people's thoughts here, but, to be clear, even if we did this it wouldn't be included in this ticket anyways.

Are we missing a "view" of when we're about to remove a manager, who would be the last domain manager/sole domain manager that is left for a domain? Can you add more clarity here? I'm not following
Picture is better, we have these:

The view I am referring to is one in which someone is the only domain manager. In the pic there is a alert mocked up for the last admin and has in progress request, but not "you can't remove this person because there is no other domain manager"

[AnnaGingle]

3. Are we missing a "view" of when we're about to remove a manager, who would be the last domain manager/sole domain manager that is left for a domain?

I don't think we need a separate design for each alert so I track them in the annotations right next to the design. This is the annotation, so no that is not missing.

[AnnaGingle]

1. Do we want to prioritize having a cancel status (allows Analyst to see what state it is in)?

This cancel invitation button isn't new, it exists on the domain managers page in the app today. Would a canceled status be helpful to them?

[gabydisarli]

@abroddrick Did Anna answer all your questions Alysia? I'd say for the for the canceled status, let's hold off on a decision until we do a design review. My hunch is let's wait for feedback from users, but also want to get a chance to look at the experience in a test environment to really make a determination.

[katypies]

@abroddrick to review this and update for implementation, including removal of the canceled status on the front-end while maintaining that status on the backend.

[abroddrick]

All questions resolved and refinement removed