[$250] Composer Not Visible in Workspace Chat and Report Threads

[m-natarajan]

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:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
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 (hyperlinked to channel name): #Quality

Action Performed:

1. Navigate to a workspace chat
2. Open a report thread within the workspace chat
3. Observe the bottom of the screen

Expected Result:

The composer input field should be visible

Actual Result:

Composer is not visible

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshot and onyx data for the issue is in Slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @KioCoan

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022041504978208870859
• Upwork Job ID: 2041504978208870859
• Last Price Increase: 2026-04-14

[MelvinBot]

Proposal

What is the root cause of that problem?

The composer visibility in ReportFooter.tsx is gated by canUserPerformWriteAction (ReportFooter.tsx:77-78). On desktop, the composer renders when shouldHideComposer is false (line 90). When canUserPerformWriteAction returns false, the code falls through a series of fallback conditions (archived, anonymous, blocked, system chat, admins-only) and if none match, returns null at line 175 — rendering nothing with no explanation to the user.

For workspace chat threads, the most likely failing condition is in the permission chain:

1. canWriteInReport (ReportUtils.ts:2462-2468) — If the backend returns a permissions array on the thread report that doesn't include 'write', the composer is hidden. This is entirely backend-driven with no client-side fallback.

2. isAllowedToComment (ReportUtils.ts:2473-2494) — If writeCapability is set to anything other than 'all' on the thread report and the user is not a policy admin, commenting is blocked. Critically, if allPolicies hasn't loaded when this runs, any restricted-capability report returns false.

3. Thread creation doesn't inherit writeCapability — In createChildReport (Report/index.ts:2086-2098), the optimistic thread report is built without passing writeCapability from the parent. The thread defaults to 'all' optimistically, but the backend response may override with a restricted value.

The "admins-only" banner fallback (line 157) checks the thread report's writeCapability, not the parent's. So if the backend restricts the thread via the permissions array instead of writeCapability, the banner won't show and the user sees nothing — the composer simply disappears.

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

The fix depends on which condition is failing, which can be confirmed by inspecting the Onyx data in the linked Slack thread. There are two likely scenarios:

Scenario A — Backend permissions array on thread report lacks 'write':
The thread report inherits a restrictive permissions array from the backend. The fix would be in the backend to ensure workspace chat thread reports include 'write' permission for eligible participants. On the client side, ReportFooter.tsx should also show a meaningful message (similar to the admins-only banner) when the composer is hidden due to canWriteInReport returning false, instead of silently returning null.

Scenario B — writeCapability or policy data race:
If allPolicies hasn't loaded when isAllowedToComment evaluates a thread with any non-default writeCapability, commenting is blocked. The fix would be to treat a missing policy as permissive (show the composer) rather than restrictive, or defer the write-action check until policies are loaded.

In either case, the silent return null at ReportFooter.tsx:175 should be replaced with an informative fallback banner so users aren't left with no explanation when the composer is hidden.

What alternative solutions did you explore? (Optional)

An alternative is to have thread reports inherit writeCapability from their parent workspace chat during optimistic creation in createChildReport. This would ensure the admins-only banner shows correctly for threads in restricted rooms. However, this alone wouldn't fix the case where the permissions array is the restricting factor.

Investigation details

Key code paths:

• ReportFooter.tsx:90 — Composer renders when !shouldHideComposer && (shouldShowComposeInput || !isSmallScreenWidth)
• ReportFooter.tsx:77-78 — shouldHideComposer = !canPerformWriteAction || isBlockedFromChat
• ReportUtils.ts:10277-10288 — canUserPerformWriteAction checks archived status, creation errors, isAllowedToComment, anonymous user, and canWriteInReport
• ReportUtils.ts:2462-2468 — canWriteInReport checks report.permissions array for 'write'
• ReportUtils.ts:2473-2494 — isAllowedToComment checks writeCapability and policy admin role
• Report/index.ts:2086-2098 — createChildReport builds optimistic thread report without writeCapability

Ruled out:

• shouldShowComposeInput timing issue: This only affects mobile (isSmallScreenWidth=true); the bug is on desktop Chrome
• Archived/blocked/anonymous conditions: Issue doesn't indicate these apply

To confirm root cause: Inspect the Onyx data from the Slack thread — specifically the thread report's permissions array and writeCapability field.

---

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 - @thesahindia (External)

[melvin-bot]

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

[MadalitsoPhiri]

🚨 Edited by proposal-police: This proposal was edited at 2026-04-07 13:49:45 UTC.

Proposal

What is the root cause of that problem?

The composer visibility check in the footer uses the current report object directly:

• src/pages/inbox/report/ReportFooter.tsx#L77

For workspace chat threads, write access can be determined incorrectly when the thread report has incomplete or stale write metadata. In that case, canUserPerformWriteAction(report, ...) returns false, so the composer is hidden even though the parent workspace chat is writable.

Relevant logic:

• src/libs/ReportUtils.ts#L10277
• src/libs/ReportUtils.ts#L1348

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

1. Add a thread-aware write-check helper in ReportUtils.
2. If the current report is a chat thread, evaluate write access using the parent report as fallback/source of truth.
3. Keep all existing blockers unchanged (archived, anonymous, blocked, admins-only/system constraints).
4. Update ReportFooter to call the new helper.

Permalinks to update:

• src/libs/ReportUtils.ts#L10277
• src/pages/inbox/report/ReportFooter.tsx#L77
• tests/unit/ReportUtilsTest.ts#L8713

Diff 1: Add thread-aware helper in ReportUtils

--- a/src/libs/ReportUtils.ts
+++ b/src/libs/ReportUtils.ts
@@
 function canUserPerformWriteAction(report: OnyxEntry<Report>, isReportArchived: boolean | undefined) {
@@
 }
+
+function canUserPerformWriteActionForComposer(report: OnyxEntry<Report>, isReportArchived: boolean | undefined) {
+    if (!isChatThread(report)) {
+        return canUserPerformWriteAction(report, isReportArchived);
+    }
+
+    const parentReport = getParentReport(report);
+
+    // Prefer parent room permissions for workspace threads. Fallback to thread if parent is missing.
+    return canUserPerformWriteAction(parentReport ?? report, isReportArchived);
+}
@@
 export {
@@
-    canUserPerformWriteAction,
+    canUserPerformWriteAction,
+    canUserPerformWriteActionForComposer,
@@
 };

Diff 2: Use new helper in ReportFooter

--- a/src/pages/inbox/report/ReportFooter.tsx
+++ b/src/pages/inbox/report/ReportFooter.tsx
@@
 import {
-    canUserPerformWriteAction,
+    canUserPerformWriteActionForComposer,
@@
 } from '@libs/ReportUtils';
@@
-    const canPerformWriteAction = canUserPerformWriteAction(report, isReportArchived) ?? shouldShowComposerOptimistically;
+    const canPerformWriteAction = canUserPerformWriteActionForComposer(report, isReportArchived) ?? shouldShowComposerOptimistically;

What alternative solutions did you explore? (Optional)

1. Backend-only fix to always hydrate thread write metadata before rendering.The catch is frontend can still encounter temporary stale Onyx states.

2. Show composer optimistically while thread metadata is loading.Only issue it can briefly show composer in truly read-only threads.

[MassoudFSharifi]

Proposal

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

When a user opens a report thread from a workspace chat on desktop web, the bottom composer disappears even though the user can write in the parent workspace chat and should be able to comment in the thread.

---

What is the root cause of that problem?

src/pages/inbox/report/ReportFooter.tsx decides whether to render the composer with:

const canPerformWriteAction = canUserPerformWriteAction(report, isReportArchived) ?? shouldShowComposerOptimistically;
const shouldHideComposer = !canPerformWriteAction || isBlockedFromChat;

That report is the currently opened child report/thread from useRoute() + useOnyx(). For workspace chat threads and money request/report threads opened from a workspace chat, the child report can have incomplete or report-specific write metadata, especially a permissions array that does not include CONST.REPORT.PERMISSIONS.WRITE.

The actual failure sequence is:

1. The user opens a report thread from a workspace chat.
2. ReportFooter loads the child report from ONYXKEYS.COLLECTION.REPORT + reportIDFromRoute.
3. canUserPerformWriteAction() in src/libs/ReportUtils.ts calls isAllowedToComment(report) and canWriteInReport(report) on the child report.
4. canWriteInReport() returns false when the child report has a non-empty permissions array without write.
5. ReportFooter sets shouldHideComposer = true.
6. None of the fallback footers match, because the report is not archived, anonymous, blocked, system chat, or an admins-only room, so ReportFooter returns null.

The important mismatch is that comment permissions for these workspace child reports should be evaluated from the source workspace chat/parent report, while the current code evaluates only the child report’s stale/incomplete write metadata.

---

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

Update the shared write-action helper in src/libs/ReportUtils.ts so workspace chat threads and workspace money/invoice report threads resolve their effective write-permission source to the parent workspace chat report before evaluating isAllowedToComment() / canWriteInReport().

This is better than fixing only ReportFooter because the same canUserPerformWriteAction() result is also used by useIsReportReadyToDisplay, ReportActionsView, and ReportActionsList, so fixing the shared helper keeps composer visibility, editing state, and visible action filtering aligned.

Implementation

// File: src/libs/ReportUtils.ts

+function getReportForWriteAction(report: OnyxEntry<Report>): OnyxEntry<Report> {
+    if (!report?.parentReportID) {
+        return report;
+    }
+
+    const shouldUseParentReportWriteAccess =
+        isWorkspaceThread(report) || ((isMoneyRequestReport(report) || isInvoiceReport(report)) && report.parentReportID === report.chatReportID);
+
+    if (!shouldUseParentReportWriteAccess) {
+        return report;
+    }
+
+    return getReport(report.parentReportID, deprecatedAllReports) ?? report;
+}
+
 function canUserPerformWriteAction(report: OnyxEntry<Report>, isReportArchived: boolean | undefined) {
     const reportErrors = getCreationReportErrors(report);
+    const reportForWriteAction = getReportForWriteAction(report);
 
     // If the expense report is marked for deletion, let us prevent any further write action.
     if (isMoneyRequestReportPendingDeletion(report)) {
         return false;
     }
 
     return (
-        !isArchivedNonExpenseReport(report, isReportArchived) && isEmptyObject(reportErrors) && report && isAllowedToComment(report) && !deprecatedIsAnonymousUser && canWriteInReport(report)
+        !isArchivedNonExpenseReport(report, isReportArchived) &&
+        isEmptyObject(reportErrors) &&
+        report &&
+        isAllowedToComment(reportForWriteAction) &&
+        !deprecatedIsAnonymousUser &&
+        canWriteInReport(reportForWriteAction)
     );
 }

This keeps deletion/archive/error checks tied to the current child report, but uses the parent workspace chat as the source of write permissions only for child reports whose conversation permissions are inherited from that workspace chat. If the parent is unavailable, we fall back to the current report, preserving the existing behavior.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

A ReportFooter-only helper is weaker because other codepaths would still treat the same report as read-only.

A backend-only fix to always hydrate the child report with write would help, but the client can still briefly or permanently see stale child report metadata from Onyx, so the UI should derive effective write permissions from the correct parent report.

Showing the composer optimistically would be more fragile because it can briefly show the composer in genuinely read-only rooms.

[Abdullahtmk]

Proposal

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

When a user navigates to workspace chat, opens a report thread inside the chat then they cannot see the composer input field. Composure should be visible

Note: This issue could not be reproduced on staging by me either, however, potential problem is below

What is the root cause of that problem?

Composer suppression is being used as a side effect of errorFields (failed create/open/join state), but the UI does not surface that reason in the footer flow.

App/src/libs/ReportUtils.ts

Line 10220 in 8e1cdd8

function getCreationReportErrors(report: OnyxEntry<Report>): Errors | null | undefined {

Another issue could be the use of a narrow screen. So it would require a minor UI fix. This is because input composer is has by a global Onyx flag: SHOULD_SHOW_COMPOSE_INPUT. In ReportFooter, on small screens the composer only shows if this flag is true.

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

Have a dedicated footer for creation errors

Change this

App/src/pages/inbox/report/ReportFooter.tsx

Lines 89 to 97 in 8e1cdd8

	// Happy path — user can compose
	if (!shouldHideComposer && (shouldShowComposeInput || !isSmallScreenWidth)) {
	return (
	<View style={[chatFooterStyles, isComposerFullSize && styles.chatFooterFullCompose]}>
	<SwipeableView onSwipeDown={Keyboard.dismiss}>
	<ReportActionCompose reportID={report.reportID} />
	</SwipeableView>
	</View>
	);

To this

// ReportFooter.tsx — after computing canPerformWriteAction / before the "Happy path"

import { getCreationReportErrors } from '@libs/ReportUtils'; // if not exported, duplicate minimal check or export helper

const creationErrors = getCreationReportErrors(report);
const hasCreationErrors = !isEmptyObject(creationErrors);

if (hasCreationErrors) {
    return (
        <View style={[styles.chatFooter, styles.mt4, shouldUseNarrowLayout && styles.mb5]}>
            <Banner
                containerStyles={[styles.chatFooterBanner]}
                text={translate('reportActionCompose.chatFailedToLoad')}
                shouldShowIcon
            />
            {/* Optional: <Button onPress={() => openReportAgain(report.reportID)} /> */}
        </View>
    );
}

Besides this, to solve keeping in mind the SHOULD_SHOW_COMPOSE_INPUT Onyx Key, add a useEffect that resets on ID change.

In file src/pages/inbox/report/ReportActionCompose/ReportActionCompose.tsx, add the following

useEffect(() => {
    setDidHideComposerInput(!shouldShowComposeInput);
}, [shouldShowComposeInput]);

What alternative solutions did you explore? (Optional)

N/A

[twilight2294]

Proposal

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

When a user opens a workspace chat or a thread inside it on desktop web, the composer input disappears and no explanation is shown.

What is the root cause of that problem?

openReport() in Report/index only clears errorFields.notFound on success — it never clears addWorkspaceRoom, createChat, createReport, or createChatThread. If a previous report creation attempt failed (network timeout, transient error), those error fields persist in Onyx permanently. When the user later re-opens the report (which now exists server-side), openReport succeeds but the stale error remains.

canUserPerformWriteAction() in ReportUtils calls getCreationReportErrors() at L10220-10224, finds the stale error, and returns false. ReportFooter then hides the composer, falls through all fallback checks, and hits return null at L175 — no composer, no banner.

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

Clear all creation error fields in openReport()'s base success data in Report/index. If OpenReport succeeds, the report exists and any creation errors are stale:

// Report/index.ts, base successData ~L1329-1332
errorFields: {
    notFound: null,
    addWorkspaceRoom: null,
    createChat: null,
    createReport: null,
    createChatThread: null,
},

This is safe because a successful OpenReport response proves the report exists server-side, making any prior creation failure irrelevant.

What alternative solutions did you explore? (Optional)

All existing proposals focus on write permission evaluation — inheriting permissions from parent reports (MadalitsoPhiri, MassoudFSharifi), or adding new footer components (Abdullahtmk). None address why stale creation errors persist after a successful re-open. Even with correct permission inheritance, a stale errorFields.addWorkspaceRoom will still cause canUserPerformWriteAction() to return false before permission checks are ever reached (the isEmptyObject(reportErrors) check at L10286 short-circuits first). This fix addresses the actual data staleness rather than working around it.

[mountiny]

@adhorodyski Can you look at the proposals?