[Exploratory] SelfDM Expense - Error after mention user create report from the Track expense in SelfDM

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.51-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96352
Email or phone of affected tester (no customers): leungbratt6adasda@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: Chat Report View

Action Performed:

Preconditions: User has a SelfDM and a Workspace, 2 users on 2 devices

1. Open the New Dot app on user A
2. Navigate to the SelfDM
3. Create a manual track expense
4. Mention another user B -> Select Invite to chat only
5. As mentioned user B, go to the track expense of user A
6. Click on any section: Description, Category, select Report -> Create report

Expected Result:

The section on the track expense should be a read-only section for the user B

Actual Result:

User B can interact with the track expense of user A, and an error appears when create report to the Workspace of user A "Unexpected error creating this chat. Please try again later."

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7229358_1786254905455.mention_user_inselfDM.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7229358

Issue Owner

Current Issue Owner: @chuckdries

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/b979d676bf84cfb83fbe3166cdeea782cb9f3339525b68b528bd67a55d51d144

[MelvinBot]

Proposal

What is the root cause of that problem?

MoneyRequestView hands the viewer's own workspace to the permission check, and canEditMoneyRequest short-circuits to true for anyone whose role on that workspace is admin. User B is admin of B's own workspace, so B gets edit rights on User A's expense.

Every self-DM track expense is stored as unreported, and for unreported expenses MoneyRequestView.tsx:255-262 replaces the expense's policy with policyForMovingExpenses — which resolves to the current user's active policy (usePolicyForMovingExpenses.ts:129-135). That value is meant to answer "which workspace would I move this to", but it is passed straight into a permission helper at MoneyRequestView.tsx:403-405.

Inside ReportUtils.ts:5200-5211, isAdmin is computed from that policy with no isExpenseReport guard, and if (isAdmin || isManager) return true; skips the owner check at ReportUtils.ts:5237. Description, Category, Tag, Billable and Report all funnel through this one gate, because canEditFieldOfMoneyRequest delegates to it at ReportUtils.ts:5450-5452.

The error message is a downstream symptom, not a second bug: because the Report row is interactive, B reaches "Create report", which sends CreateAppReport with ownerEmail = A (DynamicIOURequestStepReport.tsx:87-90) and policyID = B's own workspace (Report/index.ts:4664-4678). A is not a member of B's workspace, the backend rejects it, and failureData paints the generic report.genericCreateReportFailureMessage string (Report/index.ts:4561-4571).

Supporting evidence and how the checks were traced

Why the repro requires "User has a SelfDM and a Workspace". If B had no group workspace, policyForMovingExpenses would be undefined, reportPolicy would fall back to the self-DM's (nonexistent) policy, isAdmin would be false, and canEditMoneyRequest would correctly fall through to isRequestor === false → read-only. The workspace precondition in the bug report is exactly what makes it reproduce.

The same helper already gets this right elsewhere. canCurrentUserEditExpense at ReportUtils.ts:5389-5390 qualifies both roles with isExpenseReport(moneyRequestReport):

const isAdmin = isExpenseReport(moneyRequestReport) && reportPolicy?.role === CONST.POLICY.ROLE.ADMIN;
const isManager = isExpenseReport(moneyRequestReport) && deprecatedCurrentUserAccountID === moneyRequestReport?.managerID;

canEditMoneyRequest omits that qualifier. The line also already carries a TODO comment noting the policy resolution is temporary.

Independent corroboration. useShowNotFoundPageInIOUStep.ts:30 calls the same canEditMoneyRequest but reads the policy from report?.policyID instead of substituting the viewer's workspace — and with that argument it returns false. The identical helper gives opposite answers purely based on which policy object the caller passes, which pins the substitution as the trigger.

A related comment already flags this hazard. MoneyRequestView.tsx:270-271 says: "Use the report's real policy, not policy above (swapped to an unrelated workspace for unreported expenses)" — a prior fix for a different bug caused by the same substitution.

Second, weaker gate. Even if the first gate were fixed, the "Create report" row has its own defeated owner check at IOURequestEditReportCommon.tsx:121-125 — isOwner is forced true by || isSelectedReportUnreported, so "unreported" is treated as "mine".

What I did not verify. The exact backend rejection reason for CreateAppReport is inferred from the payload mismatch; the App client has no visibility into the response and paints the generic message regardless of jsonCode. Reproducing the flow end to end needs two accounts on two devices, so this analysis is from code only.

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

1. In canEditMoneyRequest (ReportUtils.ts:5201-5202), qualify isAdmin and isManager with isExpenseReport(moneyRequestReport), matching canCurrentUserEditExpense. A self-DM is not an expense report, so B falls through to the owner check and every field renders read-only. A editing their own track expense is unaffected — isRequestor is true for A at line 5237, and a self-DM is never approved, settled, or closed.

2. Drop the || isSelectedReportUnreported clause from isOwner in IOURequestEditReportCommon.tsx:121-125 so the "Create report" row is hidden for a non-owner even if it is reached another way.

3. Add a unit test to the existing describe('canEditMoneyRequest') block in tests/unit/ReportUtilsTest.ts: a track expense on another user's self-DM, viewed by a non-actor who is admin of an unrelated policy, must return false.

What alternative solutions did you explore? (Optional)

• Stop passing policyForMovingExpenses into permission helpers in MoneyRequestView and pass expensePolicy instead. This attacks the substitution at its source and is arguably more correct, but it touches every canEditFieldOfMoneyRequest call in the component and risks regressing unreported-expense flows that intentionally rely on the default workspace. Option 1 is the smaller, better-precedented change.
• Have the backend return permissions: ['read'] for users invited via "Invite to chat only", which would make canUserPerformWriteAction false and disable the whole view. This is the cleanest long-term model but is a backend change outside this repo, and the client gate should be correct regardless.
• Only suppress the error message. Rejected — it hides the symptom while leaving a non-owner able to edit someone else's expense.

Related issues

No likely duplicate found. #99315 also involves self-DM expenses but is about distance rate display, not permissions.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/98099) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run · view recording

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[melvin-bot]

@suneox this issue is now 4 weeks old, please consider:

• Finding a contributor to fix the bug
• Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[suneox]

I'll take a look at this one today

[suneox]

@MelvinBot Let's analyze the regression risk of alternative option 1 (stop passing policyForMovingExpenses in this case). Are there any specific conditions we can apply to prevent regression?