[PAID] [$250] IOU - Fields in transaction thread appear at the top of the page in combined IOU report

[izarutskaya]

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.61-0
Reproducible in staging?: Y
Reproducible in production?: N
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to 1:1 DM with user that has no unsettled IOU.
3. Send an IOU to the user.
4. Click on the preview.

Expected Result:

The IOU transaction thread is placed correctly.

Actual Result:

The IOU fields in transaction thread appear at the top of the page. This issue only happens in combined report.

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

Bug6442196_1712579374631.one_transaction_report_view.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01323cb2c1a74d7f5e
• Upwork Job ID: 1777640937893277696
• Last Price Increase: 2024-04-09
• Automatic offers:
• ishpaul777 | Contributor | 0

Issue Owner

Current Issue Owner: @strepanier03

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @strepanier03 (Bug), see https://stackoverflow.com/c/expensify/questions/14418 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.

[izarutskaya]

@strepanier03 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.

[izarutskaya]

We think this issue might be related to the #collect project.

[pecanoro]

Trying to figure out which PR caused this

[pecanoro]

It's interesting because it shows the total in the wrong place for a bit and then it gets updated to show the proper layout.

[pecanoro]

I could not figure out where the error is coming from so I will continue tomorrow

[nkdengineer]

Proposal

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

The IOU fields in transaction thread appear at the top of the page. This issue only happens in combined report.

What is the root cause of that problem?

For combine report, we will render both MoneyRequestView and MoneyReportView if the transaction currency is not the same with report currency.

App/src/pages/home/report/ReportActionItem.tsx

Line 760 in 1ba0795

{transactionCurrency !== report.currency && (

But the transaction in ReportActionItem for combine report is always undefined. The reason is for combine report, we filtered out the iouPreviewAction here and then action here is undefined which leading the transaction is always undefined.

App/src/pages/home/report/ReportActionItem.tsx

Line 944 in 1ba0795

const action = reportActions?.find((reportAction) => reportAction.reportActionID === parentReportActionID);

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

We should pass parentReportActionForTransactionThread prop which is the money request action of combine report from ReportActionView to ReportActionItem and then use it here to get the transactionID

key: ({parentReportActionForTransactionThread}) => {
    const transactionID = (parentReportActionForTransactionThread as OnyxTypes.OriginalMessageIOU)?.originalMessage.IOUTransactionID ? (parentReportActionForTransactionThread as OnyxTypes.OriginalMessageIOU).originalMessage.IOUTransactionID : 0;
    return `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`;
},

App/src/pages/home/report/ReportActionItem.tsx

Line 944 in 1ba0795

const action = reportActions?.find((reportAction) => reportAction.reportActionID === parentReportActionID);

To calculate parentReportActionForTransactionThread, we can do it here when we get the combineReportActions

const [combinedReportActions, parentReportActionForTransactionThread] = useMemo(() => {
        if (isEmptyObject(transactionThreadReportActions)) {
            return [allReportActions, null];
        }

       ...
        const parentReportActionForTransactionThread = allReportActions.find((action) => {
            const actionType = (action as OnyxTypes.OriginalMessageIOU).originalMessage?.type ?? '';
            return actionType === CONST.IOU.REPORT_ACTION_TYPE.CREATE || actionType === CONST.IOU.REPORT_ACTION_TYPE.TRACK || !ReportActionsUtils.isSentMoneyReportAction(action);
        })

        ...
        return [ReportActionsUtils.getSortedReportActions(filteredReportActions, true), parentReportActionForTransactionThread];
}, [allReportActions, transactionThreadReportActions]); 

App/src/pages/home/report/ReportActionsView.tsx

Line 140 in 1ba0795

const combinedReportActions = useMemo(() => {

What alternative solutions did you explore? (Optional)

Or we can simply pass the transactionID from ReportActionView to ReportActionItem. The way to get transactionID is the same as we do for parentReportActionForTransactionThread above.

[pecanoro]

I think I found the PR that caused the issue: #39465. I tried reverting the PR on my dev and it fixes the bug. However, there is a bug that also exists on prod and it's the total appearing and disappearing when the action stops being pending.

[pecanoro]

I am going to open this to external and see if we can fix both bugs in one PR.

[melvin-bot]

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

[melvin-bot]

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

[nkdengineer]

@ishpaul777 The PR is here.

[Julesssss]

@nkdengineer it sounds like the fix might not work. As this is blocking our deploy we'll need to see if anyone else has an idea for an alternative solution.

[nkdengineer]

@Julesssss I updated the PR, the main idea is correct, just a mistake in a check.

[Julesssss]

Checed this one off as we reverted the offending PR

[Julesssss]

• this hadn't yet been CP'd. But this is now done and the build is in progress

[melvin-bot]

This issue has not been updated in over 15 days. @pecanoro, @strepanier03, @ishpaul777, @nkdengineer eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[nkdengineer]

@strepanier03 The PR was deployed to production last week, please help to add Weekly label again.

[pecanoro]

I am not sure what's going on with automatization to update issues for payment

[strepanier03]

Thanks @pecanoro - automation has been hit or miss lately for sure.

[strepanier03]

@nkdengineer - Invited you to the job in Upwork.
@ishpaul777 - I've finished paying you via Upwork.

[nkdengineer]

@strepanier03 Thank you 🙇 I accepted the offer

[strepanier03]

You're welcome!

This is all paid and contracts closed, thanks everyone!