Home address is required modal shows when employee create distance map in self DM

[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.76-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: #100478
Email or phone of affected tester (no customers): gocemate+buzz19s77@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: windows 10/chrome
App Component: Other

Action Performed:

Precondition:
1.As an admin, add a home address to the workspace, enable Distance rates, and under Distance rates → Settings → Exclude commutes select "Calculate by home and office".
2. Invite a member who does not have a home address set, and have them make this workspace their default workspace.

Steps:

1. Member goes to self DM.
2. Start creating a map distance expense> Add start and stop points> Click Next

Expected Result:

"Home address is required" should not appear

Actual Result:

"Home address is required" modal appears

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7256937_1789123296787.Recording__1593.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7256937

Issue Owner

Current Issue Owner: @cretadn22

[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/015bf973a106266d51fbf1daee7c0bfb7e713c8bc72519940a45e99759670bff

[MelvinBot]

Proposal

What is the root cause of that problem?

The Map distance tab checks the commuter-exclusion rule against the member's default workspace instead of the expense's destination. In a self DM there is no destination workspace yet, so the check should not run at all.

On Next, IOURequestStepDistanceMap.tsx:289-291 runs the guard before navigating. The policy it feeds the guard comes from IOURequestStepDistanceMap.tsx:79-80, which uses usePolicyForTransaction. For a self-DM track expense that hook deliberately returns the active (default) workspace — usePolicyForTransaction.ts:56-60. That workspace has commuterExclusions.method = homeAndOffice and the member has no home address, so useBlockDistanceRequest.ts:99-101 returns homeAddressRequired.

The Manual and Odometer tabs already scope this correctly to the destination; the Map tab was missed. Compare DynamicIOURequestStepDistanceManual.tsx:159-164 and IOURequestStepDistanceOdometer.tsx:174-179, which pass report?.policyID ?? (shouldAutoReportToDefaultWorkspace ? defaultExpensePolicy?.id : undefined).

That personal expenses are exempt is already the documented product rule for this same feature — see the comment at DistanceRequestStartPage.tsx:72-84: "never hide for a Self-DM target (personal expenses are exempt)".

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

1. In IOURequestStepDistanceMap.tsx:80, stop passing the usePolicyForTransaction policy to useBlockDistanceRequest. Use the same destination-scoped expression the Manual and Odometer tabs use, so a self-DM/track expense resolves to undefined (no block) while a FAB flow that will auto-report into the workspace still blocks. personalPolicy and defaultExpensePolicy are already in scope on that screen.

2. Apply the same scoping at useExpenseSubmission.ts:345-350, which has the identical unscoped policyID: policy?.id. Without this the member is simply blocked one screen later on Create expense. MoneyRequestConfirmationList.tsx:233-237 already shows the right pattern (isPolicyExpenseChat ? policy?.id : undefined), and isPolicyExpenseChat is already a param of useExpenseSubmission.

3. Add a test for the Map tab's guard — there is currently none. tests/unit/hooks/useBlockDistanceRequest.test.ts covers the hook, but no test covers this call site.

What alternative solutions did you explore? (Optional)

Alternatives and evidence

Leaner Map-tab-only fix: policyID: isSelfDM(report) ? undefined : policy?.id. This fixes the reported repro with one line and matches the wording in DistanceRequestStartPage, but it leaves a gap where a global-FAB CREATE flow that auto-reports into a restricted workspace is never blocked. The sibling-tab formula handles both, so I'd prefer it.

Ruled out: PR #100478 (linked in the bug report). It added isDistanceRequest to the guard in DynamicIOURequestStepParticipants.tsx, but:

• That call site passes no policyID and is only invoked on a tapped participant row (ParticipantSearchResults.tsx:490-494). A self-DM row carries no policyID, so it cannot produce this modal.
• The self-DM track flow never reaches the participants step at all — handleMoneyRequestStepDistanceNavigation.ts:257 routes TRACK straight to confirmation.
• The offending IOURequestStepDistanceMap.tsx:80 line pre-dates that PR, which matches the report's "Reproducible in production: Yes" — Fix map/GPS distance expenses skipping home address check on move #100478 merged 2026-09-10 and would not yet be in production.
• The tests Fix map/GPS distance expenses skipping home address check on move #100478 added assert only that tapping a workspace row is blocked. They don't lock in the self-DM behavior, so scoping the Map/confirmation guards won't break them.

Possibly related: #99725 (Profile background page is not shown after clicking Add Home Address) — same homeAddressRequired modal, different defect in what the modal's action does.

Not verified in a browser. Browser control was unavailable for this run, so this is static analysis only: every line above was read at 45b319e, but I could not drive the repro live. The code path is deterministic client-side logic with no server round trip, so logs would not add anything either.

---

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

---

view run

[melvin-bot]

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

[melvin-bot]

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

[ceosss]

Proposal

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

A member whose default workspace has "Exclude commutes: calculate by home and office" enabled, and who has no home address saved, creates a Map distance expense in their own self DM and taps Next. A "Home address is required" modal appears and blocks them. The expense is personal: it is not going to that workspace, so the workspace's commuter rule should not gate it.

What is the root cause of that problem?

IOURequestStepDistanceMap.tsx:79-80 feeds the compliance guard, and :289-290 runs it on Next. It hands the guard the same policy object the screen uses for pricing:

const {policy} = usePolicyForTransaction({transaction, reportPolicyID: report?.policyID, action, iouType});
const blockDistanceRequestIfNeeded = useBlockDistanceRequest({policyID: policy?.id, isDistanceRequest: true});

Those are two different questions being answered by one value.

For a self-DM track expense, usePolicyForTransaction.ts:57-60 resolves policyForMovingExpenses, not the report's policy. That is correct for what the screen needs it for: it is the workspace the expense would move to, so it supplies the mileage rate, currency and tax code, which is why useDistanceRequestData and handleMoneyRequestStepDistanceNavigation read it. It is the wrong input for a compliance gate, because at this moment no workspace is the destination. The transaction is headed for the self DM as an unreported personal expense.

So the root cause is not that usePolicyForTransaction misbehaves. It is that the distance guard is scoped to the pricing policy when it must be scoped to the destination. useBlockDistanceRequest.ts:90 then finds commuterExclusionMethod === homeAndOffice on a workspace that is not the destination, sees no home address, and returns homeAddressRequired.

The same mis-scoping is present at three further call sites, all passing the bare policy?.id: IOURequestStepDistanceMap.tsx:80, DynamicIOURequestStepDistance.tsx:369, IOURequestStepConfirmation.tsx:258 and useExpenseSubmission.ts:343. Two sibling screens avoid the bug only because they hand-inline a destination expression instead (DynamicIOURequestStepDistanceManual.tsx:159-164, IOURequestStepDistanceOdometer.tsx:174-179), and MoneyRequestConfirmationList.tsx:233-237 avoids it with a third, differently-written expression (isPolicyExpenseChat ? policy?.id : undefined). Three spellings of one rule, and the two screens that never got a spelling are the two that are broken.

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

Unlike the approach of copying the Manual/Odometer expression into the Map tab, I would resolve the destination policy once and feed every distance guard from it, because a per-tab copy leaves the confirmation step broken and adds a fourth spelling of the same rule.

1. Derive the guard's policy ID from the destination rather than from the pricing policy. The destination is already decided by existing logic: a report-scoped flow uses report?.policyID; a global FAB flow uses the default workspace only when it will actually auto-report there, which is the condition handleMoneyRequestStepDistanceNavigation.ts:476-481 already uses to choose between the policy expense chat and the self DM; everything else, self DM included, has no destination workspace and must yield undefined. I would put that resolution in one small helper (or extend useBlockDistanceRequest to accept the destination inputs and compute it internally) so there is a single definition.

2. Point the four unscoped call sites at it: IOURequestStepDistanceMap.tsx:80, DynamicIOURequestStepDistance.tsx:369, IOURequestStepConfirmation.tsx:258 and useExpenseSubmission.ts:343. Without the last two the member is not fixed, only moved: the Map tab lets them through and useExpenseSubmission.ts:975 blocks them one screen later on Create expense.

3. Optional, and separable from steps 1 and 2: replace the three hand-inlined expressions in DynamicIOURequestStepDistanceManual.tsx, IOURequestStepDistanceOdometer.tsx and MoneyRequestConfirmationList.tsx with the same helper. They are correct today, so this fixes nothing on its own and I would drop it if you prefer the smaller diff. I raise it only because they are why the rule drifted into four spellings, and leaving them means the next distance screen copies whichever one it finds first.

Suppressing the check in the self DM loses no enforcement, and I want to be explicit about why, since that is the risk a reviewer should weigh. Every path that later moves a personal expense into a workspace already re-runs the guard with the destination's own policy ID, passed explicitly: IOURequestEditReportCommon.tsx:265 (item.policyID) and :305 (policyForMovingExpenses?.id), DynamicReportChangeWorkspacePage.tsx:138 (policyID), useParticipantSubmission.ts:241 and IOURequestStepConfirmation.tsx:421 (selectedPolicyID). The home-address requirement is therefore enforced at the point the workspace actually becomes the destination, which is where it belongs. Creating the personal expense is not that point.

This also matches the product rule already documented for this same feature at DistanceRequestStartPage.tsx:72-84: "never hide for a Self-DM target (personal expenses are exempt)".

What specific scenarios should we cover in automated tests?

1. Map tab, self DM, member has no home address, default workspace has commuterExclusions.method = homeAndOffice: tapping Next navigates and shows no modal. This is the reported repro and nothing covers it today.
2. Same member and workspace, but the flow targets that workspace's expense chat: tapping Next still shows the homeAddressRequired modal. This is the regression guard, and it is the case a self-DM-only check would silently break.
3. Global FAB create where the default workspace restricts and autoReporting is on, so the expense will land in the workspace: still blocked. With autoReporting off, the expense lands in the self DM: not blocked.
4. Confirmation step for the self-DM expense from scenario 1: Create expense completes without the modal, covering useExpenseSubmission.ts:975.
5. Moving that personal expense to a restricted workspace afterwards still blocks, via IOURequestEditReportCommon and DynamicReportChangeWorkspacePage.

tests/unit/hooks/useBlockDistanceRequest.test.ts covers the hook's own logic but every case passes the policy ID in directly, so none of the above is exercised. Scenarios 1 to 3 are the ones that would have caught this.

What alternative solutions did you explore? (Optional)

One-line self-DM check on the Map tab (policyID: isSelfDM(report) ? undefined : policy?.id). Smallest possible diff and it fixes the repro, but it treats the self DM as a special case rather than fixing the scoping, so the confirmation step stays broken and the same defect returns on the next screen that reads the pricing policy.

Changing usePolicyForTransaction so it stops resolving policyForMovingExpenses for track expenses. I ruled this out. Fourteen call sites depend on that fallback for rates, currency, tax and category resolution, including DynamicIOURequestStepDistanceRate, DynamicIOURequestStepTaxRatePage and IOURequestStepConfirmation. The hook's behaviour is correct for its purpose; only the guard is reading it for the wrong purpose.

Excluding homeAndOffice from the guard when the policy is not the report's policy, inside useBlockDistanceRequest. This hides the mis-scoping behind a condition in the hook rather than fixing what callers pass, and it would weaken the workspace cases in the existing tests.

[cretadn22]

@MelvinBot Implement this

[MelvinBot]

🤖 Draft PR created: #101022

Please mark it as "Ready for review" when it is ready for review.

What changed

Two call sites checked the commuter-exclusion rule against the member's default workspace instead of the expense's destination:

1. IOURequestStepDistanceMap.tsx:80 — now uses the same destination-scoped expression the Manual and Odometer tabs use, so a Self-DM track expense resolves to no policy while a global-FAB flow that auto-reports into a restricted workspace still blocks.
2. useExpenseSubmission.ts:345-350 — same unscoped policyID, now gated on isPolicyExpenseChat. Without this the member is just blocked one screen later on Create expense.

Plus a new regression test, tests/ui/IOURequestStepDistanceMapCommuterExclusionTest.tsx, covering both directions.

Testing performed

Automated (all passing):

• The new test fails on the first case without the fix and passes with it, so it genuinely locks in the behavior:
  • does not ask for a home address when the expense is a personal Self-DM track expense — ✕ before the fix, ✓ after
  • still asks for a home address when the expense is going to a workspace that excludes commutes — ✓ both before and after, so the workspace path is not weakened
• 11 related suites, 268 tests, all passing: useBlockDistanceRequest, useExpenseSubmission, IOURequestStepConfirmationPage, DistanceRequestStartPage, DynamicIOURequestStepParticipants (the suites added by Fix map/GPS distance expenses skipping home address check on move #100478), useParticipantSubmission, PolicyDistanceRatesUtils, DistanceRequestUtils, IOURequestEditReportCommon, MoneyRequestTest
• npm run typecheck — passed
• npm run lint-changed — passed
• npm run spell-changed — passed
• npm run react-compiler-compliance-check on both changed source files — passed

Not done: browser verification. The test session handed to this run rendered a blank page and never became interactive, so I could not drive the repro live. The change is deterministic client-side logic and the automated coverage above exercises both the fixed and the unchanged path, but a human should still run the manual steps before marking the PR ready.

[melvin-bot]

@cretadn22 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!