Web- Users are disappears for a moment after click remove for restrict policy

[kbecciv]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Go to https://staging.expensify.com
2. Log in with expensifail account (admin account)
3. Go to Groups - Create Groups
4. Use any name for Permission group name
5. Unable Preferred Policy tag
6. Go to Group - Show members
7. Add a couple members to this group
8. On NewDot, try to remove the member from the workspace

Expected Result:

Users should be visible after click remove

Actual Result:

Users are disappears for a moment after click remove

Workaround:

Unknown

Platform:

Where is this issue occurring?

• Web

Version Number: 1.1.38.3

Reproducible in staging?: Yes

Reproducible in production?: No

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Recording.214.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause

Issue was found when executing: #7229

Slack conversation:

View all open jobs on GitHub

[MelvinBot]

Triggered auto assignment to @francoisl (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[francoisl]

According to the PR that was linked, this looks like the normal behavior we're expecting? Either way, I don't think it's an issue, that's what the setting in Domain Control is for after all - you can't remove people from a workspace (policy) if they're on a group that has that workspace set to the restricted policy.

cc @flodnv if you have any more context in case it's related to #7229

[flodnv]

Yeah, I am not sure if this is a bug or a feature. We could indeed make it that they don't disappear before an error, but it all depends on the UX paradigms we want to follow. @marcaaron @tgolen what are your thoughts on this one?

[marcaaron]

Seems like expected behavior to me. We are assuming that the users can be removed before making the API request. If we later find out they can't be removed they are re-added to the list. That's the idea behind an optimistic response and makes the UI feel snappier in general. I guess when the optimistic response is wrong it could be perceived as jarring, but we give the user an error message which tells them what went wrong so I don't really see the problem.

[flodnv]

Agreed, thanks for your thoughts!

[tgolen]

Yeah, I agree with Marc about that's how I would expect an error on an optimistic action to be handled.

However, in this case, I think if we don't EVER allow that operation, then the UI shouldn't allow the user to do that action in the first place. That's where I think we can improve the UX of this.

I know we currently don't have any concept of domain control in App, but it's being added as part of the changes to N7 Account settings. Seems like we could use that domain control information to disable the UI here.

[flodnv]

I am not sure if what we're adding in N7 will support this, but I agree with the overall direction.