[$250] Teacher Chat- Principal can see Join button in Teacher's Chat despite is already a member

[nlemma]

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.3.55-0
Reproducible in staging?: Yes
Reproducible in production?: Unable to validate in Prod - error happens when teacher tries to add themselves.
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-17112/folder/13176687/41237965/1317000027?sort=%2Bidentifier&p=2
Email or phone of affected tester (no customers): applausetester+prin100@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10
App Component: Chat Report View

Action Performed:

Precondition: Principal has invited a Teacher to join, and Teacher is already joined.

1. Login with a new Expensifail account for "Principal"
2. Navigate to inbox
3. Verify the workspace chat with the teacher for the "Teachers Unite! testing policy" is displayed
   Result: teacher's chat is accesible only via search
4. Click on the workspace chat
   Result: Principal can see "Join" button
5. Click on the header
6. Verify there are 4 members, the principal, the teacher, the expensify.org admin and the Auditor
   Result: Principal can see "Join" button
7. Click on "Join"
   Result: Join disappears

Expected Result:

Teacher's chat should displas in LHN, and "Join" button should not displayed as Principal is already a member on the chat

Actual Result:

Teacher's chat is accesible only via search, and Principal can see Join button in Teacher's Chat despite is already a member

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7125466_1775705065778.bandicam_2026-04-08_22-00-48-222.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @arosiclair

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042183165760248352
• Upwork Job ID: 2042183165760248352
• Last Price Increase: 2026-04-09

[MelvinBot]

Proposal

What is the root cause of that problem?

The Principal's accountID is missing from report.participants on the Teacher's workspace chat. The client-side addSchoolPrincipal() (TeachersUnite.ts:81-91) only creates an optimistic POLICY_EXPENSE_CHAT with the Teacher as participant — the Principal's email is sent to the backend as partnerUserID, and the backend AddSchoolPrincipal command is solely responsible for adding the Principal to the workspace and their chat membership.

When the Principal is not in report.participants, getReportNotificationPreference() returns HIDDEN (because undefined || HIDDEN = HIDDEN). This causes two symptoms:

1. Join button shown: canJoinChat() sees the report as hidden (doesn't exit early at L11259), then returns true via isNonAdminOrOwnerOfPolicyExpenseChat() — because the Principal is neither policy admin, policy owner, nor report owner.
2. Chat not in LHN: The report with a hidden notification preference is filtered out by reasonForReportToBeInOptionList(), making it only accessible via search.

A key difference from the standard AddMembersToWorkspace flow is that reportCreationData in addSchoolPrincipal only maps the Teacher's email to an optimistic reportID — the Principal's email is absent from reportCreationData. If the backend uses this mapping to determine which chats to create (as AddMembersToWorkspace does), the Principal's chat would never be properly set up.

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

This is likely a backend issue in the AddSchoolPrincipal command handler — the Principal needs to be added as a participant with a non-hidden notificationPreference to the relevant workspace chat. The backend command should ensure the Principal is added to the Teachers Unite policy's employeeList and that a POLICY_EXPENSE_CHAT is created (or updated) with the Principal as a proper participant.

As a client-side defensive fix, canJoinChat() in ReportUtils.ts could be hardened to distinguish between "user left the chat (has participant entry with hidden pref)" and "user was never a participant." Currently both cases are treated identically. Adding a check like report.participants?.[currentUserAccountID] !== undefined before allowing Join on a POLICY_EXPENSE_CHAT would prevent showing the Join button to users who were never added as participants.

What alternative solutions did you explore?

An alternative would be to fix only the addSchoolPrincipal client-side action to include the Principal in reportCreationData (similar to how AddMembersToWorkspace includes all invited members). However, this alone may not fix the issue if the backend's AddSchoolPrincipal handler has its own logic for member setup. The backend fix is the more robust approach since it's the source of truth for workspace membership.

Investigation details

Evidence chain:

Step	Code	What happens
1	TeachersUnite.ts:81-91	Teacher calls addSchoolPrincipal(), optimistic chat created with participantList: [sessionAccountID] (Teacher only)
2	TeachersUnite.ts:230-238	Backend receives Principal's email as partnerUserID but reportCreationData only maps Teacher's email
3	ReportUtils.ts:1911-1917	getReportNotificationPreference() looks up report.participants[principalAccountID] → undefined → returns HIDDEN
4	ReportUtils.ts:2245-2253	isHiddenForCurrentUser() returns true
5	ReportUtils.ts:11259	canJoinChat() does NOT exit early (early exit is for non-hidden)
6	ReportUtils.ts:11226-11228	isNonAdminOrOwnerOfPolicyExpenseChat() returns true (Principal is not admin/owner)
7	ReportUtils.ts:11283	canJoinChat() returns true → Join button rendered in HeaderView.tsx:392,416

Related constants: Teachers Unite uses hardcoded policy B795B6319125BDF2 (prod) defined in CONST/index.ts:6139-6146.

No duplicate issues found in the open issue tracker.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[MobileMage]

Proposal

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

A Principal who is already a member of a Teacher's Chat (a user-created policy room) still sees a "Join" button in the chat header, even though they are already a participant of that room.

What is the root cause of that problem?

The canJoinChat function in ReportUtils.ts determines whether to show the Join button. Its very first guard is !isHiddenForCurrentUser(report), which checks the current user's notificationPreference on the report. isHiddenForCurrentUser returns true (i.e., the report is hidden) when notificationPreference is 'hidden', empty, null, or undefined. This means: if the Principal is a participant of the room but their notificationPreference happens to be 'hidden' or is missing from Onyx, the first guard does not short-circuit — it falls through to the final return on line 11283, which returns true for any isUserCreatedPolicyRoom. The Join button then appears even though the user already belongs to the room.

The correct condition for "user is already a member" is whether they exist in report.participants, not whether their notification preference is non-hidden. A user can be a participant of a room while having a 'hidden' notification preference (e.g., they joined, then muted, or the preference was never explicitly set on their side).

App/src/libs/ReportUtils.ts

Lines 11245 to 11283 in 2f8e65f

	function canJoinChat(
	report: OnyxEntry<Report>,
	parentReportAction: OnyxInputOrEntry<ReportAction>,
	policy: OnyxEntry<Policy>,
	parentReport: OnyxEntry<Report>,
	isReportArchived = false,
	): boolean {
	// We disabled thread functions for whisper action
	// So we should not show join option for existing thread on whisper message that has already been left, or manually leave it
	if (isWhisperAction(parentReportAction)) {
	return false;
	}
	// If the notification preference of the chat is not hidden that means we have already joined the chat
	if (!isHiddenForCurrentUser(report)) {
	return false;
	}
	const isExpenseChat = isMoneyRequestReport(report) || isMoneyRequest(report) || isInvoiceReport(report) || isTrackExpenseReportNew(report, parentReport, parentReportAction);
	// Anyone viewing these chat types is already a participant and therefore cannot join
	if (isRootGroupChat(report, isReportArchived) || isSelfDM(report) || isInvoiceRoom(report) || isSystemChat(report) || isExpenseChat) {
	return false;
	}
	// The user who is a member of the workspace has already joined the public announce room.
	if (isPublicAnnounceRoom(report) && !isEmptyObject(policy)) {
	return false;
	}
	// For restricted visibility rooms, the user must be a workspace member to join
	if (isUserCreatedPolicyRoom(report) && report?.visibility === CONST.REPORT.VISIBILITY.RESTRICTED && !isPolicyMember(policy, deprecatedCurrentUserEmail)) {
	return false;
	}
	if (isReportArchived) {
	return false;
	}
	return isChatThread(report) || isUserCreatedPolicyRoom(report) || isNonAdminOrOwnerOfPolicyExpenseChat(report, policy);

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

Add an explicit participant check before evaluating the notification preference. If deprecatedCurrentUserAccountID is already present in report.participants, the user is already a member and the Join button must not be shown. The notification preference check can remain as a secondary signal for cases where the user is not a participant, but it should not be the sole guard against showing Join.

App/src/libs/ReportUtils.ts

Lines 11258 to 11261 in 2f8e65f

	// If the notification preference of the chat is not hidden that means we have already joined the chat
	if (!isHiddenForCurrentUser(report)) {
	return false;
	}

 function canJoinChat(
     report: OnyxEntry<Report>,
     parentReportAction: OnyxInputOrEntry<ReportAction>,
     policy: OnyxEntry<Policy>,
     parentReport: OnyxEntry<Report>,
     isReportArchived = false,
 ): boolean {
     if (isWhisperAction(parentReportAction)) {
         return false;
     }

-    // If the notification preference of the chat is not hidden that means we have already joined the chat
-    if (!isHiddenForCurrentUser(report)) {
+    // If the current user is already a participant of the report, they have already joined
+    if (deprecatedCurrentUserAccountID && report?.participants?.[deprecatedCurrentUserAccountID] !== undefined) {
         return false;
     }

This replaces the notification-preference guard with a direct participant membership check. A user present in report.participants has definitively joined the room, regardless of what their notification preference is set to. The rest of the function's early-exit conditions (archived, group chat, invoice room, etc.) remain unchanged.

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

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

[Tony-MK]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @Tony-MK Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[brunovjk]

I believe we can go with @MobileMage's proposal. The fix is ​​surgical, testable, and prevents the Join button from appearing for any user who is already a participant. Thanks.

🎀 👀 🎀 C+ reviewed