[Due for payment 2026-03-19] Scan - New user scan expense via scan icon, "Allow location access" modal isn't appeared

[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.36-0
Reproducible in staging?: Yes
Reproducible in production?: No
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-8439/folder/13176933/41237726/1244463273
Email or phone of affected tester (no customers): lekima20+64403@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Win 11/Chrome
App Component: Money Requests

Action Performed:

Precondition: Login with new account, create a workspace

1. Open https://staging.new.expensify.com
2. At Inbox tab click on the scan icon
3. Upload file and complete create expense flow
4. Click on FAB > Create Expense > Scan > complete create expense flow

Expected Result:

In the first time creating a scan expense, "Allow location access" modal should appear

Actual Result:

In the first time creating a scan expense via the scan icon, "Allow location access" modal isn't appeared. This modal only appears when create scan expense from FAB or workspace chat

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @Beamanator (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #84552 - "[No QA] Re-add the "Sentry logs for Scan shortcut"" by @cristipaval (High confidence)
Related Issues: None

Recommendation: REVERT

PR #84552 introduced the isFromFloatingActionButton flag to track when users start the scan flow from the green receipt button (scan icon). This flag causes the scan flow to bypass the "from report" navigation path where location permission is properly requested, and instead uses the default policy flow that navigates directly to confirmation without showing the location permission modal.

Labels: No label changes made (issue is only reproducible on staging, not production, and was reported by internal tester)

Detailed Analysis

Evidence

PR #84552 added telemetry tracking for the scan shortcut by introducing isFromFloatingActionButton flag on transactions. This flag is set to true when users click:

• The scan icon in the Inbox tab
• The green receipt FAB (floating action button)

The issue states: "In the first time creating a scan expense via the scan icon, 'Allow location access' modal isn't appeared. This modal only appears when create scan expense from FAB or workspace chat"

This perfectly matches the behavior change introduced by #84552.

Verification

Looking at the affected code in src/libs/actions/IOU/MoneyRequest.ts at line 368:

if (!initialTransaction?.isFromGlobalCreate && !initialTransaction?.isFromFloatingActionButton && !isArchivedExpenseReport && iouType !== CONST.IOU.TYPE.CREATE) {
    // "from report" path - handles location permission properly
    const participants = getMoneyRequestParticipantOptions(...);
    
    if (shouldSkipConfirmation) {
        // Location permission is requested here when gpsRequired
        if (locationPermissionGranted) {
            getCurrentPosition(...);
        }
        createTransaction(...);
    }
}

When isFromFloatingActionButton is true, this entire block is skipped, and the flow jumps to the default policy flow (line 520+) which navigates directly to the confirmation page without checking for location permission.

The location permission modal in IOURequestStepScan (lines 718-728) only appears when startLocationPermissionFlow is true, but this state is only set in specific conditions within useReceiptScan.ts that are not triggered when using the scan icon path.

Root Cause

The PR added isFromFloatingActionButton to differentiate scan shortcut flows for telemetry purposes. However, it reused the same conditional logic that was meant for isFromGlobalCreate, inadvertently changing the navigation flow. The scan icon flow now bypasses the "from report" path where location permission is properly handled, causing the modal to not appear for first-time scan users clicking the scan icon.

The files modified by PR #84552:

• src/libs/actions/IOU/MoneyRequest.ts - Added check for isFromFloatingActionButton
• src/libs/actions/IOU/index.ts - Sets the flag on transactions
• src/pages/inbox/sidebar/FloatingActionButtonAndPopover.tsx - Starts telemetry span
• src/components/FloatingCameraButton/BaseFloatingCameraButton.tsx - Starts telemetry span
• src/pages/iou/request/step/IOURequestStepScan/useReceiptScan.ts - Passes flag through
• src/pages/iou/request/step/IOURequestStepScan/useScanShortcutSpan.ts - New hook for telemetry

[MelvinBot]

Proposal

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

When a new user creates a scan expense via the scan icon on the Inbox tab, the "Allow location access" modal does not appear. However, the modal correctly appears when creating a scan expense through FAB > Create Expense > Scan.

What is the root cause of that problem?

The scan icon path (startQuickScan / FloatingReceiptButton) calls startMoneyRequest with requestType = SCAN, which creates a minimal transaction draft that does not include amount: 0:

// IOU/index.ts:1382-1388
Onyx.set(`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${CONST.IOU.OPTIMISTIC_TRANSACTION_ID}`, {
    isFromFloatingActionButton,
    transactionID: CONST.IOU.OPTIMISTIC_TRANSACTION_ID,
    ...(requestType && {iouRequestType: requestType}),
});

This draft has no amount field, so amount is undefined.

Normally, initMoneyRequest (which sets amount: 0) gets called when the user switches tabs in IOURequestStartPage. But the scan icon pre-sets the tab to SCAN via Tab.setSelectedTab before navigating. When OnyxTabNavigator mounts, it sees the selected tab already matches the current tab (selectedTab === newSelectedTab at OnyxTabNavigator.tsx:186-188), so it skips calling onTabSelected → resetIOUTypeIfChanged → initMoneyRequest. The useFocusEffect in IOURequestStartPage also skips because transaction.reportID === reportID.

As a result, initMoneyRequest is never called, and amount stays undefined.

Both the scan step and confirmation page check:

const gpsRequired = initialTransaction?.amount === 0 && iouType !== CONST.IOU.TYPE.SPLIT ...

Since undefined === 0 is false, gpsRequired is false, and the LocationPermissionModal is never triggered.

In contrast, the FAB > Create Expense flow calls startMoneyRequest with requestType = undefined. When the user manually switches to the Scan tab, initMoneyRequest IS called and creates a full transaction draft with amount: 0, enabling the location permission flow.

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

Add amount: 0 to the transaction draft created in startMoneyRequest when isFromFloatingActionButton is true (IOU/index.ts:1383-1387):

Onyx.set(`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${CONST.IOU.OPTIMISTIC_TRANSACTION_ID}`, {
    amount: 0,
    isFromFloatingActionButton,
    transactionID: CONST.IOU.OPTIMISTIC_TRANSACTION_ID,
    ...(requestType && {iouRequestType: requestType}),
});

This ensures the transaction draft always has amount: 0 for scan flows initiated from the floating buttons, matching the behavior of initMoneyRequest and allowing gpsRequired to evaluate correctly.

What alternative solutions did you explore? (Optional)

1. Changing gpsRequired to treat undefined the same as 0 (e.g., !initialTransaction?.amount): This would be a broader change that could have unintended side effects on other flows where amount being undefined has a different meaning.

2. Calling initMoneyRequest explicitly in the scan icon path: This would work but is more invasive, as initMoneyRequest does a lot more than just setting amount: 0 (it creates a full transaction with comments, currency, merchant, etc.), and the scan icon path intentionally creates a lightweight draft.

3. Modifying OnyxTabNavigator to call onTabSelected even when the tab hasn't changed: This would affect all tab navigators in the app and could cause unwanted side effects.

---

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.