[Hold for #36378][$500] The member list of a public room shows inconsistent results

[m-natarajan]

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.43-14
Reproducible in staging?:
Reproducible in production?:
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: @quinthar
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1708893734376029

Action Performed:

Precondition: Have a public room, users with real accounts and anonymous users without email contact information

1. Go to the public room
2. Click on the header to see the details of the room
3. Look at the members count
4. Click on the members to see the members list
5. Go back to the details page and look at the members count

Expected Result:

Should show the same number of the members

Actual Result:

It first showing the correct number of people who have signed in with real accounts and when opening the members list and going back it includes anonymous user (who didn't provide any email contact information)

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

Recording.2780.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01a589af5940630bea
• Upwork Job ID: 1761932775026454528
• Last Price Increase: 2024-02-26

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01a589af5940630bea

[melvin-bot]

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

[kadiealexander]

Reproduced in chrome.

[brunovjk]

I believe they are similar #36378

[wildan-m]

Proposal

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

The member list of a public room shows inconsistent results

What is the root cause of that problem?

We have not omitted any visible members without personal details on the report detail page.

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

Filter visible members with personal details in getVisibleMemberIDs

function getVisibleMemberIDs(report: OnyxEntry<Report>): number[] {
    if (!report) {
        return [];
    }
    const visibleChatMemberAccountIDs = report.visibleChatMemberAccountIDs ?? [];

    let visibleMemberIDs: number[] = [];
    report?.visibleChatMemberAccountIDs?.forEach((accountID) => {
        const details = allPersonalDetails?.[accountID];

        if (!details) {
            return;
        }

        visibleMemberIDs.push(accountID);
    });

    // Build participants list for IOU/expense reports
    if (isMoneyRequestReport(report)) {
        const onlyTruthyValues = [report.managerID, report.ownerAccountID, ...visibleChatMemberAccountIDs].filter(Boolean) as number[];
        const onlyUnique = [...new Set([...onlyTruthyValues])];
        return onlyUnique;
    }

    return visibleMemberIDs;}

Then we can modify this code to optimize loop:

App/src/pages/RoomMembersPage.tsx

Lines 156 to 161 in 89d5689

	const details = personalDetails[accountID];
	if (!details) {
	Log.hmmm(`[RoomMembersPage] no personal details found for room member with accountID: ${accountID}`);
	return;
	}

Modify to:

        const participants = useMemo(() => ReportUtils.getVisibleMemberIDs(report), [report]);
        participants.forEach((accountID) => {
            const details = personalDetails[accountID];

            if (!details) {
                Log.hmmm(`[RoomMembersPage] no personal details found for room member with accountID: ${accountID}`);
                return;
            }

We could also add filtering per page in ReportDetailsPage.tsx, similar to what RoomMembersPage did.

What alternative solutions did you explore? (Optional)

Do we intend to display all members, even if they do not have personal details? If so, we can omit the null check on the personalDetails data.

We can remove return and fallback null to empty object in getMemberOptions. Change

App/src/pages/RoomMembersPage.tsx

Lines 152 to 161 in 89d5689

	const getMemberOptions = (): ListItem[] => {
	let result: ListItem[] = [];
	report?.visibleChatMemberAccountIDs?.forEach((accountID) => {
	const details = personalDetails[accountID];
	if (!details) {
	Log.hmmm(`[RoomMembersPage] no personal details found for room member with accountID: ${accountID}`);
	return;
	}

To:

    const getMemberOptions = (): ListItem[] => {
        let result: ListItem[] = [];

        report?.visibleChatMemberAccountIDs?.forEach((accountID) => {
            const details = personalDetails[accountID] || {} as PersonalDetails;
            if (!details) {
                Log.hmmm(`[RoomMembersPage] no personal details found for room member with accountID: ${accountID}`);
            }

It will show "Hidden" since the returned value after the invite is an empty object. I believe the room admin/owner should be able to view at least the registered contact (email/number) so they can identify the members (Require backend change). This is a suggestion for the returned object for non-registered users, it has the same structure as optimistic data.

{
    "login": "[email protected]",
    "accountID": 83056826,
    "avatar": "https://d2k5nsl2zxldvw.cloudfront.net/images/avatars/default-avatar_3.png",
    "displayName": "[email protected]"
}

[mkhutornyi]

I believe they are similar #36378

Agree. I think we can hold this for #36378

[Emrullah-Akbulak]

Proposal

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

Member count in a public room's details shows inconsistency when the user enters the "RoomMembersPage" and goes back to the "ReportDetailsPage".

What is the root cause of that problem?

When user opens a room the client sends an API command called "OpenReport" which returns the report information that is used to display the room's details such as member count. However, when the user navigates to "RoomMembersPage" via clicking "Members" button, the client sends another command called "OpenRoomMembersPage". This new command's response returns new object which has the following properties "participantAccountIDs", "participants", "visibleChatMemberAccountIDs", then this fields gets merged with the existing report via Onyx.

The problem is the participantAccountIDs fields between these requests "OpenReport" and "RoomMembersPage" returns different values and that causes "RoomMembersPage" command's response to override these 3 fields. When the fields get overwritten, the following code in "ReportDetailsPage"

const participants = useMemo(() => {
        console.log("I have RUN" ,report);
        return ReportUtils.getVisibleMemberIDs(report)
    }, [report]);

updates the participant count with the new overwritten values due to report object being updated by "OpenRoomMembersPage" command. Hence the member count changes when the user navigates & go backs from the "RoomMembersPage".

Moreover, the code that calls the "OpenRoomMembersPage" command is located at RoomMembersPage and wrapped in useEffect hook that runs only once the component mounts.

    const getRoomMembers = useCallback(() => {
        if (!report) {
            return;
        }
        Report.openRoomMembersPage(report.reportID);
        setDidLoadRoomMembers(true);
    }, [report]);

    useEffect(() => {
        getRoomMembers();
        // eslint-disable-next-line react-hooks/exhaustive-deps
    }, [])

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

Assuming that "OpenReport" command returns the true value of the report. The "OpenRoomMembersPage" should either use the same filtration as the "OpenReport" command so that it filters and returns the same number of members to client.

What alternative solutions did you explore? (Optional)

In my opinion, the "OpenRoomMembersPage" command can also be completely removed or altered since it permanently adds the "participantAccountIDs", "participants", "visibleChatMemberAccountIDs" fields to report object for no apparent reason other then being used in "RoomMembersPage" page . I haven't checked all the code that uses these fields but if these 3 fields are only going to be added once the user enter the "RoomMembersPage " page then they should get disposed and not permanently alter the report object when the user goes back.

[melvin-bot]

📣 @Emrullah-Akbulak! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[Emrullah-Akbulak]

Contributor details
Your Expensify account email: [email protected]
Upwork Profile Link: https://www.upwork.com/freelancers/~01565aae43960f7cbc

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[kadiealexander]

Holding for #36378!

[kadiealexander]

Still on hold.

[kadiealexander]

Same

[kadiealexander]

Still on hold.

[kadiealexander]

Still on hold.

[kadiealexander]

Asked for a retest here.

[kbecciv]

QA team is unable to reproduce it on build 1.4.74.3

Recording.477.mp4

Recording.476.mp4