[$250] [Collect] Workspace - User name and avatar disappears when opening profile immediately after invite

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 1.4.56-2 Reproducible in staging?: Y Reproducible in production?: Y Logs: https://stackoverflow.com/c/expensify/questions/4856 Issue reported by: Applause-Internal team

Action Performed:

Precondition:

• User is admin of Collect workspace.

1. Go to staging.new.expensify.com.
2. Go to Profile > Workspaces > Collect workspace.
3. Go to Members.
4. Invite a new member that does not have Expensify account.
5. Immediately after inviting the member, click on the highlighted new user in the list.

Expected Result:

The user name and avatar will not disappear.

Actual Result:

The user name disappears and avatar changes to placeholder avatar.

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• [x] Android: Native
• [x] Android: mWeb Chrome
• [x] iOS: Native
• [x] iOS: mWeb Safari
• [x] MacOS: Chrome / Safari
• [x] MacOS: Desktop

Screenshots/Videos

https://github.com/Expensify/App/assets/115492554/e207297d-5428-4893-909c-3717d93be0a6

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~011d6aa43dad80012f
• Upwork Job ID: 1778901063514075136
• Last Price Increase: 2024-04-12

[melvin-bot[bot]]

Triggered auto assignment to @strepanier03 (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[izarutskaya]

We think that this bug might be related to #wave-control.

[bernhardoj]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The user name and avatar disappear if we view the recently added workspace member. We can easily reproduce this by adding the member while offline, viewing the member detail, and go online.

What is the root cause of that problem?

When we start adding a new member, we generate an optimistic personal detail for that user and clear it when the request is successful. https://github.com/Expensify/App/blob/b3baa68ac50d1c75e52385b4e60ce581de7baa24/src/libs/actions/Policy.ts#L1130-L1138 https://github.com/Expensify/App/blob/b3baa68ac50d1c75e52385b4e60ce581de7baa24/src/libs/actions/Policy.ts#L1143-L1161

That's why after the request is completed, the name and avatar disappear because we are viewing the optimistic personal detail data that is already gone.

What changes do you think we should make in order to solve the problem?

We can disable it when the personal detail is still an optimistic one until we receive the correct personal detail from the server. This is what we do in several places too, for example: https://github.com/Expensify/App/blob/b3baa68ac50d1c75e52385b4e60ce581de7baa24/src/components/ReportWelcomeText.tsx#L143-L153 https://github.com/Expensify/App/blob/1c632fe194cd634d6024965f13d3605043f32ed6/src/components/MoneyTemporaryForRefactorRequestConfirmationList.js#L422-L425

First, add isOptimisticPersonalDetail: true to getNewPersonalDetailsOnyxData. https://github.com/Expensify/App/blob/1c632fe194cd634d6024965f13d3605043f32ed6/src/libs/PersonalDetailsUtils.ts#L125-L138

Then, disable it when isOptimisticPersonalDetail is true. https://github.com/Expensify/App/blob/1c632fe194cd634d6024965f13d3605043f32ed6/src/pages/workspace/WorkspaceMembersPage.tsx#L362-L367

This will disable the checkbox too, we can customize to not disable the checkbox, but I don't think that's a good idea separating the checkbox disabled state and the row disabled state. Or we can keep it enable, but do nothing when clicked (or just toggle the checkbox when clicked).

optionally we can show not found page on member detail page when it's an optimistic personal detail, but I see we don't do that for profile page, so not sure whether we want to do this or not

What alternative solutions did you explore? (Optional)

Don't clear the optimistic personal detail, but this would keep stacking unnecessary data every time we add a new member. Also, it's useless for the user to see the outdated optimistic personal detail when the server already sends us the correct data.

or don't rerender the detail page when personal details change. we can use memo for this case.

Another alternative is, save the member optimistic login in a ref, then if the member personal details become empty, iterate through the policy members collection and find the one that has the same login. If found, close the current member page and navigate to the new one. But this would fail if we invite the user with their secondary login.

[bernhardoj]

Just FYI, we don't need to perform the 5th step quickly. We can perform it while offline to reproduce it easier.

1. Go offline
2. Add a new member (any user that doesn't exist in your contact, it can be a registered expensify user or non-registered, doesn't matter)
3. Click the member to open the detail
4. Go online
5. Wait for a few seconds until the apps reconnecting and the name and avatar will disappear

[strepanier03]

Hmmm, I'm having a slightly different experience with the avatar, but the username isn't an issue when testing Mac/Chrome and Android mobile web for me.

---

On both here's what I am doing and seeing:

1. Go to staging.new.expensify.com.
2. Go to Profile > Workspaces > Collect workspace.
3. Go to Members.
4. Invite a new member that does not have Expensify account.
5. Immediately after inviting the member, click on the highlighted new user in the list.

Expected Result: The user name and avatar will not disappear and remain as they appear until the user updates them..

Actual Result: In the RHP the username and avatar remain as they appear initially, but in the member table the avatar changes to a different default avatar. Pressing back and then clicking on the new member, shows the updated avatar.

https://github.com/Expensify/App/assets/10925636/17efd9f8-27d2-4f97-a3bf-b79485cc9c78

[bernhardoj]

@strepanier03 did you test it on a collect workspace? Looking at the left side of the workspace menu, I guess it's a free workspace. The new RHP for workspace member detail (instead of a profile page that is shown in your video) is only available for collect workspace.

[strepanier03]

I'll retest, I made a collect workspace but maybe clicked the wrong button afterward and added on the free workspace.

[strepanier03]

Running into an issue recreating this. I get a "Hmm ... its not here" in the RHP when clicking on any Collect workspace member.

I'm going to ask for a hand repro'ing and then tie to a project.

[strepanier03]

Not sure what was different on the second collect workspace I made but I was able to repro with a fresh slate.

https://github.com/Expensify/App/assets/10925636/7f8e95b3-cd63-4859-840f-b9da3d09e21c

[melvin-bot[bot]]

@strepanier03 this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot[bot]]

@strepanier03 10 days overdue. Is anyone even seeing these? Hello?

[melvin-bot[bot]]

@strepanier03 12 days overdue now... This issue's end is nigh!

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~011d6aa43dad80012f

[melvin-bot[bot]]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ikevin127 (External)

[nkdengineer]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The user name disappears and avatar changes to placeholder avatar.

What is the root cause of that problem?

The problem here happens because when we add a new workspace member, if that member doesn't exist in personal details list yet, we'll create optimistic personal details for them and then clearing the personal details after the request is done, see here.

This leads to the user seeing user name and avatar disappearing because the optimistic personal details is gone now.

What changes do you think we should make in order to solve the problem?

We had this same problem with the optimistic report: we create a new optimistic report with a user, but the report with that user already exists, so what we did is we'll navigate to the new report when the API request is successful.

Here's exactly how we implement it, we should do the same for the optimistic personal detail in this case

• Do not clear the personal details of the existing users when the API request is successful
• Modify the back-end to merge preexistingAccountID into the personalDetailsList item of the current optimistic personal detail created in front end. For example, if the optimisticAccountID created in front-end is 123456, and the actual accountID of the existing user is 654321, then the backend will return this Onyx data:

{
  "key": "personalDetailsList",
  "onyxMethod": "merge",
  "value": {
    "123456": {
      "preexistingAccountID": 654321
  }
}

• Now, in the front-end, when we detect that there's the preexistingAccountID being merged into personalDetailsList, we'll do the following (same as here for report):
  • Check if the user is on the workspace member URL with optimistic account ID, if yes, navigate the user to the workspace member URL with the preexistingAccountID
  • Clear the optimistic personal details

This is the same approach as we did with the optimistic report, just that we do for optimistic personal details now. This will make sure the user has a seamless experience when using the product.

What alternative solutions did you explore? (Optional)

NA

[strepanier03]

@ikevin127 - Friendly bump on the proposal here, thanks!

[ikevin127]

@strepanier03 Sorry, didn't get notified 3 days ago.

I will review the mentioned proposal and get back in the next 24h.

Should I consider @bernhardoj's proposal too, since it was the first one on this issue ?

[ikevin127]

@nkdengineer @bernhardoj Could you please provide a video result of your best solution in terms of UI ?

Note: for the proposal involving BE changes, try to mock the BE response using a timeout, simply for the sake of demonstrating the video result in terms of UI.

I am asking for this so we can make a decision on which proposal to go with since one of them is proposing a strictly FE fix and the other one involves BE changes. I plan to tag the design team once we have the videos and decide if this could be addressed strictly from the FE side or whether to involve somebody from the BE team and have a BE / FE fix.

[bernhardoj]

Here is mine

https://github.com/Expensify/App/assets/50919443/fa49774e-83cd-46fe-b64b-b03f41493b00

[nkdengineer]

@nkdengineer @bernhardoj Could you please provide a video result of your best solution in terms of UI ?

Sure, I'll provide this tomorrow since I need to do some mocking of the BE.

[nkdengineer]

@nkdengineer @bernhardoj Could you please provide a video result of your best solution in terms of UI ?

@ikevin127 Here's the UX in my solution

https://github.com/Expensify/App/assets/161821005/80da0d40-4214-4900-8f33-411bb11a206c

[ikevin127]

@bernhardoj Thanks for your early proposal. After careful consideration I decided to move on with the other proposal since as per the expected result of the issue, that fits best as a solution to our issue.

Why ? To be more specific I'm referring to the behaviour your video from here suggested: even if say we would disable (gray-out) the option until the BE response arrives, that looks more like a workaround considering the expected result, and additionally I did not see this behaviour anywhere else in the app when it comes to a call's optimistic -> success transition.

[ikevin127]

Expected result:

The user name and avatar will not disappear.

As per the expected result of the issue, I think @nkdengineer's proposal fits best as a solution here. The RCA is correct and the proposed solution fixes the issue as suggested by the expected result.

🎀👀🎀 C+ reviewed

[melvin-bot[bot]]

Triggered auto assignment to @techievivek, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[ikevin127]

[!note] Considering BE changes are needed as part of the selected proposal's solution, I noticed that in the issue https://github.com/Expensify/App/issues/15511 and PR https://github.com/Expensify/App/pull/24320 which did something similar here, @puneetlath handled the BE side, therefore I'd suggest them for handling the BE part here too if they have the capacity.

@techievivek Otherwise, please let us know who could handle the BE side of the proposed solution. Thank you!

[techievivek]

Just a quick question so I understand the RCA and then I can handle the BE changes.

The problem here happens because when we add a new workspace member

Could you please confirm whether this issue occurs for a user who doesn't exist in our database, or if it happens when the user might exist in the database but we don't have their personal details locally? I ask because if the user doesn't exist, are we sending the optimistic accountID in the request? If so, why doesn't it match what we finally receive in the response?

[techievivek]

Reproduction step says this.

Invite a new member that does not have Expensify account.

[techievivek]

In report case, it makes sense that the optimistically generated reportID doesn't match the backend reportID as a chat already exists between users but here the RCA is not clear to me.

[ikevin127]

Could you please confirm whether this issue occurs for a user who doesn't exist in our database

As far as my understanding goes, this is correct. It occurs for a user who doesn't exist in our database.

I ask because if the user doesn't exist, are we sending the optimistic accountID in the request? If so, why doesn't it match what we finally receive in the response?

In report case, it makes sense that the optimistically generated reportID doesn't match the backend reportID as a chat already exists between users but here the RCA is not clear to me.

@nkdengineer Could you please clarify ? Thank you!

[nkdengineer]

@techievivek @ikevin127

Could you please confirm whether this issue occurs for a user who doesn't exist in our database, or if it happens when the user might exist in the database but we don't have their personal details locally?

This happens in both these cases

I ask because if the user doesn't exist, are we sending the optimistic accountID in the request?

No we're not sending optimistic accountID in the request in this case, we're only sending the emails

If so, why doesn't it match what we finally receive in the response?

@techievivek Even if we send the accountID to the back-end (tested), the back-end seems not to be using the optimistic accountID that was sent from front-end to create the user. The back-end will always send back a brand new accountID (different from the one optimistically generated from front-end)