[HOLD for payment 2024-07-26] [$250] Hold - Red dot remains when unhold expense

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.5-3
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4700894&group_by=cases:section_id&group_id=309128&group_order=asc
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause - Internal Team

Action Performed:

Preconditions:

1. Login as the owner of the workspace
2. Create a workspace
3. Invite the approver and employee
4. Navigate to more features
5. Enable "workflows"
6. On the "Workflow" editor - enable "Add Approvals"
7. Set the Approver account as the Approver
   Steps:
8. As Employee submit 2 expenses to Workspace chat
9. As Approver hold the first expense
10. As Approver go back to the expenses page ( there is red dot on the expense that is on Hold)
11. As Approver go back to transaction thread> Unhold the expense
12. As Approver go back to expenses page

Expected Result:

There should be no red dot on the unheld expense

Actual Result:

Red dot remains when approver unhold expense

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

Bug6536079_1720455823531.Recording__3457.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01785e48b0c37e8c52
• Upwork Job ID: 1810949376048189607
• Last Price Increase: 2024-07-10
• Automatic offers:
• paultsimura | Reviewer | 103143168

Issue Owner

Current Issue Owner: @dylanexpensify

[melvin-bot]

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

[lanitochka17]

@dylanexpensify 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

[bernhardoj]

Proposal

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

The hold status isn't removed immediately from the money request preview.

What is the root cause of that problem?

The hold status comes from the transaction.comment.hold status or the transaction violations.

App/src/components/ReportActionItem/MoneyRequestPreview/MoneyRequestPreviewContent.tsx

Line 111 in bb9b486

const isOnHold = TransactionUtils.isOnHold(transaction);

App/src/components/ReportActionItem/MoneyRequestPreview/MoneyRequestPreviewContent.tsx

Line 130 in bb9b486

const shouldShowRBR = hasNoticeTypeViolations || hasViolations || hasFieldErrors || (!isFullySettled && !isFullyApproved && isOnHold);

When we hold, the transaction.comment.hold is set, but the transaction violations are still empty. After we reopen the transaction thread, the transaction violations are returned from the BE. When we unhold the request, we only optimistically remove the transaction.comment.hold.

App/src/libs/actions/IOU.ts

Lines 7041 to 7059 in bb9b486

	const optimisticData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: {
	[createdReportAction.reportActionID]: createdReportAction as ReportAction,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: {
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	comment: {
	hold: null,
	},
	},
	},
	];

So, the transaction violations (that contain hold violations) still exist, thus the money request preview still shows the hold status. Reopening the transaction thread once again will clear it.

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

Optimistically removes the transaction violations of hold when unhold-ing a request. (and revert it when fails)

{
    onyxMethod: Onyx.METHOD.SET,
    key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transactionID}`,
    value: transactionViolations?.filter((violation) => violation.name !== 'hold') ?? [],
},

I also suggest to return the onyx update to clears the hold violation from the UnholdRequest API.

(we can also optimistically add the hold violation if needed, lmk if we should do it)

[dylanexpensify]

moving!

[melvin-bot]

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

[melvin-bot]

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

[paultsimura]

Reviewing today 👀

[paultsimura]

The proposal by @bernhardoj looks good to me.

🎀👀🎀 C+ reviewed

@cead22 sorry if you're the wrong person, but IIRC you were implementing the violations initially. We should modify the BE to remove the hold violation on the UnholdRequest API endpoint (in addition to the App changes). Could you please check it?

[melvin-bot]

Triggered auto assignment to @Beamanator, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[Beamanator]

I'm OOO today, hopefully @cead22 can check the comments above - if not, I'll get back to this by wednesday / thursday

[melvin-bot]

@Beamanator, @paultsimura, @dylanexpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

📣 @paultsimura 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[cead22]

We should modify the BE to remove the hold violation on the UnholdRequest API endpoint (in addition to the App changes). Could you please check it?

I created an issue for us to update this

[bernhardoj]

PR is ready

cc: @paultsimura

[Beamanator]

Thanks @cead22 - I am happy to review the PR for this front end part, but also feel free to assign yourself if you want it 🙏

[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.9-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix red dot remains when unhold expense #45584

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

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

• @paultsimura requires payment automatic offer (Reviewer)
• @bernhardoj requires payment through NewDot Manual Requests

[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:

• [@paultsimura] The PR that introduced the bug has been identified. Link to the PR:
• [@paultsimura] 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:
• [@paultsimura] 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. Link to discussion:
• [@paultsimura] Determine if we should create a regression test for this bug.
• [@paultsimura] 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.
• [@dylanexpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[dylanexpensify]

Payment coming up!

[paultsimura]

• The PR that introduced the bug has been identified. Link to the PR: [WAVE7] Hold Requests: Approving/Paying expense reports with held requests #33124
• 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/33124/files#r1686797407
• 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. Link to discussion: N/A
• Determine if we should create a regression test for this bug: Yes
• 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.

Regression Test Proposal

1. Create a workspace if you have none
2. Submit at least 2 expenses to the workspace
3. Open one of the transaction threads
4. Click the report header and hold the transaction
5. Go back to the expense report
6. Verify there is an RBR on the transaction preview that you held
7. Open the same transaction thread again and unhold the transaction
8. Go back to the expense report
9. Verify the RBR is gone from the said transaction preview

Do we agree 👍 or 👎

[melvin-bot]

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

[dylanexpensify]

@OfstadC I'm heading OOO starting this afternoon, so reassigning for payment! TY!

[bernhardoj]

Payment is due today. Requested in ND.

[OfstadC]

Payment Summary:

@paultsimura paid $250 via Upwork
@bernhardoj due $250 via NewDot

[JmillsExpensify]

$250 approved for @bernhardoj