Reports- preview Disabled submit button not displayed to prevent self-approval wp

[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: 9.4.74-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: #97946
Email or phone of affected tester (no customers): applausetester+dk45@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 Home/Chrome
App Component: Money Requests

Action Performed:

1. Open https://staging.new.expensify.com/
2. Go to Workspace settings
3. Enable 'Prevent self-approvals'
4. Go to workspace chat
5. Create an expense report

Expected Result:

verify the preview Submit button is disabled

Actual Result:

The disabled submit button is not displayed in preview report

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7254708_1788923759675.bandicam_2026-09-09_10-12-24-533.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Nathan Lemma
Bug ID: 7254708

Issue Owner

Current Issue Owner: @thelullabyy

[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/382126e64fc48b24fc9274370557986caa27115a9184ed1d37d07244fd730702

[MelvinBot]

Proposal

What is the root cause of that problem?

The report preview never renders a Submit button in this state, so there is nothing to disable. The two Submit surfaces resolve their action differently:

• Report header — ReportPrimaryActionUtils.ts:155 blocks the SUBMIT action for prevented self-approval only when the current user is not the submitter (&& !isReportSubmitter). The submitter still gets SUBMIT, and SubmitPrimaryAction then renders it disabled.
• Report preview — canSubmit in ReportPreviewActionUtils.ts:76-78 has the same check without the !isReportSubmitter qualifier, so it returns false for the submitter. getReportPreviewAction therefore never returns SUBMIT, and ReportPreviewActionButton falls through to null and renders only the View button.

This makes the gate added by #97946 (SubmitActionButton.tsx:124-133, isDisabled at L195) unreachable for the prevent-self-approval branch — the component is never mounted. Its unit test mocks shouldBlockSubmitDueToPreventSelfApproval, so it passes while the real app skips the component, which is why this only surfaced in QA.

Why the underlying "block submission" condition really is true here

shouldBlockSubmitDueToPreventSelfApproval (ReportUtils.ts:10102-10111) compares getNextApproverAccountID(report) against report.ownerAccountID. With a self-approval workspace, getApprovalChain pops the owner from the chain when preventSelfApproval is set, leaving it empty, so getNextApproverAccountID falls back to getSubmitToAccountID = the owner. Both gates agree the submission is blocked; they only disagree on whether to hide or disable the button.

Verification note: I could not reproduce the blocked state at runtime — "Prevent self-approvals" is behind the Control-plan upgrade paywall on a test workspace, and the test account is on Collect. With the setting off I confirmed the control case: preview card and report header both show an enabled Submit. The root cause above rests on code evidence, not a live repro.

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

Align canSubmit with the header's isSubmitAction: in ReportPreviewActionUtils.ts:76, add the !isSubmitter qualifier (the local isSubmitter is already computed at L57) so the early return only applies to non-submitters.

The preview action then resolves to SUBMIT for the submitter, SubmitActionButton mounts, and the isDisabled gate from #97946 renders it disabled — matching the header and the documented expected result. No change to SubmitActionButton is needed.

Add a unit test for canSubmit/getReportPreviewAction covering preventSelfApproval + submitter → SUBMIT (there is currently no test file for ReportPreviewActionUtils), so the preview and header gates cannot drift apart again.

What alternative solutions did you explore? (Optional)

Treat the preview's current hide-the-button behavior as intended and correct the QA/test plan instead. That still leaves the header showing a disabled Submit while the preview shows no Submit for the same report, so a product decision is needed either way. Hiding-vs-disabling parity should be settled before the fix lands.

Related issues

• [Due for payment 2026-09-16] [$250] Submit button remains enabled for violating reports and shows generic error when strict workflow rules are enforced #92367 — the parent issue fix: disable report preview Submit button when strict workflow rules block submission #97946 fixed; step 7 of that PR's test plan is the step this QA failure comes from.

---

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

---

view run · no recording available

[melvin-bot]

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

[melvin-bot]

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