[Awaiting Checklist] [$250] Workspace - #admin is displayed as #hidden for workspace member's LHN

[jponikarchuk]

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

---

Version Number: v9.2.47-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-1877/folder/13176685/41236618/1002487201
Email or phone of affected tester (no customers): gocemate+b2155020@gmail.com
Issue reported by: Applause Internal Team
Device used: Lenovo 80ES / Windows 10 Pro
App Component: Left Hand Navigation (LHN)

Action Performed:

1. Invite User B as member to workspace
2. User A creates a workspace room or text in workspace chat
3. User A mention #admins room
4. Take a look at User's B LHN and verify that #admins is displayed as #hidden
5. User A promote User B as admin
6. Take a look at User's B LHN and verify that #admins is displayed as #admins
7. User A promote User B as member again
8. Take a look at User's B LHN and verify that #admins is still displayed as #admins

Expected Result:

There should be #admins room displayed in LHN, just like in chat history

Actual Result:

#Hidden is displayed in LHN even user is a member of the workspace. It is displayed correctly only when promote member to admin, but when user is downgraded to member again, mentioning #admin is displayed as #admin

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @marufsharifi

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022036908618043241266
• Upwork Job ID: 2036908618043241266
• Last Price Increase: 2026-03-25

[melvin-bot]

Triggered auto assignment to @garrettmknight (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

📣 @MahmoodHashem! 📣
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>

[melvin-bot]

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

[melvin-bot]

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

[marufsharifi]

Proposal

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

When a regular workspace member is mentioned in a message that includes #admins, the mention is displayed as #hidden (as expected) because the member doesn’t have access to that chat.

However, after the member is promoted to an admin:

• The #admins room is added to their LHN.
• Mentions to #admins are correctly shown as #admins.

When the member is later downgraded back to a regular user:

• The #admins chat is removed from their LHN (correct behavior),
• But the last message still shows #admins instead of reverting to #hidden.

So the displayed label does not correctly update after access changes.

What is the root cause of that problem?

In Parser.ts

App/src/libs/Parser.ts

Lines 56 to 62 in 82a45ab

	htmlToText(htmlString: string, extras?: Extras): string {
	return super.htmlToText(htmlString, {
	reportIDToName: extras?.reportIDToName ?? reportIDToNameMap,
	accountIDToName: extras?.accountIDToName ?? accountIDToNameMap,
	cacheVideoAttributes: extras?.cacheVideoAttributes,
	});
	}

when the app renders <mention-report reportId=12342357>, it looks up the name from the reportIDToNameMap.

• Initially, since the user can’t access the report, it’s not present in reportIDToNameMap, so the parser shows #hidden.
• When the user becomes an admin, the report is added to the Onyx collection which updates reportIDToNameMap and shows #admins.

  App/src/libs/Parser.ts

  Lines 10 to 25 in 82a45ab

  	Onyx.connect({
  	key: ONYXKEYS.COLLECTION.REPORT,
  	waitForCollectionCallback: true,
  	callback: (value) => {
  	if (!value) {
  	return;
  	}
  	Object.values(value).forEach((report) => {
  	if (!report) {
  	return;
  	}
  	reportIDToNameMap[report.reportID] = report.reportName ?? report.reportID;
  	});
  	},
  	});

• But when the user is downgraded again, the report is removed from Onyx, yet it still remains in reportIDToNameMap , so the parser continues showing #admins instead of #hidden.

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

We should ensure that when a report is removed from the Onyx COLLECTION.REPORT, it is also removed from the in-memory reportIDToNameMap.

This could be done by modifying the Onyx.connect callback to rebuild or reconcile the map whenever the collection changes — for example:

Onyx.connect({
    key: ONYXKEYS.COLLECTION.REPORT,
    waitForCollectionCallback: true,
    callback: (reports) => {
        // Clear the map so removed reports don’t linger
        reportIDToNameMap = {};

        Object.values(reports || {}).forEach((report) => {
            if (!report) {
                return;
            }
            reportIDToNameMap[report.reportID] = report.reportName ?? report.reportID;
        });
    },
});

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[eVoloshchak]

@marufsharifi's proposal looks good to me!

🎀👀🎀 C+ reviewed!