IOU shows incorrect avatar and sender name

[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: 9.1.20-2
Reproducible in staging?: y
Reproducible in production?: y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
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: @dubielzyk-expensify
Slack conversation (hyperlinked to channel name): #expensify-bugs

Action Performed:

1. Log in as user A
2. Send an IOU to user B
3. Observe the report preview

Expected Result:

Should show correct avatar and sender name (A)

Actual Result:

Showing sender name as user B and incorrect avatar

Workaround:

unknown

Platforms:

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

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

View all open jobs on GitHub

[melvin-bot]

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

[FitseTLT]

Proposal

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

IOU shows incorrect avatar and sender name

What is the root cause of that problem?

When User A sends an IOU User A will be the owner and User B the manager. So actorAccountID here

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

Line 110 in 4c087bc

const actorAccountID = getReportActionActorAccountID(action, iouReport, report, delegatePersonalDetails);

will be the iou report manager

App/src/libs/ReportUtils.ts

Lines 8988 to 8996 in 4c087bc

	case CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW: {
	const ownerAccountID = iouReport?.ownerAccountID ?? reportAction?.childOwnerAccountID;
	const actorAccountID = iouReport?.managerID ?? reportAction?.childManagerAccountID;
	if (isPolicyExpenseChat(report) || delegatePersonalDetails) {
	return ownerAccountID;
	}
	return actorAccountID;

So the display name will be the name of actorAccountID/User B

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

Line 115 in 4c087bc

let displayName = getDisplayNameForParticipant({accountID: actorAccountID});

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

For IOU report the actorAccountID should be the owner for iou reports so change

App/src/libs/ReportUtils.ts

Lines 8992 to 8993 in 4c087bc

	if (isPolicyExpenseChat(report) || delegatePersonalDetails) {
	return ownerAccountID;

 if (isPolicyExpenseChat(report) || delegatePersonalDetails || isIOUReport(iouReport)) {
                return ownerAccountID;
            }

Then we should set the secondary account for iou reports to be the managerID

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

Line 157 in 4c087bc

const secondaryAccountId = ownerAccountID === actorAccountID || isInvoiceReport ? actorAccountID : ownerAccountID;

const managerID = iouReport?.managerID ?? action?.childManagerAccountID;
            const iouManagerID = isReportPreviewAction && isIOUReport(iouReport) ? managerID : undefined;
            const secondaryAccountId = iouManagerID ?? (ownerAccountID === actorAccountID || isInvoiceReport ? actorAccountID : ownerAccountID);
            

Note: I think we might remove the code that returns managerID as actorAccountID here if it is handling only the case of iou report types. On the same note the logic of setting secondary account to actorAccountID when ownerAccountID is equal to actorAccountID here can also be removed if we do not need it anymore.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Not needed

What alternative solutions did you explore? (Optional)

[bernhardoj]

Looks like this is being handled in #50697

[slafortune]

closing as duplicate