[$250] QAB - Can create expense through the QAB of the Expired Workspace

[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.3.32-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: #83736
Email or phone of affected tester (no customers): luongquocvu92+010125@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: Money Requests

Action Performed:

Preconditions: User has an Expired Workspace and has created an expense before, so it has a QAB point to the expired WS

1. Open the ND app
2. Click on the FAB -> QAB -> Track distance
3. Enter any amount and create the expense

Expected Result:

RHP paywall appears

Actual Result:

QAB can create a new expense to the Expired Workspace

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Pujan92

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043664107473821341
• Upwork Job ID: 2043664107473821341
• Last Price Increase: 2026-04-13

[MelvinBot]

Proposal

What is the root cause of that problem?

In QuickActionNavigation.ts:65-74, navigateToQuickAction() passes shouldRestrictAction = false for TRACK_MANUAL, TRACK_SCAN, TRACK_PER_DIEM, TRACK_DISTANCE, and REQUEST_DISTANCE.

The selectOption callback in QuickActionMenuItem.tsx:110-120 only checks shouldRestrictUserBillableActions() when shouldRestrictAction is true. So for these actions, the paywall check is entirely skipped and the user navigates straight to expense creation on the expired workspace.

For comparison, REQUEST_MANUAL, REQUEST_SCAN, PER_DIEM, SPLIT_*, and REQUEST_TIME all correctly pass true.

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

Change shouldRestrictAction from false to true for the affected actions in QuickActionNavigation.ts:

• TRACK_MANUAL / TRACK_SCAN / TRACK_PER_DIEM (line 68)
• REQUEST_DISTANCE (line 71)
• TRACK_DISTANCE (line 74)

This makes them consistent with REQUEST_MANUAL, REQUEST_SCAN, and other actions that already pass true.

What alternative solutions did you explore? (Optional)

Adding shouldRestrictUserBillableActions() checks directly in the distance step pages (IOURequestStepDistance.tsx, IOURequestStepDistanceManual.tsx) as defense-in-depth. However, the simplest and most consistent fix is at the navigateToQuickAction call site, matching the pattern already used by other action types.

---

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