[One expense reports] [$250] Deleting an expense on a one-expense report doesn’t delete the corresponding report

[m-natarajan]

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: 1.4.70-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @JmillsExpensify
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1714841273549179

Action Performed:

1. Go to a workspace chat
2. Click plus and Submit expense
3. Navigate to the report
4. Write a comment or two
5. Choose Delete expense in the three-dot overflow menu
6. Navigate back to the workspace chat

Expected Result:

The one-expense report is deleted along with expense

Actual Result:

The one-expense report remains with a $0 balance

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

deleting.an.expense.on.a.one.expense.report.mp4

Add any screenshot/video evidence

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0159a6f1b83dfeb303
• Upwork Job ID: 1787848035385294848
• Last Price Increase: 2024-05-07
• Automatic offers:
• akinwale | Reviewer | 0
• nkdengineer | Contributor | 0

[melvin-bot]

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

[JmillsExpensify]

For clarity, in the case that a one-expense report is deleted and it has comments from users, we should use the existing pattern, which is:

• The report appears as [Deleted report]
• User comments are saved
• The report is converted to a chat report so that the expense report totals and report fields are no longer visible.

[trjExpensify]

@JmillsExpensify did we make this change somewhere else, can you link me to it?

The report is converted to a chat report so that the expense report totals and report fields are no longer visible.

[JmillsExpensify]

Not sure what issue, though @amyevans this is the solution we landed on right? This avoids someone confusingly opening a report with only comments and then also seeing report fields, totals, etc.

[amyevans]

Yep that's where we landed - implemented in https://github.com/Expensify/Auth/pull/10640, there's some screenies and a vid in there

[trjExpensify]

Nice! Moving it on!

[melvin-bot]

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

[melvin-bot]

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

[nkdengineer]

Proposal

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

The one-expense report remains with a $0 balance

What is the root cause of that problem?

When deleting the money request here, if it's single transaction view, we're not setting the status of the IOU report to CLOSED, so it doesn't satisfy this condition and does not show [Deleted report] correctly.

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

1. When deleting the money request here, if it's single transaction view, we should set the status of the IOU report to CLOSED.

Eg. in here we can add

if (isSingleTransactionView) {
    updatedIOUReport.statusNum = CONST.REPORT.STATUS_NUM.CLOSED;
}

We can make the condition more specific like if it's isSingleTransactionView and shouldDeleteIOUReport is false (because if shouldDeleteIOUReport we just delete the IOU report and doesn't need to update the status)

2. Optionally, we also need to update here so that the user cannot add transactions to a deleted single-transaction IOU report

if (moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.CLOSED) {
    return false;
}

3. To make sure it works for personal IOU, we will need to expand the condition here so that it will also apply to IOU report, not just expense report

What alternative solutions did you explore? (Optional)

NA

[trjExpensify]

@akinwale can you review this proposal today please? Thanks!

[kmbcook]

Yep that's where we landed - implemented in https://github.com/Expensify/Auth/pull/10640, there's some screenies and a vid in there

@amyevans I changed "Auth" to "App" in the link above but it still doesn't look like the right PR to me.

[amyevans]

@kmbcook the link was to a backend PR which has restricted access. You can see the existing pattern of

The report appears as [Deleted report]
User comments are saved
The report is converted to a chat report so that the expense report totals and report fields are no longer visible.

by following these steps though:

1. As a member of a collect policy with the workspace chat beta enabled, create an expense report with at least two expenses and at least one comment
2. Delete the report in OldDot

Screen.Recording.2024-05-09.at.2.09.11.PM.mov

So in this GH we are expecting that an expense report with one expense and 1+ comments, when deleted, displays the same as shown above

[kmbcook]

Proposal

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

Deleting an expense on a one-expense report doesn’t delete the corresponding report

What is the root cause of that problem?

The backend does not change the expense report to a chat report, in this situation.

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

In the one-expense view check to see if all IOU actions of the expense report are marked as deleted. If so, change the view to a chat report view.

Similarly, in the workspace chat check to see if each expense report preview is of an expense report for which all IOU actions are marked deleted. If so, treat the expense report as if it were a chat report instead.

Could write a function in ReportUtils called shouldTreatAsChatReport, for this purpose, which checks IOU actions of an expense report to see if they are all marked deleted. If so, the function returns true.

If shouldTreatAsChatReport does return true, in addition to treating as a chat report, also display as [Deleted report].

[akinwale]

We can move forward with @nkdengineer's proposal here.

🎀👀🎀 C+ reviewed.

[melvin-bot]

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

[kmbcook]

@akinwale, I could be missing something but it appears to me that nkdengineer's proposal will not work. The proposal is to set the status of the IOU report to closed, by setting the status of the optimistically generated IOU report to closed. The change to optimistic data is temporary. Regardless of optimistic data, after the API call successfully completes the status of the IOU report will be set to the value returned by the backend, which in this case is 0 or CONST.REPORT.STATUS_NUM.OPEN.

[blimpich]

@kmbcook I think it should work. I believe the optimistic data is being set to make sure that the app still works well even if the user's internet cuts out. The problem is not that the expense isn't being handled correctly in the backend, its that the frontend doesn't correctly render it. We want the UI to change in response to the user deleting the expense report immediately. And as @nkdengineer said in their proposal, setting that piece of state will mean that when we hit this conditional we will correctly render the report.

[melvin-bot]

📣 @akinwale 🎉 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

[melvin-bot]

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

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[kmbcook]

For clarity, in the case that a one-expense report is deleted and it has comments from users, we should use the existing pattern, which is:

• The report appears as [Deleted report]
• User comments are saved
• The report is converted to a chat report so that the expense report totals and report fields are no longer visible.

@blimpich the only way I can see for the third requirement above to be satisfied, to convert the expense report to a chat report, is for the backend to do it.

[nkdengineer]

@akinwale The PR is here.

[kmbcook]

@akinwale I can see from the submitted PR that the originally approved proposal does not work. What do you think of my proposal?

[blimpich]

@kmbcook I think you were right to say this really is an internal issue. This should not be fixed externally. Apologies for not realizing that sooner.

@akinwale please take note so that in the future we can mark issues like this as internal sooner rather than later.

I can't prioritize this right now but I'll mark this as internal and a hot pick and leave some of my investigation notes for whoever picks this up.

[melvin-bot]

Current assignee @akinwale is eligible for the Internal assigner, not assigning anyone new.

[blimpich]

Investigation notes:

I looked more deeply into this issue after the proposed PR ran up against a seemingly incorrect backend response (link). I was aware of this PR which made it so that reports with comments that are deleted in old dot are converted into chats so that their history can be preserved, so I presumed that we must be calling this command incorrectly when deleting from new dot or simply not parsing the response correctly. I thought it was a frontend issue.

However, when clicking "delete expense" in new dot we aren't actually calling auth/command/DeleteReport.cpp, which is what that previously mentioned PR actually changed. Under the hood, we are calling auth/command/DeleteMoneyRequest.cpp. So the problem isn't how we're calling it in the frontend, its how we're handling it in the backend.

The core of the logic that is executed as part of the DeleteMoneyRequest command is in Transaction::deleteMoneyRequest. That is a 200 line function that has comments that indicate that it should already be properly handling this scenario where a deleted report has comments that we want to preserve, but it doesn't seem to be working correctly.

I imagine the fix involves extracting the logic for what is done in this PR and gluing that together in Transaction::deleteMoneyRequest. But I'm unsure if Transaction::deleteMoneyRequest has a bug or just never handled this scenario to begin with. Whatever we do we should not make Transaction::deleteMoneyRequest more complicated than it already is. It's already gigantic and too complicated to be considered at all readable.

[melvin-bot]

@trjExpensify this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[trjExpensify]

@amyevans don't suppose you have any ideas on this? Or @mountiny, @luacmartins from way back when. Thanks!

[mountiny]

I would say this case was definitely working fine before as its quite simple case to test. I am wondering if we are passing wrong data to the backend with the one-expense view.

Is the transactionID and reportActionID correct when calling the deleteMoneyRequest in case of one expense report @blimpich ?

[blimpich]

From what I can see yes, the correct transactionID and reportActionID are being passed.

[rlinoz]

Asked for a Auth deploy.

[rlinoz]

Deployed to prod https://github.com/Expensify/Auth/pull/10979#issuecomment-2140490642