Expense - "Allow location access" modal shows up when creating manual expense with 0 amount

[mitarachim]

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: 9.3.37-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: #83354
Email or phone of affected tester (no customers): soidjsodijsodjnsoidjs@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Location access is not allowed.

1. Go to staging.new.expensify.com
2. Create a new account.
3. Create a workspace.
4. Go to workspace chat.
5. Click + > Create expense > Manual.
6. Enter 0 > Next.
7. On confirm page, enter Merchant.
8. Click Create expense.

Expected Result:

"Allow location access" modal will not show up because the expense is a manual expense.

Actual Result:

"Allow location access" modal shows up when creating manual expense with 0 amount.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7101662_1773359553305.4.mp4

View all open jobs on GitHub

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #83354

[melvin-bot]

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #83354 - "Pass locationPermissionGranted=true when permission was already grant..." by @MobileMage (High confidence)
Related Issues: #81184 (original issue that PR 83354 was fixing)

Recommendation: REVERT

PR #83354 should be reverted. While it successfully fixed the original issue (scanned receipts not collecting GPS for currency detection), it introduced a regression where manual expenses with 0 amount now incorrectly trigger the location permission modal.

Labels: Keeping DeployBlockerCash - this is an App bug that requires reverting an App PR. Removing DeployBlocker as this is not a backend issue.

Detailed Analysis

Evidence

PR #83354 modified src/pages/iou/request/step/IOURequestStepScan/useReceiptScan.ts to pass locationPermissionGranted=true when:

1. shouldSkipConfirmation is true
2. gpsRequired is true (amount === 0)
3. Permission was already granted

The problem is in the gpsRequired condition:

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

This condition checks for 0 amount expenses but does NOT distinguish between:

• Scanned receipts (which need GPS to determine currency from location)
• Manual expenses (which do not need GPS)

Verification

From the issue reproduction steps:

1. Create a manual expense (not scanned)
2. Enter amount 0
3. The location permission modal incorrectly appears

The fix applies to lines 234-246 in processReceipts() and lines 254-263 in submitReceipts() in useReceiptScan.ts, where the GPS requirement logic does not check the expense type.

Root Cause

The PR correctly identified that scanned receipts with 0 amount need GPS coordinates for currency detection when permission is already granted. However, the implementation applies this logic to ALL expenses with 0 amount, including manual expenses that should never trigger location permission flows.

The same issue exists in IOURequestStepConfirmation.tsx line 285:

const gpsRequired = transaction?.amount === 0 && iouType !== CONST.IOU.TYPE.SPLIT && Object.values(receiptFiles).length && !isTestTransaction;

This condition should additionally check if the expense is a scanned receipt (e.g., using isScanRequest(transaction)) before requiring GPS.