[$250] Email - Wrong subject and action button in email preview

[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.19-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/test-runs/TR-48574/folder/13176725/41237080/1515171550?sort=%2Bidentifier
Email or phone of affected tester (no customers): leungbratt6+25061@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: Money Requests

Action Performed:

Workspace setup:

1. Add a member you have access to as an employee
2. Disable Approvals
3. Delay Submissions is OFF
4. Add a bank account and Disable Payments

Steps:

1. Log in as the employee
2. Navigate to the workspace chat and submit a DISTANCE expense to the workspace
3. Check the email inbox of the Approver
4. Verify that the ReportSubmission email was received immediately
5. Verify the email subject reads: “Submitted my amount expense”
6. Verify no action button is displayed in the report preview component

Expected Result:

5. Verify the email subject reads: “Submitted my amount expense”
6. Verify no action button is displayed in the report preview component

Actual Result:

Wrong email subject and action button in preview after adding bank acount

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7190504_1782356352557.wrong_email_distance.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070033432989382836
• Upwork Job ID: 2070033432989382836
• Last Price Increase: 2026-06-25

Issue Owner

Current Issue Owner: @cead22

[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/71e978ad01375307e3723bafa274f1fd9362189c9e9c36a1415cfbaa9e54ebd1

[MelvinBot]

Issue Analysis

Root Cause (outside the App repo): Both symptoms — the wrong email subject and the unexpected action button in the email's report-preview component — originate in the backend email-generation system (Old Dot / Web-Expensify), not in this repository. New Expensify (Expensify/App) does not generate the ReportSubmission email's subject line or the action buttons rendered inside an emailed report preview; those are built server-side.

The trigger described in the report — "after adding a bank account" with Payments disabled — points to the backend incorrectly treating the report as payable once a bank account exists on the workspace. That mis-classification is what produces (a) a different subject than the expected "Submitted my amount expense", and (b) a payment/action button in the preview that should be suppressed when payments are off.

This cannot be fixed in Expensify/App. The change needs to be made in the internal backend email/report-preview code by an engineer with access to that repository. Please escalate to an internal engineer.

Why this is backend, not App

• A search of the App source for the expected subject string "Submitted my amount expense" and for ReportSubmission-email subject/action-button logic returns nothing — App only contains EmailUtils (email-address helpers), not email-content templating.
• The test verifies content delivered to the approver's email inbox, which is rendered server-side. The in-app ReportPreview component is a separate code path and is not what the email displays.
• Confidence: Medium — high confidence the root cause is server-side and not in App; the exact backend code path could not be inspected here because that repo isn't accessible from this workspace.

---

Next Steps for Contributor+ team: This is a backend email issue and should be handled by an internal engineer. Reply with @MelvinBot <your feedback> if you believe part of this belongs in the App repo and I should re-investigate.

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022070033432989382836

[godzillaxbox19982014-lgtm]

Proposal

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

Email - Wrong subject and action button in email preview

What is the root cause of that problem?

I traced this to the path that handles expense report, OFF, DISTANCE:

• src/pages/iou/request/step/IOURequestStepScan/components/ReceiptPreviews/index.tsx:48 (if): if (optimisticTransactionsReceipts.length >= initialReceiptsAmount) {
• src/pages/iou/request/step/IOURequestStepTimeWorkspace.tsx:38 (setMoneyRequestParticipantsFromReport): setMoneyRequestParticipantsFromReport(transactionID, policyExpenseChat, accountID);
• src/pages/iou/request/step/IOURequestStepScan/components/ScanSkipConfirmation.tsx:218 (ScanSkipConfirmation): scenario: CONST.TELEMETRY.SUBMIT_EXPENSE_SCENARIO.SPLIT_RECEIPT,
• The local evidence matches this recurring failure shape: optimistic transaction/report data is written to one Onyx key but the visible list reads another derived key. Here, src/pages/iou/request/step/IOURequestStepScan/components/ReceiptPreviews/index.tsx:48 and src/pages/iou/request/step/IOURequestStepTimeWorkspace.tsx:38 do not agree on the same expense report, OFF, DISTANCE value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/iou/request/step/IOURequestStepScan/components/ReceiptPreviews/index.tsx:48 to derive expense report, OFF, DISTANCE from the report/transaction source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/iou/request/step/IOURequestStepTimeWorkspace.tsx:38; that follows the safer family move to align optimistic/success/failure data with the selector consumed by the screen, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Reports, Expenses, IOU, Transactions surface and avoid changing payment actions, personal/deleted policies.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/ReportUtils*.ts for the exact issue flow: Email - Wrong subject and action button in email preview.
2. Cover the counter-case near src/pages/iou/request/step/IOURequestStepScan/components/ReceiptPreviews/index.tsx:48 so valid existing expense report, OFF, DISTANCE behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep expense report, OFF, DISTANCE consistent at the first read/write boundary shown above.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-25 06:40:22 UTC.

Proposal

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

The ReportSubmission email sent to the approver has the wrong subject ("Submitted my amount expense") and renders an action button inside the report-preview block, when a distance expense is submitted to a workspace that has Approvals disabled, Delay Submissions off, and Payments disabled (after a bank account was added).

What is the root cause of that problem?

Both symptoms are produced server-side, not by NewDot:

• The ReportSubmission email (its subject line and the report-preview HTML embedded in the body) is generated by the backend (Web-Expensify / Auth), not by the App. A search of the App repo for the subject string and the email template returns nothing — NewDot never builds this email.
• The "amount" in the subject is an unsubstituted/zero report-total placeholder for the distance expense in the submission template, and the action button is rendered by the email's own preview gating, which does not account for reimbursementChoice === REIMBURSEMENT_NO (Payments disabled) together with Approvals disabled.

For reference, the equivalent NewDot in-app gating is already correct for this exact case, so the bug is isolated to the email template. The report-preview action is computed by getReportPreviewAction → canPay:

App/src/libs/ReportPreviewActionUtils.ts

Lines 201 to 267 in 75f7b14

	function getReportPreviewAction({
	isReportArchived,
	currentUserAccountID,
	currentUserLogin,
	report,
	policy,
	transactions,
	bankAccountList,
	invoiceReceiverPolicy,
	isPaidAnimationRunning,
	isApprovedAnimationRunning,
	isSubmittingAnimationRunning,
	isDEWSubmitPending,
	violationsData,
	reportMetadata,
	}: {
	isReportArchived: boolean;
	currentUserAccountID: number;
	currentUserLogin: string;
	report: Report | undefined;
	policy: Policy | undefined;
	transactions: Transaction[];
	bankAccountList: OnyxEntry<BankAccountList>;
	invoiceReceiverPolicy?: Policy;
	isPaidAnimationRunning?: boolean;
	isApprovedAnimationRunning?: boolean;
	isSubmittingAnimationRunning?: boolean;
	isDEWSubmitPending?: boolean;
	violationsData?: OnyxCollection<TransactionViolation[]>;
	reportMetadata: OnyxEntry<ReportMetadata>;
	}): ValueOf<typeof CONST.REPORT.REPORT_PREVIEW_ACTIONS> {
	if (!report) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.VIEW;
	}
	// We want to have action displayed for either paid or approved animations
	if (isPaidAnimationRunning || isApprovedAnimationRunning) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.PAY;
	}
	if (isSubmittingAnimationRunning) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.SUBMIT;
	}
	if (isAddExpenseAction(report, transactions ?? [], isReportArchived)) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.ADD_EXPENSE;
	}
	if (isDEWSubmitPending && isOpenReport(report)) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.VIEW;
	}
	if (canSubmit(report, isReportArchived, currentUserAccountID, currentUserLogin, violationsData, policy, transactions)) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.SUBMIT;
	}
	if (canApprove(report, currentUserAccountID, reportMetadata, policy, transactions)) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.APPROVE;
	}
	if (canPay(report, isReportArchived, currentUserAccountID, currentUserLogin, bankAccountList, transactions, policy, invoiceReceiverPolicy)) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.PAY;
	}
	if (canExport(report, currentUserLogin, policy)) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.EXPORT_TO_ACCOUNTING;
	}
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.VIEW;
	}

App/src/libs/ReportPreviewActionUtils.ts

Lines 107 to 169 in 75f7b14

	function canPay(
	report: Report,
	isReportArchived: boolean,
	currentUserAccountID: number,
	currentUserLogin: string,
	bankAccountList: OnyxEntry<BankAccountList>,
	transactions: Transaction[],
	policy?: Policy,
	invoiceReceiverPolicy?: Policy,
	) {
	if (isReportArchived) {
	return false;
	}
	const isReportPayer = isPayer(currentUserAccountID, currentUserLogin, report, bankAccountList, policy, false);
	const isExpense = isExpenseReport(report);
	const isPaymentsEnabled = arePaymentsEnabled(policy);
	const isProcessing = isProcessingReport(report);
	const isApprovalEnabled = policy ? policy.approvalMode && policy.approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL : false;
	const isSubmittedWithoutApprovalsEnabled = !isApprovalEnabled && isProcessing;
	const isApproved = isReportApproved({report}) || isSubmittedWithoutApprovalsEnabled;
	const isClosed = isClosedReport(report);
	const isReportFinished = (isApproved || isClosed) && !report.isWaitingOnBankAccount;
	const {reimbursableSpend, nonReimbursableSpend} = getMoneyRequestSpendBreakdown(report);
	const isReimbursed = isSettled(report);
	const isExported = report.isExportedToIntegration ?? false;
	const hasExportError = hasExportErrorUtil(undefined, report);
	const didExportFail = !isExported && hasExportError;
	if (
	isExpense &&
	isReportPayer &&
	isPaymentsEnabled &&
	isReportFinished &&
	(reimbursableSpend !== 0 || (nonReimbursableSpend !== 0 && hasOnlyNonReimbursableTransactions(report?.reportID, transactions)))
	) {
	return !didExportFail;
	}
	if (!isProcessing) {
	return false;
	}
	const isIOU = isIOUReport(report);
	if (isIOU && isReportPayer && !isReimbursed && reimbursableSpend > 0) {
	return true;
	}
	const isInvoice = isInvoiceReport(report);
	if (!isInvoice) {
	return false;
	}
	const parentReport = getParentReport(report);
	if (parentReport?.invoiceReceiver?.type === CONST.REPORT.INVOICE_RECEIVER_TYPE.INDIVIDUAL && reimbursableSpend > 0) {
	return parentReport?.invoiceReceiver?.accountID === currentUserAccountID;
	}
	return invoiceReceiverPolicy?.role === CONST.POLICY.ROLE.ADMIN && reimbursableSpend > 0;
	}

canPay gates the expense path on isPaymentsEnabled = arePaymentsEnabled(policy), which is false when Payments are disabled:

App/src/libs/PolicyUtils.ts

Lines 1354 to 1356 in 75f7b14

	/** Get a tax with given ID from policy */
	function getTaxByID(policy: OnyxEntry<Policy>, taxID: string): TaxRate | undefined {

and isPayer returns false for a paid group policy whose reimbursementChoice is REIMBURSEMENT_NO, even after a bank account is added:

App/src/libs/ReportUtils.ts

Lines 2837 to 2878 in 75f7b14

	if (isPaidGroupPolicy(iouReport)) {
	if (reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_YES) {
	if (!policy?.achAccount?.reimburser) {
	return isAdmin;
	}
	// If user is the reimburser, or a policy admin with access to the business bank account via sharees, they can pay.
	const isReimburser = currentUserEmailParam === policy?.achAccount?.reimburser;
	// Check if the current user has access to the bank account via sharees
	const bankAccountID = policy?.achAccount?.bankAccountID;
	const bankAccount = bankAccountID ? bankAccountList?.[bankAccountID] : null;
	const hasAccessToBankAccount = currentUserEmailParam && bankAccount?.accountData?.sharees ? bankAccount.accountData.sharees.includes(currentUserEmailParam) : false;
	return isReimburser || (isAdmin && hasAccessToBankAccount);
	}
	if (reimbursementChoice === CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_MANUAL || onlyShowPayElsewhere) {
	return isAdmin;
	}
	return false;
	}
	return isAdmin || (isMoneyRequestReport(iouReport) && isManager);
	}
	/**
	* Checks if the current user is the action's author
	*/
	function isActionCreator(reportAction: OnyxInputOrEntry<ReportAction> | Partial<ReportAction>): boolean {
	return reportAction?.actorAccountID === deprecatedCurrentUserAccountID;
	}
	/**
	* Returns the notification preference of the action's child report if it exists.
	* Otherwise, calculates it based on the action's authorship.
	*/
	function getChildReportNotificationPreference(reportAction: OnyxInputOrEntry<ReportAction> | Partial<ReportAction>): NotificationPreference {
	const childReportNotificationPreference = reportAction?.childReportNotificationPreference ?? '';
	if (childReportNotificationPreference) {
	return childReportNotificationPreference;
	}

With Approvals disabled canApprove also returns false, so NewDot correctly shows no action button. The email path needs the same two checks applied server-side.

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

The fix belongs in the backend ReportSubmission email template (Web-Expensify / Auth), not in this repo:

• Subject: substitute the actual report total instead of the literal "amount" token, and fall back to the report title when the distance total is still 0 / unresolved at submission time.
• Report-preview action button: gate it on the same conditions NewDot uses — only render a Pay button when arePaymentsEnabled(policy) is true (i.e. reimbursementChoice !== REIMBURSEMENT_NO) and the viewer is the payer, and only render Approve when an approval workflow is enabled. With Payments and Approvals both disabled, render no button.

We should move this issue to the backend (Web-Expensify) project since the App cannot produce or alter this email.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Backend email test: submit a distance expense to a workspace with Approvals disabled, Delay Submissions off, and Payments disabled — assert the ReportSubmission subject contains the resolved total (no literal "amount" placeholder) and that the email body's report preview renders no action button.

What alternative solutions did you explore? (Optional)

N / A

[x-dev90]

Proposal

What is the root cause of that problem?

When the user disables Payments from the Workflows page, the page correctly computes reimbursementChoice = reimburseNo and calls setWorkspaceReimbursement() with the currently attached bank account ID:

App/src/pages/workspace/workflows/WorkspaceWorkflowsPage.tsx

Lines 620 to 635 in f289caf

	if (!isEnabled) {
	newReimbursementChoice = CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_NO;
	} else if (!!policy?.achAccount && !isCurrencySupportedForDirectReimbursement((policy?.outputCurrency ?? '') as CurrencyType)) {
	newReimbursementChoice = CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_MANUAL;
	} else {
	newReimbursementChoice = CONST.POLICY.REIMBURSEMENT_CHOICES.REIMBURSEMENT_YES;
	}
	const newReimburserEmail = policy?.achAccount?.reimburser ?? policy?.owner;
	setWorkspaceReimbursement({
	policyID: route.params.policyID,
	currentAchAccount: policy?.achAccount,
	currentReimbursementChoice: policy?.reimbursementChoice,
	reimbursementChoice: newReimbursementChoice,
	reimburserEmail: newReimburserEmail ?? '',
	bankAccountID: policy?.achAccount?.bankAccountID,

But setWorkspaceReimbursement() exits early whenever the passed bank account is already connected to the policy:

App/src/libs/actions/Policy/Policy.ts

Lines 1154 to 1160 in f289caf

	const oldBankAccountID = Object.keys(bankAccountList ?? {}).find((accountID) => {
	const account = bankAccountList?.[accountID];
	return account?.accountData?.policyIDs?.includes(policyID);
	});
	if (oldBankAccountID !== undefined && String(bankAccountID) === oldBankAccountID) {
	return;

That early return only checks the bank account ID. It does not check whether reimbursementChoice is changing. So after a bank account is added, disabling Payments becomes a no-op: App never sends SetWorkspaceReimbursement with reimburseNo, and the policy remains payment-enabled.

Report preview/payability logic treats payment-enabled reports as payable through arePaymentsEnabled(policy):

App/src/libs/ReportPreviewActionUtils.ts

Lines 121 to 144 in f289caf

	const isReportPayer = isPayer(currentUserAccountID, currentUserLogin, report, bankAccountList, policy, false);
	const isExpense = isExpenseReport(report);
	const isPaymentsEnabled = arePaymentsEnabled(policy);
	const isProcessing = isProcessingReport(report);
	const isApprovalEnabled = policy ? policy.approvalMode && policy.approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL : false;
	const isSubmittedWithoutApprovalsEnabled = !isApprovalEnabled && isProcessing;
	const isApproved = isReportApproved({report}) || isSubmittedWithoutApprovalsEnabled;
	const isClosed = isClosedReport(report);
	const isReportFinished = (isApproved || isClosed) && !report.isWaitingOnBankAccount;
	const {reimbursableSpend, nonReimbursableSpend} = getMoneyRequestSpendBreakdown(report);
	const isReimbursed = isSettled(report);
	const isExported = report.isExportedToIntegration ?? false;
	const hasExportError = hasExportErrorUtil(undefined, report);
	const didExportFail = !isExported && hasExportError;
	if (
	isExpense &&
	isReportPayer &&
	isPaymentsEnabled &&
	isReportFinished &&
	(reimbursableSpend !== 0 || (nonReimbursableSpend !== 0 && hasOnlyNonReimbursableTransactions(report?.reportID, transactions)))
	) {
	return !didExportFail;

That is why the submitted expense notification is generated as a payable expense with the “Please pay…” subject and Pay button instead of the submit-and-close/no-payments notification.

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

Keep the same-bank-account no-op only when the reimbursement choice is also unchanged.

Required changes:

• Update the early return in setWorkspaceReimbursement() so it returns only when:
  • the old bank account ID matches the requested bank account ID, and
  • currentReimbursementChoice === reimbursementChoice
• Add a focused action test for the regression:
  • setup policy with reimbursementChoice = reimburseYes
  • setup bankAccountList where the same bank account is already attached to the policy
  • call setWorkspaceReimbursement() with the same bank account ID and reimbursementChoice = reimburseNo
  • assert the policy is optimistically updated to reimburseNo
  • assert SetWorkspaceReimbursement is sent with reimburseNo

I considered changing report preview button logic, but that would only hide the symptom after the policy remains in the wrong payment-enabled state. The root cause is the skipped SetWorkspaceReimbursement write, so the fix belongs in the action-layer no-op guard.

What alternative solutions did you explore? (Optional)

[sumairq]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.