[HOLD for payment 2024-12-30] [HOLD on #53914] [$250] Invoices - Invoice title is not changed after it is renamed

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.72-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp https://expensify.testrail.io/index.php?/tests/view/5310233
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team

Action Performed:

Precondtion:

• Invoices are enabled.

1. Go to staging.new.expensify.com
2. Go to FAB > Send invoice.
3. Send an invoice to anyone.
4. In invoice room, click on the invoice preview.
5. Click on the report title.
6. Click on the invoice title.
7. Rename and save it.

Expected Result:

The invoice title should be changed.

Actual Result:

The invoice title is not changed after it is renamed.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6686201_1733478013504.bandicam_2024-12-06_17-33-11-641.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021865017078260739311
• Upwork Job ID: 1865017078260739311
• Last Price Increase: 2024-12-06

Issue Owner

Current Issue Owner: @twisterdotcom

[melvin-bot]

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

[twilight2294]

Proposal

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

Invoice title is not changed after it is renamed

What is the root cause of that problem?

We call getMoneyRequestReportName when getting report name for a invoice report:

App/src/libs/ReportUtils.ts

Lines 4051 to 4053 in 2dcfd50

	if (isInvoiceReport(report)) {
	formattedName = getMoneyRequestReportName(report, policy, invoiceReceiverPolicy);
	}

This results in sending the payerOwesAmount:

App/src/libs/ReportUtils.ts

Lines 3086 to 3088 in 2dcfd50

	if (isProcessingReport(report) || isOpenExpenseReport(report) || isOpenInvoiceReport(report) || moneyRequestTotal === 0) {
	return Localize.translateLocal('iou.payerOwesAmount', {payer: payerOrApproverName, amount: formattedAmount});
	}

Which is why even when we update the report name it doesn't reflect

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

We should always return report?.reportName whenever we have invoice reports present.

    if (isInvoiceReport(report)) {
        formattedName = report?.reportName;
    }

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

We should write a unit test to render the header and report details page for a invoice report. And render the text to be matched with the reportName of the invoice.

What alternative solutions did you explore? (Optional)

[bernhardoj]

Proposal

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

Invoice title doesn't change when renamed.

What is the root cause of that problem?

I believe the real issue here is that we let the user rename the report title field. The title field menu will show if there exists a report field with the type of title.

App/src/pages/ReportDetailsPage.tsx

Lines 752 to 755 in 36b9b44

	const titleField = useMemo<OnyxTypes.PolicyReportField | undefined>((): OnyxTypes.PolicyReportField | undefined => {
	const fields = ReportUtils.getAvailableReportFields(report, Object.values(policy?.fieldList ?? {}));
	return fields.find((reportField) => ReportUtils.isReportFieldOfTypeTitle(reportField));
	}, [report, policy?.fieldList]);

The invoice report itself doesn't have any report field, but the policy linked to the invoice has. If we see the logic in MoneyReportView, we will only render the report field if it's an expense report in a paid policy.

App/src/components/ReportActionItem/MoneyReportView.tsx

Lines 107 to 116 in 36b9b44

	{ReportUtils.isPaidGroupPolicyExpenseReport(report) &&
	policy?.areReportFieldsEnabled &&
	(!isCombinedReport || !isOnlyTitleFieldEnabled) &&
	sortedPolicyReportFields.map((reportField) => {
	if (ReportUtils.isReportFieldOfTypeTitle(reportField)) {
	return null;
	}
	const fieldValue = reportField.value ?? reportField.defaultValue;
	const isFieldDisabled = ReportUtils.isReportFieldDisabled(report, reportField, policy);

The getMoneyRequestReportName function also checks for the same condition, an expense report in a paid policy.

App/src/libs/ReportUtils.ts

Lines 3047 to 3049 in 36b9b44

	if (titleReportField && report?.reportName && isPaidGroupPolicyExpenseReport(report)) {
	return report.reportName;
	}

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

So, I think the solution here is to not show the report field if it's not an expense report in a paid policy. We can do that by early return here.

App/src/pages/ReportDetailsPage.tsx

Lines 752 to 755 in 36b9b44

	const titleField = useMemo<OnyxTypes.PolicyReportField | undefined>((): OnyxTypes.PolicyReportField | undefined => {
	const fields = ReportUtils.getAvailableReportFields(report, Object.values(policy?.fieldList ?? {}));
	return fields.find((reportField) => ReportUtils.isReportFieldOfTypeTitle(reportField));
	}, [report, policy?.fieldList]);

const titleField = useMemo<OnyxTypes.PolicyReportField | undefined>((): OnyxTypes.PolicyReportField | undefined => {
    if (!ReportUtils.isPaidGroupPolicyExpenseReport(report)) {
        return;
    }
    const fields = ReportUtils.getAvailableReportFields(report, Object.values(policy?.fieldList ?? {}));
    return fields.find((reportField) => ReportUtils.isReportFieldOfTypeTitle(reportField));
}, [report, policy?.fieldList]);

And since the report field title is now undefined, nameSectionExpenseIOU will be rendered,

App/src/pages/ReportDetailsPage.tsx

Line 878 in 36b9b44

{isExpenseReport && (!shouldShowTitleField || !titleField) && nameSectionExpenseIOU}

which shows the report name for report with shouldDisableRename is true (which is true for invoice)

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

I think we can merge the invoice report to Onyx and render the ReportDetailsPage. Then, verify that the nameSectionExpenseIOU exists. We need to add a testID here so we can get the component by id.

App/src/pages/ReportDetailsPage.tsx

Line 687 in 36b9b44

<View style={[styles.reportDetailsRoomInfo, styles.mw100]}>

[melvin-bot]

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

[melvin-bot]

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

[hungvu193]

I remember reviewing a similar issue in the past with editing the report title field, and we ended up deciding to disable editing (I can't find the issue at the moment :/).

@twisterdotcom Can you confirm the expected behavior here? Should we allow user to edit the title field of an Invoice request?

[melvin-bot]

@twisterdotcom, @hungvu193 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[hungvu193]

little bump @twisterdotcom

[twisterdotcom]

Do you know where that other issue is? I can sort of see the logic in not allowing edits to avoid somebody changing it from say "Services - July 2024" to "Services - December 2024", because you'd expect a new invoice. But we would want them to be able to edit it from "Services Jluy 2023" to "Services - July 2024" - basically fix mistakes, not block improper actions.

On balance, I think allowing the former will resolve more confusion and customer cases than blocking the latter, so let's go ahead with allowing edits.

[twilight2294]

hey, there is a issue to fix the invoice title #53914, I think we should close that issue and merge it into this one

[twisterdotcom]

Asked @rezkiy37 in there.

[rezkiy37]

Hi, I am Michael (Mykhailo) from Callstack, an expert agency and I can work on this issue.

[rezkiy37]

Preparing a PR - #54031.

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

• Use reportName for invoice reports #54031

If no regressions arise, payment will be issued on 2024-12-30. 🎊

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

• @hungvu193 requires payment through NewDot Manual Requests
• @rezkiy37 does not require payment (Contractor)

[melvin-bot]

@hungvu193 @twisterdotcom @hungvu193 The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[melvin-bot]

Payment Summary

Upwork Job

• Reviewer: @hungvu193 owed $250 via NewDot
• Contributor: @rezkiy37 is from an agency-contributor and not due payment

BugZero Checklist (@twisterdotcom)

• I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1865017078260739311/hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[hungvu193]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] 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: N/A

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source 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: N/A

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Test:

Precondition: Invoices feature must be enabled.

Invoices are enabled.

1. Login with any account.
2. Go to FAB > Send invoice.
3. Send an invoice to anyone.
4. In the invoice room, click on the invoice preview.
5. Click on the report title.
6. Click on the invoice title.
7. Rename and save it.
8. Verify that you can change the invoice title.

Do we agree 👍 or 👎

[melvin-bot]

@twisterdotcom, @hungvu193, @cristipaval, @rezkiy37 Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

@twisterdotcom, @hungvu193, @cristipaval, @rezkiy37 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[twisterdotcom]

Payment Summary:

• @hungvu193 paid $250 via NewDot Manual Request
• @rezkiy37 does not require payment (Contractor)

[garrettmknight]

$250 approved for @hungvu193