[HOLD for payment 2023-09-11] [$500] Report message naming logic is messed up

[JmillsExpensify]

Our report message naming logic is all messed up. Here's what is going on and why it's wrong.

The correct logic for the report message name should be%submitterDisplayName & %workspaceName%, like so.

However, currently what we have is something completely different, which is the policy owner followed by the submitter. It's reverse and also incorrectly showing the policy owner rather than the workspace name (in this case the workspace name is Expensify Contributors, which you can see in the owes report name).

Even worse, we completely change the report message when someone pays the report. Here's another report from the same user, and now the admin who paid the report is included in the report name, again when it should be the workspace name instead.

Good news is that the correct logic for the report message is super simple:

• The "dual-avatar" should always be that of the workspace as well as submitter
• The report message name should always take the form %submitterDisplayName & %workspaceName%

Additionally, in the report preview, the report name should always take the form %workspaceName% and then owes or paid

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0111ce66b26ea6258e
• Upwork Job ID: 1697449629715591168
• Last Price Increase: 2023-09-01

[melvin-bot]

Current assignee @JmillsExpensify is eligible for the Bug assigner, not assigning anyone new.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~0111ce66b26ea6258e

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

Current assignee @JmillsExpensify is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[DylanDylann]

@JmillsExpensify Could you help to describe the test step for this issue?

[hoangzinh]

Proposal

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

Report message naming logic is messed up

What is the root cause of that problem?

When we build display name, we always set actor & submitter name

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

Lines 116 to 125 in 3c73b7e

	if (displayAllActors) {
	const secondaryUserDetails = props.personalDetailsList[props.iouReport.ownerAccountID] || {};
	const secondaryDisplayName = lodashGet(secondaryUserDetails, 'displayName', '');
	displayName = `${primaryDisplayName} & ${secondaryDisplayName}`;
	secondaryAvatar = {
	source: UserUtils.getAvatar(secondaryUserDetails.avatar, props.iouReport.ownerAccountID),
	type: CONST.ICON_TYPE_AVATAR,
	name: secondaryDisplayName,
	id: props.iouReport.ownerAccountID,
	};

It also happens with displaying avatars as well.

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

We should update above logic so that if the actor is WS, then we should build display name as submitter & WS name. And also apply for avatar too.

[kmwamasali]

Proposal

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

Report message naming logic is messed up

What is the root cause of that problem?

The report display name is defined in

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

Lines 98 to 115 in 9b48540

	if (isWorkspaceActor) {
	displayName = ReportUtils.getPolicyName(props.report);
	actorHint = displayName;
	avatarSource = ReportUtils.getWorkspaceAvatar(props.report);
	} else if (props.action.delegateAccountID && props.personalDetailsList[props.action.delegateAccountID]) {
	// We replace the actor's email, name, and avatar with the Copilot manually for now. And only if we have their
	// details. This will be improved upon when the Copilot feature is implemented.
	const delegateDetails = props.personalDetailsList[props.action.delegateAccountID];
	const delegateDisplayName = delegateDetails.displayName;
	actorHint = `${delegateDisplayName} (${props.translate('reportAction.asCopilot')} ${displayName})`;
	displayName = actorHint;
	avatarSource = UserUtils.getAvatar(delegateDetails.avatar, props.action.delegateAccountID);
	}
	// If this is a report preview, display names and avatars of both people involved
	let secondaryAvatar = {};
	const displayAllActors = useMemo(() => props.action.actionName === CONST.REPORT.ACTIONS.TYPE.REPORTPREVIEW && props.iouReport, [props.action.actionName, props.iouReport]);
	const primaryDisplayName = displayName;

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

We should get the workspace name using
showWorkspaceDetails(props.report.reportID);
And the personal details from
props.personalDetailsList[props.action.delegateAccountID]
And set them in the desired order replacing the policy name and placing the workspace name first as required in

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

Line 119 in 9b48540

displayName = `${primaryDisplayName} & ${secondaryDisplayName}`;

What alternative solutions did you explore? (Optional)

[trjExpensify]

Hm, @Gonals you implemented this originally can you help? Any ideas what happened to cause a regression? Ideally we can quick time the fix/revert on this one if we can, so it's live for the activations next week.

Looking at the file history, I think it might be this PR?

[Gonals]

Ended up grabbing this for a quick fix. We couldn't reproduce the full issue, but after payment, we were wrongly displaying the agent's name, instead of the workspace. Fixing that.

[JmillsExpensify]

@Gonals thanks! I'm happy to give you access to the account I'm using. Besides the payment issue you fixed, it's the historical reports have the incorrect naming. I imagine we're just fixing things moving forward rather than retroactively?

[Gonals]

Hmmm. Kinda weird. It is possible we stored the data differently back then 🤷. If you have an example, I can take a look, but that explains why I couldn't reproduce it in dev

[JmillsExpensify]

Hmm, weird. I can't reproduce this one either now. We can disregard and I'll let you know if I see it again.

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

• Correctly display workspace for Money requests #26466

If no regressions arise, payment will be issued on 2023-09-11. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

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

• @mollfpr requires payment

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

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

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

[JmillsExpensify]

@mollfpr Do you mind getting us kicked off with the checklist above and also recommending a regression test?

[JmillsExpensify]

Actually scratch that. This is an internal PR so I'm closing.