[HOLD for payment 2024-07-24] [HOLD for payment 2024-07-10] Send invoice - Hold option appears for invoice and error shows up when attempting to hold it

[lanitochka17]

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.2-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to FAB > Send invoice
3. Enter amount > Next
4. Send invoice to any user
5. Go to invoice thread
6. Click 3-dot menu
7. Click Hold
8. Enter a reason and save it

Expected Result:

Hold option should not appear for invoice if it is not supported (production behavior)

Actual Result:

Hold option appears for invoice and error shows up when attempting to hold the invoice

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6525058_1719394493471.20240626_173231.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abekkala

[melvin-bot]

Triggered auto assignment to @carlosmiceli (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[lanitochka17]

@carlosmiceli FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[etCoderDysto]

Proposal

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

Hold option appears for invoice and error shows up when attempting to hold it

What is the root cause of that problem?

We are not checking if the report is an invoice report before adding the hold menu item to threeDotsMenuItems here

App/src/components/MoneyReportHeader.tsx

Lines 258 to 263 in 0c20881

	if (!isOnHold && (isRequestIOU || canModifyStatus) && !isScanning) {
	threeDotsMenuItems.push({
	icon: Expensicons.Stopwatch,
	text: translate('iou.hold'),
	onSelected: () => changeMoneyRequestStatus(),
	});

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

Check if the report is invoice here by adding the following code

const isInvoiceReport = ReportUtils.isInvoiceReport(moneyRequestReport);

Add && !isInvoiceReport to the condition below to prevent adding hold menu item to threeDotsMenuItems if the report is an invoice report

if (!isOnHold && (isRequestIOU || canModifyStatus) && !isScanning && !isInvoiceReport)

App/src/components/MoneyReportHeader.tsx

Line 258 in 0c20881

if (!isOnHold && (isRequestIOU || canModifyStatus) && !isScanning) {

What alternative solutions did you explore? (Optional)

[carlosmiceli]

@etCoderDysto that looks promising, let's do it!

[etCoderDysto]

Great! I am raising ASAP.

[melvin-bot]

Current assignee @carlosmiceli is eligible for the DeployBlockerCash assigner, not assigning anyone new.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[yuwenmemon]

@etCoderDysto Any update here?

[etCoderDysto]

Pr is almost ready. It will be ready for review under 30 minutes.

[yuwenmemon]

@etCoderDysto Can you confirm whether or not this came from the following PR? #43618

[etCoderDysto]

@etCoderDysto Can you confirm whether or not this came from the following PR? #43618

I have checked with git blame and the issue seems to come from the PR.

[etCoderDysto]

@yuwenmemon @carlosmiceli
PR is ready for review

[carlosmiceli]

@etCoderDysto Reviewing.

[carlosmiceli]

@yuwenmemon Just approved/merged the PR.

[melvin-bot]

Triggered auto assignment to @abekkala (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.

[mountiny]

The PR has been CPed and QA has confirmed it worked so removing the DB label

[melvin-bot]

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

[melvin-bot]

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

• fix: Hold option appears for invoice  #44508

If no regressions arise, payment will be issued on 2024-07-10. 🎊

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

• @etCoderDysto requires payment (Needs manual offer from BZ)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@carlosmiceli] The PR that introduced the bug has been identified. Link to the PR: Feature: Hold expense in one transaction view v2 #43618
• [@carlosmiceli] 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: Feature: Hold expense in one transaction view v2 #43618 (comment)
• [@carlosmiceli] A discussion in #expensify-bugs 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. (No discussion)
• [@etCoderDysto] Determine if we should create a regression test for this bug.
• [@etCoderDysto] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@abekkala] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[abekkala]

PAYMENT SUMMARY FOR JUL 10

• Fix: @etCoderDysto [$250, if no regressions] offer
• PR Review: @carlosmiceli - internal, no payment 😉

@etCoderDysto I'm having a hard time finding your profile in Upwork. Can you link it here and I can send your offer!
Thanks

[abekkala]

updated summary above with your offer

[etCoderDysto]

I have accepted the offer. Thank you!

[etCoderDysto]

Since we are removing three-dot menu in recent releases, I don't think we need to create a regression test step.

[abekkala]

@etCoderDysto payment sent and contract ended - thank you! 🎉

[melvin-bot]

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

• fix: Hold option appears for invoice  #44508

If no regressions arise, payment will be issued on 2024-07-24. 🎊

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

• @etCoderDysto requires payment (Needs manual offer from BZ)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@carlosmiceli] The PR that introduced the bug has been identified. Link to the PR: Feature: Hold expense in one transaction view v2 #43618
• [@carlosmiceli] 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: Feature: Hold expense in one transaction view v2 #43618 (comment)
• [@carlosmiceli] A discussion in #expensify-bugs 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. (No discussion)
• [@etCoderDysto] Determine if we should create a regression test for this bug.
• [@etCoderDysto] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@abekkala] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: