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

@NicMendonca

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.

Go to staging.new.expensify.com
Go to workspace chat with no unsettled expense.
Submit a manual expense.
Go to expense report.
Click on the receipt.
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:

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

@muttmuure

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.

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

Simply the loop for finding isTransactionBeingScanned by using .some.

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

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.

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

@alitoshmatov

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

@cretadn22

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

Reviewing label has been removed, please complete the "BugZero Checklist".

@alitoshmatov

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.99-2 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

Update settlement button condition #56410

If no regressions arise, payment will be issued on 2025-02-25. 🎊

For reference, here are some details about the assignees on this issue:

@alitoshmatov requires payment through NewDot Manual Requests
@cretadn22 requires payment automatic offer (Contributor)

@alitoshmatov

@alitoshmatov @NicMendonca @alitoshmatov The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

BugZero Checklist:

[Contributor] Classify the bug:

Bug classification

Source of bug:

1a. Result of the original design (eg. a case wasn't considered)
1b. Mistake during implementation
1c. Backend bug
1z. Other:

Where bug was reported:

2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
2b. Reported on staging (eg. found during regression or PR testing)
2d. Reported on a PR
2z. Other:

Who reported the bug:

[Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

Link to comment:
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

Link to discussion:
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal Template

[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

Link to issue:

Regression Test Proposal

Precondition:

Test:

Do we agree 👍 or 👎

@alitoshmatov

@alitoshmatov bump on BZ checklist ^

@alitoshmatov

Payment summary

Contributor+: @alitoshmatov - $250 paid through NewDot Manual Requests
Contributor: @cretadn22 - $250 paid through UpWork

@cretadn22

@cretadn22 you've been paid!

BugZero Checklist:

[Contributor] Classify the bug:

Bug classification

Source of bug:

1a. Result of the original design (eg. a case wasn't considered)
1b. Mistake during implementation
1c. Backend bug
1z. Other:

Where bug was reported:

2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
2b. Reported on staging (eg. found during regression or PR testing)
2d. Reported on a PR
2z. Other:

Who reported the bug:

[Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

Link to comment: https://github.com/Expensify/App/pull/41859/files#r1972389342
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

Link to discussion: No discussion
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

I don't think regression is needed

Cool, all set here then!

Reposting payment summary: #54168 (comment)

@alitoshmatov

$250 approved for @alitoshmatov

Navigation Menu

Repository navigation

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

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Proposal

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

What is the root cause of that problem?

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

Optional Suggested Changes

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

68 remaining items

BugZero Checklist:

Regression Test Proposal

Precondition:

Test:

Payment summary

BugZero Checklist:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	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;

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

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

melvin-bot commented on Dec 15, 2024

Tony-MK commented on Dec 16, 2024

Proposal

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

What is the root cause of that problem?

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

Optional Suggested Changes

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

melvin-bot commented on Dec 17, 2024

melvin-bot commented on Dec 17, 2024

github-actions commented on Dec 21, 2024

68 remaining items

melvin-bot commented on Feb 18, 2025

melvin-bot commented on Feb 18, 2025

melvin-bot commented on Feb 18, 2025

NicMendonca commented on Feb 25, 2025

BugZero Checklist:

Regression Test Proposal

Precondition:

Test:

NicMendonca commented on Feb 25, 2025

NicMendonca commented on Feb 25, 2025

Payment summary

NicMendonca commented on Feb 25, 2025

alitoshmatov commented on Feb 26, 2025

BugZero Checklist:

NicMendonca commented on Feb 27, 2025

JmillsExpensify commented on Mar 3, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions