[$250] Expense - Rate field is not disabled when submission frequency is off

[applause-bot]

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.4.27-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/18717689/test-cases/69314246
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Redmi note 10s android 13
App Component: Money Requests

Action Performed:

1. Launch app
2. Enable workflows and disable submissions
3. Tap fab- create distance - manual
4. Enter a distance and tap next
5. Note rate row

Expected Result:

Rate field must be disabled when submission frequency is off

Actual Result:

Rate field is not disabled when submission frequency is off

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7199206_1783154652321.Screenrecorder-2026-07-04-14-06-41-771.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074072100931122704
• Upwork Job ID: 2074072100931122704
• Last Price Increase: 2026-07-06

[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/3330ec8511638ad81ab54e1e15aacf05a05a263a07e62a51cec9124fe148f4cc

[MelvinBot]

Proposal

What is the root cause of that problem?

The Rate row's interactivity on the money request confirmation page is decided by a single flag that never looks at the workspace's submission (auto‑reporting) state.

In RateField.tsx:97:

const isRateInteractive = !!rate && !isReadOnly && iouType !== CONST.IOU.TYPE.SPLIT;

isRateInteractive is the only gate — it drives both shouldShowRightIcon (L109) and interactive (L146). None of its conditions reflect "submissions disabled," so with workflows enabled + submissions off the row stays tappable. isReadOnly is a whole‑surface read‑only flag (defaults to false), and disabled={didConfirm} (L145) only locks the row after confirming — neither represents submission frequency.

"Submission frequency off" corresponds to policy.autoReporting === false (equivalently getCorrectedAutoReportingFrequency(policy) === CONST.POLICY.AUTO_REPORTING_FREQUENCIES.MANUAL). Helpers for this already exist in PolicyUtils.ts (isInstantSubmitEnabled / isDelayedSubmissionEnabled).

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

Factor the submission state into isRateInteractive in RateField.tsx:97. policy is already a prop on this component, so no new plumbing is needed:

• Add a PolicyUtils helper that returns whether submissions are disabled, e.g. !isInstantSubmitEnabled(policy) && !isDelayedSubmissionEnabled(policy).
• Include it in the gate: const isRateInteractive = !!rate && !isReadOnly && iouType !== CONST.IOU.TYPE.SPLIT && submissionsEnabled;

Because isRateInteractive already feeds both interactive and shouldShowRightIcon, this one change disables the row and hides its chevron when submissions are off, with no other edits.

Confidence & open question

Confidence: High on the root cause (the code demonstrably never consults submission state); Medium on the exact fix condition, pending confirmation of intended behavior.

Worth confirming against OldDot/backend behavior: should the rate be disabled on any "submissions off" state, or specifically only when workflows are enabled AND submissions off (as the repro is worded)? If the latter, add a workflows‑enabled check alongside the submission check.

Note: no other confirmation field (Category, Tag, etc.) currently gates on submission state — they only use isReadOnly + didConfirm — so this is a new, narrowly‑scoped condition on the rate row rather than an existing pattern to copy.

What alternative solutions did you explore? (Optional)

None — the gating expression is the single source of truth for this row.

---

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

[kitvasyl]

Proposal

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

The distance expense Rate field remains enabled when workspace submissions are disabled, allowing users to open the rate-selection flow when the field should be read-only.

What is the root cause of that problem?

In src/components/MoneyRequestConfirmationList/sections/RateField.tsx, isRateInteractive correctly becomes false when isReadOnly is true, but MenuItemWithTopDescription receives disabled={didConfirm} only. Consequently, the field can retain its press handler even though it is rendered as non-interactive.

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

Update RateField so the menu item is disabled whenever the rate is not interactive, for example disabled={didConfirm || !isRateInteractive}. This keeps its disabled behavior consistent with the existing read-only, missing-rate, and split-expense checks and prevents navigation to the distance-rate screen.

Add a focused test verifying that the Rate field is disabled and does not navigate when isReadOnly is true, while remaining enabled for an editable distance expense.

What alternative solutions did you explore? (Optional)

We could add the same condition inside onPress, but disabling the menu item from the derived state also provides the correct visual and accessibility behavior.

[alazarlemma02]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

When submission frequency is turned off, setWorkspaceAutoHarvesting() stores autoReporting: false on the policy (https://github.com/Expensify/App/blob/main/src/libs/actions/Policy/Policy.ts#L704-L719). The manual distance global-create flow correctly uses that flag to convert the expense to a self-DM/unreported track expense by setting transactionReportID to UNREPORTED_REPORT_ID and iouType to TRACK (https://github.com/Expensify/App/blob/main/src/pages/iou/request/step/IOURequestStepDistance/handleMoneyRequestStepDistanceNavigation.ts#L440-L445), but it still resolves a workspace distance rate from policyForMovingExpenses for that track expense (https://github.com/Expensify/App/blob/main/src/pages/iou/request/step/IOURequestStepDistance/handleMoneyRequestStepDistanceNavigation.ts#L447-L454). On the confirmation screen, unreported/track expenses also resolve their policy from policyForMovingExpenses (https://github.com/Expensify/App/blob/main/src/hooks/usePolicyForTransaction.ts#L46-L50), so the rate row receives a valid policy/rate even though submissions are disabled.

The RateField editability check only verifies that there is a rate, the screen is not read-only, and the flow is not split (https://github.com/Expensify/App/blob/main/src/components/MoneyRequestConfirmationList/sections/RateField.tsx#L96-L97). It does not check the policy submission-frequency state, and the row is only disabled after confirmation via didConfirm (https://github.com/Expensify/App/blob/main/src/components/MoneyRequestConfirmationList/sections/RateField.tsx#L143-L146). Because TransactionDetailsFields passes the rate row no separate “submission frequency disabled” editability flag (https://github.com/Expensify/App/blob/main/src/components/MoneyRequestConfirmationListFooter/fieldGroups/TransactionDetailsFields.tsx#L160-L182), the row remains interactive and navigates to the distance-rate picker even when policy.autoReporting is false.

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

Add a confirmation-level disabled flag for distance-rate editing when the active confirmation policy has submission frequency off. The smallest fix is to compute something like isDistanceRateDisabled = isDistanceRequest && policy?.autoReporting === false in the confirmation field path where policy, iouType, and isDistanceRequest are already available, pass it through TransactionDetailsFields into RateField, and include it in the row’s disabled, interactive, and shouldShowRightIcon decisions.

RateField should also guard onPress with the same flag so keyboard/press execution cannot navigate to ROUTES.MONEY_REQUEST_STEP_DISTANCE_RATE when submission frequency is disabled. This keeps the displayed selected rate unchanged, but makes the row read-only in the exact policy state that made the distance expense an unreported/track expense.

What alternative solutions did you explore? (Optional)

I also considered excluding autoReporting: false policies from usePolicyForMovingExpenses, but that helper is used by many unreported-expense flows for policy-derived defaults, categories, tags, and moving expenses. Changing it would be broader than the bug. I also considered changing the distance navigation to force the P2P rate when submissions are off, but the bug is specifically that the existing displayed rate row is editable, so the safer fix is to gate rate-row interactivity at the confirmation UI.

Demo

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 10:07:04 UTC.

Proposal

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

On a workspace that has Workflows enabled but the submission frequency turned off (manual submission), the Rate row on the distance‑expense creation/confirmation step is still interactive — it shows the right chevron and navigates to the rate selector. It should be disabled (non‑interactive), the same way the rate is locked on other surfaces for this policy configuration.

What is the root cause of that problem?

The Rate row is rendered by RateField, and whether it is tappable is decided by a single derived flag, isRateInteractive. That flag never looks at the policy's submission configuration:

const isRateInteractive = !!rate && !isReadOnly && iouType !== CONST.IOU.TYPE.SPLIT;

App/src/components/MoneyRequestConfirmationList/sections/RateField.tsx

Line 97 in fb8771e

const isRateInteractive = !!rate && !isReadOnly && iouType !== CONST.IOU.TYPE.SPLIT;

Both shouldShowRightIcon={isRateInteractive} and interactive={isRateInteractive} are driven by this one value, so on the creation flow (isReadOnly is false, iouType is submit, and rate is truthy) the row is always interactive regardless of the workspace's submission settings.

On the write side, toggling "Submission frequency" off calls setWorkspaceAutoHarvesting(policy, false), which writes autoReporting: false and harvesting.enabled: false (the code comment there literally states "immediate with harvesting = false" is manual). Feeding that policy through getCorrectedAutoReportingFrequency returns MANUAL, because the frequency is IMMEDIATE with harvesting disabled:

App/src/libs/PolicyUtils.ts

Lines 1458 to 1462 in fb8771e

	function getCorrectedAutoReportingFrequency(policy: OnyxInputOrEntry<Policy>): ValueOf<typeof CONST.POLICY.AUTO_REPORTING_FREQUENCIES> | undefined {
	if (policy?.autoReportingFrequency !== CONST.POLICY.AUTO_REPORTING_FREQUENCIES.IMMEDIATE) {
	return policy?.autoReportingFrequency;
	}

So the "submission frequency is off" state is represented in Onyx as getCorrectedAutoReportingFrequency(policy) === MANUAL. Other rate surfaces already respond to this policy state — in MoneyRequestView the rate row is gated by canEditDistanceRate, which chains through canEditFieldOfMoneyRequest/canEditMoneyRequest and becomes read‑only for this policy configuration:

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 421 to 425 in fb8771e

	const canEditDistanceRate =
	isEditable &&
	canEditFieldOfMoneyRequest({
	reportAction: parentReportAction,
	fieldToEdit: CONST.EDIT_REQUEST_FIELD.DISTANCE_RATE,

The confirmation‑step RateField has no equivalent guard, which is exactly the gap that produces the symptom.

I reproduced this on a workspace with Workflows enabled and submission frequency set to Manually. Creating a distance expense on that workspace and landing on the confirmation step, the Rate row still renders as a fully interactive button with a trailing chevron, and tapping it navigates to the rate selector. The policy state itself is correct at render time, submissions are off and the workspace resolves to MANUAL, so nothing is broken in the underlying data. The failure is purely in the render/decision path: RateField.tsx computes isRateInteractive (line 97) from rate, isReadOnly, and iouType only, with no check against the workspace's submission frequency, so the row stays interactive even when submissions are off. That confirms the root cause exactly as the proposal describes.

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

RateField already receives policy as a prop, so the fix is local to that component. Import the existing helper getCorrectedAutoReportingFrequency from @libs/PolicyUtils and fold the submission‑frequency check into isRateInteractive at line 97 of src/components/MoneyRequestConfirmationList/sections/RateField.tsx:

const isSubmissionFrequencyOff = getCorrectedAutoReportingFrequency(policy) === CONST.POLICY.AUTO_REPORTING_FREQUENCIES.MANUAL;
const isRateInteractive = !!rate && !isReadOnly && iouType !== CONST.IOU.TYPE.SPLIT && !isSubmissionFrequencyOff;

This is the canonical signal used elsewhere for this policy state (requiresManualSubmission and WorkspaceWorkflowsPage both use getCorrectedAutoReportingFrequency), so we are matching an established pattern rather than inventing a new one. It is also safe for the other callers: when there is no workspace (personal/track distance expenses) policy is undefined and the helper returns undefined, so isSubmissionFrequencyOff is false and behavior is unchanged; on workspaces with delayed submission on (weekly/monthly/instant) the corrected frequency is not MANUAL, so the rate row stays tappable and rate selection keeps working. Only the precise "submissions off" state flips the row to non‑interactive, which also removes the chevron since both props read from isRateInteractive.

For QA, enable Workflows on a workspace and turn the submission frequency off, then FAB → Create distance → Manual → enter a distance → Next, and confirm the Rate row has no right chevron and does not open the rate selector. As a regression check, flip submission frequency back on (e.g. weekly or instant) and confirm the Rate row is tappable and opens the selector, and confirm a personal/track distance expense is unaffected. For unit coverage, add a RateField render test asserting interactive/shouldShowRightIcon are false when getCorrectedAutoReportingFrequency(policy) === MANUAL and true for a delayed‑submission policy.

What alternative solutions did you explore? (Optional)

Using !isDelayedSubmissionEnabled(policy) instead would also cover instant‑submit and no‑policy cases, but that is broader than the reported scenario and would disable rate selection on workspaces the issue does not flag, so the narrower MANUAL check is safer. Adding the gate in the parent (TransactionDetailsFields/MoneyRequestConfirmationList) via a shared read‑only prop was rejected because it would risk over‑disabling sibling rows (Distance, Amount) that should stay editable.

[aswin-s]

Note: This proposal is not a duplicate. It identifies a deeper root cause rather than the surface symptom.

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

On Android and Web, when a workspace has Workflows enabled but the submission frequency is set to Manual (submissions off), starting a manual Distance expense (FAB → Create → Distance → Manual → enter distance → Next) shows the Rate row on the confirmation page as tappable/editable. Expected: the Rate row should be disabled (non-interactive) in this state, matching the workspace's disabled-submission configuration.

What is the root cause of that problem?

In src/components/MoneyRequestConfirmationList/sections/RateField.tsx at line 97, isRateInteractive is computed as !!rate && !isReadOnly && iouType !== CONST.IOU.TYPE.SPLIT, and this value is passed to MenuItemWithTopDescription's interactive and shouldShowRightIcon props (lines 109, 146). It does not consult the policy's submission state at all.

There are two distinct policy fields that express "submissions off":

1. policy.autoReporting — a boolean toggle that maps directly to the "Enable submissions" switch in Workflows (WorkspaceWorkflowsPage.tsx line 464: isActive: (policy?.autoReporting && !hasDelayedSubmissionError) ?? false). When this is false, submissions are disabled regardless of frequency.
2. getCorrectedAutoReportingFrequency(policy) === CONST.POLICY.AUTO_REPORTING_FREQUENCIES.MANUAL — the corrected frequency that normalises the IMMEDIATE + harvesting.enabled = false combination into MANUAL (PolicyUtils.ts line 1458–1469).

Both states should disable the rate row, but neither is consulted by isRateInteractive. When the workspace's submissions are turned off via the toggle (autoReporting: false) the rate row still routes to ROUTES.MONEY_REQUEST_STEP_DISTANCE_RATE on tap (lines 116–142), which is why the Android/Web repro occurs.

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

1. In src/components/MoneyRequestConfirmationList/sections/RateField.tsx at line 97, extend isRateInteractive to gate on both submission-disabled states:

const isSubmissionsDisabled =
    isPolicyExpenseChat &&
    (!policy?.autoReporting ||
        PolicyUtils.getCorrectedAutoReportingFrequency(policy) === CONST.POLICY.AUTO_REPORTING_FREQUENCIES.MANUAL);

const isRateInteractive = !!rate && !isReadOnly && iouType !== CONST.IOU.TYPE.SPLIT && !isSubmissionsDisabled;

The !policy?.autoReporting arm catches the "Enable submissions" toggle being off (the bug as filed). The getCorrectedAutoReportingFrequency arm additionally covers the case where the toggle is on but the frequency is set to Manual — both represent a workspace where submission is not happening automatically and the rate should not be editable.

2. Import getCorrectedAutoReportingFrequency from @libs/PolicyUtils (already exported at PolicyUtils.ts line 2855) into RateField.tsx. The policy prop is already threaded into the component, so no new prop is needed.

3. Confirm that this is the sole fix point. RateField is the only consumer of distanceData.rate from TransactionDetailsFields.tsx:161, reached from MoneyRequestConfirmationList.tsx:558–564. No sibling RateField component exists; the gate at RateField.tsx covers both the create and edit flows.

4. Add a unit or Storybook check that renders RateField in two additional configurations and asserts interactive === false and shouldShowRightIcon === false for each:

   • policy.autoReporting = false (submissions toggle off, frequency irrelevant)
   • policy.autoReportingFrequency = IMMEDIATE, policy.harvesting.enabled = false (which getCorrectedAutoReportingFrequency resolves to MANUAL)

What alternative solutions did you explore? (Optional)

Gate at the caller (MoneyRequestConfirmationList.tsx:558) by passing an already-computed isRateDisabled prop instead of importing PolicyUtils inside RateField; rejected because RateField already receives the policy prop and computing submission-state inside the component keeps the logic co-located with the other interactivity guards (isReadOnly, iouType), avoiding prop-threading duplication.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 10:14:33 UTC.

Proposal

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

When you create a distance expense on a workspace that has submissions turned off, the Rate row on the confirmation screen is still tappable. The tester expected it to be disabled in that state.

What is the root cause of that problem?

The enabled/disabled state of the Rate row comes from a single expression in src/components/MoneyRequestConfirmationList/sections/RateField.tsx:97:

const isRateInteractive = !!rate && !isReadOnly && iouType !== CONST.IOU.TYPE.SPLIT;

That value feeds both shouldShowRightIcon (L109) and interactive (L146), so it is the only thing that decides whether the row is pressable on the creation confirmation screen. Nothing in this expression, and nothing anywhere in the confirmation flow, looks at the workspace submission frequency. I checked this directly: grepping autoReporting across src/components and src/pages/iou turns up nothing that gates rate interactivity, the canonical edit-view helper ReportUtils.canEditFieldOfMoneyRequest(DISTANCE_RATE) resolves to (isExpenseReport || isUnreportedExpense) && isDistanceRequest with no submission term, and PolicyUtils.isInstantSubmitEnabled / isDelayedSubmissionEnabled are never called from any rate or confirmation code.

This is also not a regression. isRateInteractive is byte-for-byte identical before and after the footer-decomposition refactor in c2679ed9397 (it lived at MoneyRequestConfirmationListFooter.tsx:590 before). The rate has never consulted submission frequency, so the current behavior is the original design.

So the honest read is that the expected result in the TC has no basis in the code today. Before we build a fix around "submission frequency," I think we need product/@brunovjk to confirm that the Rate row is actually supposed to disable in that state, because right now no rule ties the two together and this may be working as designed rather than a bug.

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

If the intended rule is confirmed, the change is contained. Add the real condition to isRateInteractive at RateField.tsx:97 (its only call site), which keeps the blast radius to the Rate row alone. What we should not do is set the shared isReadOnly when submissions are off. That prop is consumed by Amount, Merchant, Description, Distance, and Time in the same footer, so gating on it would disable the entire confirmation screen when the issue names only the Rate field. It also worth noting the created-expense view already gates this field more tightly (MoneyRequestView.tsx:406, canEditDistanceOrRate = isPolicyAccessible(...) || isTrackExpense || isP2PDistanceRequest), so whatever rule we land on should stay consistent with that path. There is no test today covering the Rate-row disabled state against policy submission settings, so we should add one.

What alternative solutions did you explore? (Optional)

I looked at flipping the shared isReadOnly based on autoReporting === false, but rejected it for the reason above: it would black out every field on the screen, not just Rate. I also considered that the refactor dropped a guard, but the pre/post refactor code is identical, so there was never a submission-frequency guard to lose.

[ahmdshrif]

Proposal

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

On a workspace with Workflows enabled but Submissions toggled off, the Rate row on the distance-expense confirmation page is still tappable, even though the expected behavior is for it to be disabled when the submission frequency is off.

What is the root cause of that problem?

Turning the Submissions toggle off sets policy.autoReporting = false, which means newly created expenses stay unreported instead of being added to a workspace report. But the Rate row's interactivity predicate on the confirmation page never looks at that setting. In RateField, the row is enabled by:

App/src/components/MoneyRequestConfirmationList/sections/RateField.tsx

Line 97 in fb8771e

const isRateInteractive = !!rate && !isReadOnly && iouType !== CONST.IOU.TYPE.SPLIT;

isRateInteractive = !!rate && !isReadOnly && iouType !== CONST.IOU.TYPE.SPLIT — it only checks that a rate exists, the list isn't read-only, and the request isn't a split. There is no condition on the policy's submission setting, so the row stays interactive and opens the workspace rate picker. The same predicate is duplicated in MoneyRequestConfirmationListFooter.tsx#L590, which drives other confirmation flows.

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

Extend the predicate to account for submissions being off on the target workspace, in both places:

const areSubmissionsOff = isPolicyExpenseChat && !!policy && !policy.autoReporting;
const isRateInteractive = !!rate && !isReadOnly && iouType !== CONST.IOU.TYPE.SPLIT && !areSubmissionsOff;

https://github.com/Expensify/App/blob/fb8771e18edfb21b3da9c22a27d99ea6b4689dd8/src/components/MoneyRequestConfirmationListFooter.tsx#L590

Since isRateInteractive already feeds both interactive and shouldShowRightIcon, the row is fully disabled (no chevron, no navigation) with this one change. Regression-wise, workspaces with submissions enabled (or workflows off entirely, where autoReporting is untouched) keep the current interactive behavior, as do splits and read-only views.