[HOLD for payment 2024-07-22] [HOLD for payment 2024-07-17] [$250] Send invoice - "To" field displays Hidden instead of invoice receiver

[lanitochka17]

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.85-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to FAB > Send invoice.
3. Send invoice to a user.
4. Go to invoice chat.
5. Go to + > Send invoice.
6. Enter amount > Next.

Expected Result:

"To" field will display the invoice receiver

Actual Result:

"To" field displays Hidden instead of invoice receiver

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

Add any screenshot/video evidence

20240618_211242.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~013c79d3cbeca420a5
• Upwork Job ID: 1803182751188551607
• Last Price Increase: 2024-06-18
• Automatic offers:
• bernhardoj | Contributor | 102868154

Issue Owner

Current Issue Owner: @slafortune

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

[lanitochka17]

@slafortune 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

[daledah]

Proposal

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

"To" field displays Hidden instead of invoice receiver

What is the root cause of that problem?

When we calculate participants in case of invoice room here we do not pass accountID
so at confirmation step participantAccountID will be equal to -1 and display hidden user here

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

We need to pass accountID when we calculate participants

   participants = [
            {reportID: chatReport?.reportID, selected: true, accountID: chatReport?.invoiceReceiver?.accountID},
            {
                policyID: chatReport?.policyID,
                isSender: true,
                selected: false,
            },
        ];

What alternative solutions did you explore? (Optional)

result.mov

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~013c79d3cbeca420a5

[melvin-bot]

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

[bernhardoj]

Proposal

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

Hidden user is shown in the To section of send invoice from a chat.

What is the root cause of that problem?

On the confirmation page, the participant is mapped from the transaction participant data.

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Lines 139 to 149 in 904d49d

	const participants = useMemo(
	() =>
	transaction?.participants?.map((participant) => {
	const participantAccountID = participant.accountID ?? -1;
	if (participant.isSender && iouType === CONST.IOU.TYPE.INVOICE) {
	return participant;
	}
	return participantAccountID ? OptionsListUtils.getParticipantsOption(participant, personalDetails) : OptionsListUtils.getReportOption(participant);
	}) ?? [],
	[transaction?.participants, personalDetails, iouType],

If the participant has an accountID, we map it with getParticipantsOption, otherwise we map it with getReportOption. If we initiate the send invoice from the room/chat, the participant will contain a reportID, but not accountID.

App/src/libs/actions/IOU.ts

Lines 6651 to 6659 in 904d49d

	} else if (ReportUtils.isInvoiceRoom(chatReport)) {
	participants = [
	{reportID: chatReport?.reportID, selected: true},
	{
	policyID: chatReport?.policyID,
	isSender: true,
	selected: false,
	},
	];

With this information, we expect the participant to be mapped with getReportOption, however, this PR defaults the accountID to -1 (we previously defaulted it to 0).

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Line 142 in 904d49d

const participantAccountID = participant.accountID ?? -1;

So, this condition thinks that the participant is a user.

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Line 147 in 904d49d

return participantAccountID ? OptionsListUtils.getParticipantsOption(participant, personalDetails) : OptionsListUtils.getReportOption(participant);

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

We have 2 options:

1. No need to set a default value for the accountID. (preferrable)
2. Instead of checking whether the accountID falsey or not, check whether the value is > 0 or not

return participantAccountID > 0 ? OptionsListUtils.getParticipantsOption(participant, personalDetails) : OptionsListUtils.getReportOption(participant);

[thesahindia]

@bernhardoj's proposal looks good to me!

🎀 👀 🎀 C+ reviewed

[melvin-bot]

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

[melvin-bot]

@slafortune, @Gonals, @thesahindia Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

📣 @bernhardoj 🎉 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 📖

[bernhardoj]

PR is ready

cc: @thesahindia

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

• Fix "To" field displays Hidden instead of invoice receiver #44378

If no regressions arise, payment will be issued on 2024-07-17. 🎊

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

• @bernhardoj requires payment automatic offer (Contributor)
• @thesahindia requires payment through NewDot Manual Requests

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

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

[bernhardoj]

I'll request in ND once payment is due.

[slafortune]

Thanks for the heads up @bernhardoj - I closed the contract for this GH with Upworks

[thesahindia]

It was caused by the migration PR . It was a huge PR, so it's easy to miss such cases.

We don't need a specific test case here.

[melvin-bot]

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

• Fix "To" field displays Hidden instead of invoice receiver #44378

If no regressions arise, payment will be issued on 2024-07-22. 🎊

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

• @bernhardoj requires payment automatic offer (Contributor)
• @thesahindia requires payment through NewDot Manual Requests

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

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

[bernhardoj]

The payment should be due tomorrow (07-17)

[bernhardoj]

Requested in ND.

[slafortune]

@bernhardoj is due $250 for the Contributor role via NewDot
@thesahindia is due $250 for the C+ role via NewDot

[JmillsExpensify]

$250 approved for @bernhardoj

[JmillsExpensify]

$250 approved for @thesahindia