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

lanitochka17 commented 1 month ago

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.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): gocemate+workspaceapprover135@gmail.com Issue reported by: Applause - Internal Team

Action Performed:

Preconditions:

Login as the owner of the workspace
Create a workspace
Invite the approver and employee
Navigate to more features
Enable "workflows"
On the "Workflow" editor - enable "Add Approvals"
Set the Approver account as the Approver Steps:
As Employee submit 2 expenses to Workspace chat
As Approver hold the first expense
As Approver go back to the expenses page ( there is red dot on the expense that is on Hold)
As Approver go back to transaction thread> Unhold the expense
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?

[x] Android: Native
[x] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/c8fa0886-2f65-4585-9459-2498c5609c95

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[bot] commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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. https://github.com/Expensify/App/blob/bb9b4864694e6a97ee00bd07e3d87e9d9d462e6b/src/components/ReportActionItem/MoneyRequestPreview/MoneyRequestPreviewContent.tsx#L111 https://github.com/Expensify/App/blob/bb9b4864694e6a97ee00bd07e3d87e9d9d462e6b/src/components/ReportActionItem/MoneyRequestPreview/MoneyRequestPreviewContent.tsx#L130

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. https://github.com/Expensify/App/blob/bb9b4864694e6a97ee00bd07e3d87e9d9d462e6b/src/libs/actions/IOU.ts#L7041-L7059

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 commented 1 month ago

moving!

melvin-bot[bot] commented 1 month ago

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

melvin-bot[bot] commented 1 month ago

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

paultsimura commented 1 month ago

Reviewing today 👀

paultsimura commented 1 month ago

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[bot] commented 1 month ago

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

Beamanator commented 1 month ago

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

melvin-bot[bot] commented 1 month ago

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

melvin-bot[bot] commented 1 month ago

📣 @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 commented 1 month ago

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 commented 1 month ago

PR is ready

cc: @paultsimura

Beamanator commented 1 month ago

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[bot] commented 1 month ago

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

melvin-bot[bot] commented 1 month ago

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

https://github.com/Expensify/App/pull/45584

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

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[bot] commented 1 month ago

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 commented 1 month ago

Payment coming up!

paultsimura commented 1 month ago

The PR that introduced the bug has been identified. Link to the PR: https://github.com/Expensify/App/pull/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

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

Do we agree 👍 or 👎

melvin-bot[bot] commented 1 month ago

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 commented 1 month ago

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

bernhardoj commented 1 month ago

Payment is due today. Requested in ND.

OfstadC commented 1 month ago

Payment Summary:

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

JmillsExpensify commented 1 month ago

$250 approved for @bernhardoj

Expensify / App