Room - Member avatar changes after being invited to the room

[lanitochka17]

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.21-4
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Issue found when executing PR #33077

Action Performed:

1. Go to FAB > Start chat > Room
2. Create a room
3. Open room chat > Click room header
4. Click Members > Invite
5. Invite a few users with default avatar

Expected Result:

The member avatar will not change after being invited to the room

Actual Result:

The member avatar changes after being invited to the room
Each member shares the same default avatar after being invited to the room

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6332185_1704377196286.20240104_155317.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~018d16ed2710b34987
• Upwork Job ID: 1743087330455277568
• Last Price Increase: 2024-01-26

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~018d16ed2710b34987

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

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

[tienifr]

Proposal

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

The member avatar changes after being invited to the room
Each member shares the same default avatar after being invited to the room

What is the root cause of that problem?

There're 2 problems:

1. In Invite MemberPage, we use getIcons, but in RoomMemberPage, we use getAvatar that makes the inconsistency
2. InviteRoom API return the new avatar so we can see it's changed after member being invited

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

1. We should use getAvatar for icons in here

result.icons = [{
        source:  UserUtils.getAvatar(personalDetail.avatar, personalDetail.accountID),
        type: CONST.ICON_TYPE_AVATAR,
        name: personalDetail.login,
        id: personalDetail.accountID,
    }]

Or we can use getIcons in here
2. BE should be fix to return the correct avatar

What alternative solutions did you explore? (Optional)

NA

[Christinadobrzyn]

Oh yeah, this does happen.

I think this can be part of vip-vsp.

I'm going ooo next week so adding a BZ teammate to monitor this while I'm gone.

Status- we need to review proposals.

[melvin-bot]

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

[ntdiary]

1. In Invite MemberPage, we use getIcons, but in RoomMemberPage, we use getAvatar that makes the inconsistency
2. InviteRoom API return the new avatar so we can see it's changed after member being invited

So far, I observed the second problem (backend). As for the first one, the createOption is used in several other lists, so I think we need to handle it with caution.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@johncschuster, @ntdiary, @Christinadobrzyn Huh... This is 4 days overdue. Who can take care of this?

[Christinadobrzyn]

I'm going to be ooo this week as well but from what I can see, I think we're still waiting on proposals - @ntdiary should we raise the bounty?

[ntdiary]

I'm going to be ooo this week as well but from what I can see, I think we're still waiting on proposals - @ntdiary should we raise the bounty?

@Christinadobrzyn, eh, I feel what we need is to request a backend engineer to check the API InviteToRoom, why it returns the same avatar url. :)

[grgia]

yes @Christinadobrzyn moving to weekly!

[grgia]

Sorry for the delay here- here's my thoughts

We can probably solve some of these if we

• start storing the avatar in the avatar field regardless of default or not (right now, we only store custom avatars for newdot)

The main problem I see is that because we now use accountIDs, something that we cannot predict for a new user- any user that is invited that doesn't have an account will not use the correct avatar. This is partially why I used emails to hash in the original design.

With the privacy issue, storing the default avatar in known users would solve this problem- but I'm not sure what we would do about "guessing" a user's default avatar for a user that doesn't exist yet. Maybe we should go back to using fallback avatar for any users that you don't know?

What do you think @puneetlath @Beamanator (accountIDs/privacy perspective) and @shawnborton / @dannymcclain / @dubielzyk-expensify (design perspective)

Please let me know if you need any clarification

[dannymcclain]

@grgia so are you suggesting something like this?

Where Quad Cowboy is a known user with one of our default avatars and [email protected] is not yet a known user, so we give them the fallback avatar instead of assigning them a default avatar? And then once they become a known user, we'd assign them a random default avatar?

[shawnborton]

Ooo yeah that's a tricky one, but I quite like Danny's suggestion.

[dubielzyk-expensify]

Agree that I like what D-man has suggested here

[puneetlath]

I like @dannymcclain's suggestion. So we'd use that fallback avatar whenever we have user with an optimistic accountID. But replace it whenever we have a real accountID.

[grgia]

whenever we have user with an optimistic accountID

@puneetlath how do we calculate/set optimistic accountIDs?

Edit: nvm, I see you're agreeing we use this fallback for optimistic accountIDs (AKA any time we dont have the real accountID for a user)

[grgia]

One question I have, do we care on a privacy level if users know whether or not you have an account? Is it better to have a mismatched avatar temporarily, but every account appears "created". Versus distinguishing to users between accounts that do and don't exist

Screen.Recording.2024-03-20.at.1.22.31.PM.mov

[grgia]

If the above video looks good, I can push these changes :)

[dannymcclain]

I think the above video looks good, and I can actually see the ability to distinguish between the two being beneficial for users—but I didn't consider any privacy concerns, so I want to let someone else weigh in on that point too.

[shawnborton]

Hmm great question - I say bring that one to Slack for others to weigh in, as I'm not sure what the best answer is.

[melvin-bot]

This issue has not been updated in over 15 days. @ntdiary, @grgia, @Christinadobrzyn eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[Christinadobrzyn]

hi! Just checking on this, is there anything I can do to help? It looks like we're working on a PR - #38674

[Christinadobrzyn]

PR - #38674 is closed - I'll retest tomorrow

[Christinadobrzyn]

Testing again, I think this is fixed. Going to ask QA to test. https://expensify.slack.com/archives/C9YU7BX5M/p1718242220561929

[kavimuru]

@Christinadobrzyn bug is fixed.

20240613_231100.mp4

[Christinadobrzyn]

Awesome! I'll close this since the bug is fixed. @grgia let me know if you feel otherwise and we can reopen.