[Due for payment 2025-02-25] [$250] Expense - Approve button changes to Pay button after manually adding a receipt

[IuliiaHerets]

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.0.76-6
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers): applausetester+kh04120012@applause.expensifail.com
Issue reported by: Applause Internal Team
Device used: Mac 15.0 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Workspace has enabled Add approvals.
• Admin is the approval.

1. Go to staging.new.expensify.com
2. Go to workspace chat with no unsettled expense.
3. Submit a manual expense.
4. Go to expense report.
5. Click on the receipt.
6. Add a receipt.

Expected Result:

Approve button will not change to Pay button when receipt is in scanning state after manually adding a receipt.

Actual Result:

Approve button changes to Pay button when receipt is in scanning state after manually adding a receipt.
Approve button is hidden in the pay button dropdown list.
After the scanning is done, Pay and Approve button disappear. Approve button only appears after the page is refreshed when scanning is done.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6694830_1734267829663.20241215_205949.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021869111923159924572
• Upwork Job ID: 1869111923159924572
• Last Price Increase: 2025-01-07
• Automatic offers:
• cretadn22 | Contributor | 105693747

Issue Owner

Current Issue Owner: @NicMendonca

[melvin-bot]

Triggered auto assignment to @muttmuure (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[Tony-MK]

Proposal

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

Approve button changes to Pay button after manually adding a receipt

What is the root cause of that problem?

In MoneyReportHeader.tsx, we use the canApproveIOU function to check whether the approve settlement button can be shown.

App/src/components/MoneyReportHeader.tsx

Line 139 in 314e4fb

const shouldShowApproveButton = useMemo(() => IOU.canApproveIOU(moneyRequestReport, policy) && !hasOnlyPendingTransactions, [moneyRequestReport, policy, hasOnlyPendingTransactions]);

Instead, it returns false since a single transaction's receipt is being scanned and isTransactionBeingScanned will be true.

App/src/libs/actions/IOU.ts

Lines 7114 to 7122 in 31adaa8

	let isTransactionBeingScanned = false;
	const reportTransactions = TransactionUtils.getAllReportTransactions(iouReport?.reportID);
	for (const transaction of reportTransactions) {
	const hasReceipt = TransactionUtils.hasReceipt(transaction);
	const isReceiptBeingScanned = TransactionUtils.isReceiptBeingScanned(transaction);
	// If transaction has receipt (scan) and its receipt is being scanned, we shouldn't be able to Approve
	if (hasReceipt && isReceiptBeingScanned) {
	isTransactionBeingScanned = true;

Therefore, the last logic in the canApproveIOU shown below, will return false.

App/src/libs/actions/IOU.ts

Line 7126 in 31adaa8

return isCurrentUserManager && !isOpenExpenseReport && !isApproved && !iouSettled && !isArchivedReport && !isTransactionBeingScanned;

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

In the canApproveIOU function, we should add improve the logic using TransactionUtils.isScanRequest to check or filter the transaction is checked to set isTransactionBeingScanned to true is initially a scan request and not manual or distance request.

For example, we can modify this logic like below.

if (hasReceipt && isReceiptBeingScanned && TransactionUtils.isScanRequest(transaction)) {

Optional Suggested Changes

1. Simply the loop for finding isTransactionBeingScanned by using .some.

const isTransactionBeingScanned = reportTransactions.some((transaction) => 
 TransactionUtils.hasReceipt(transaction) &&
 TransactionUtils.isReceiptBeingScanned(transaction)&& 
 TransactionUtils.isScanRequest(transaction)
)

2. We can set the amount and merchant fields to the actual values instead of Scanning... only if the field value is available.

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

We should create a unit test for the canApproveIOU function since there is none.

Let's create IOUs with random transactions in different real-world states, such as approved, scanned, scanning, submitted, etc.. and assert whenever canApproveIOU returns an unexpected boolean value.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

@cretadn22 Your proposal will be dismissed because you did not follow the proposal template.