[CFI] [$250] Allow distance mi/km to be edited when created via map

[m-natarajan]

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:
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @AHowell14
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

Description:

When clicking into the Distance field of a distance expense, the user should see:
A screen displaying:
A text input containing the calculated number of miles
An option row underneath labeled:
“Edit the start/stop locations >”
Clicking the “Edit the start/stop locations >” option should open the waypoints editor screen.

Steps (Proposed Flow)

1. Create a distance expense from map
2. Open the expense
3. Click the Distance field on the expense

Expected Result:

• Tapping the Distance field on the expense opens a screen which has the option to edit the waypoint locations or the mi/km that was calculated.

Actual Result:

You can only edit the waypoints. Customers are complaining about it because it prevents them from being able to deduct mi/km for reasons such as commuter mileage deductions.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @youssef-lr

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022027557162450788012
• Upwork Job ID: 2027557162450788012
• Last Price Increase: 2026-03-07

EXFY-20168

[melvin-bot]

Current assignee @trjExpensify is eligible for the NewFeature assigner, not assigning anyone new.

[melvin-bot]

Current assignee @trjExpensify is eligible for the Bug assigner, not assigning anyone new.

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @dannymcclain (NewFeature)

[MelvinBot]

Proposal

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

When a user clicks the Distance field on an existing distance expense, they are taken directly to the raw editing screen (e.g., a draggable waypoint list with a map for map-based distances, or a bare number input for manual distances). There is no intermediate screen that shows the calculated miles in a text input together with an "Edit the start/stop locations" option row that opens the waypoints editor.

What is the root cause of that problem?

The current distance editing flow in MoneyRequestView.tsx:605-638 branches directly to one of three dedicated screens based on the distance sub-type:

1. Map-based → IOURequestStepDistance.tsx — shows a draggable waypoint list + Mapbox map + "Add stop" button
2. Manual → IOURequestStepDistanceManual.tsx — shows a NumberWithSymbolForm (e.g., "5.23 mi")
3. Odometer → IOURequestStepDistanceOdometer.tsx — shows start/end reading inputs

There is no intermediate screen that combines a text input displaying the calculated distance and a navigation row to edit the start/stop locations. These two concepts (viewing/editing the distance number vs. editing waypoint locations) are implemented as entirely separate, disconnected flows.

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

Modify the map-based distance edit flow so that when a user taps the Distance field on a map-based distance expense, they see a new intermediate screen with:

1. A text input showing the calculated distance (e.g., "12.50") with the unit suffix ("mi" or "km") — similar to how IOURequestStepDistanceManual.tsx uses NumberWithSymbolForm
2. An option row labeled "Edit the start/stop locations >" — a MenuItemWithTopDescription that navigates to the existing IOURequestStepDistance screen (the waypoints editor with the draggable list and map)

Files to modify:

• MoneyRequestView.tsx (~line 630): Change the default (map-based) distance navigation to point to the new intermediate screen instead of directly to ROUTES.MONEY_REQUEST_STEP_DISTANCE
• New route in ROUTES.ts: Add a route like MONEY_REQUEST_STEP_DISTANCE_OVERVIEW (e.g., :action/:iouType/distance-overview/:transactionID/:reportID/:reportActionID?)
• New screen (e.g., IOURequestStepDistanceOverview.tsx): Create a new step screen that:
  • Reads the transaction's distance via getDistanceInMeters() and converts it to the display unit
  • Renders a NumberWithSymbolForm (reusing the pattern from IOURequestStepDistanceManual.tsx) pre-filled with the calculated distance
  • Renders a MenuItemWithTopDescription with shouldShowRightIcon that navigates to ROUTES.MONEY_REQUEST_STEP_DISTANCE (the existing waypoints editor)
  • Has a "Save" button that calls updateMoneyRequestDistance if the user changes the distance number directly
• Navigation registration: Register the new screen in ModalStackNavigators/index.tsx, SCREENS.ts, Navigation/types.ts, and the linking config

Key data model points:

• Distance is stored in transaction.comment.customUnit.quantity (in mi/km) after save, and transaction.routes.route0.distance (meters) during creation
• getDistanceInMeters() from TransactionUtils/getDistanceInMeters.ts handles both cases
• The waypoints live in transaction.comment.waypoints as a WaypointCollection

What alternative solutions did you explore? (Optional)

1. Modify IOURequestStepDistance.tsx directly to add a distance text input above the waypoint list — rejected because it would make the existing map-based editing screen more complex and tightly coupled, and wouldn't match the described UX of a clean intermediate screen
2. Modify IOURequestStepDistanceManual.tsx to add an "Edit locations" row for map-based expenses — rejected because manual distance expenses fundamentally don't have waypoints, so overloading this screen for a different sub-type would be confusing

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.