[Due for payment 2025-06-02] [$250] Members are able to edit the title of `approved` reports.

[vincdargento]

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.5-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5650477
Email or phone of affected tester (no customers): agexptest+cw.employee@gmail.com
Issue reported by: Applause Internal Team
Device used: Windows 10/ Chrome, Samsung S23FE/ Android 14
App Component: Money Requests

Action Performed:

Preconditions:
Use a Control workspace with an admin and an employee.
In Workflows, the Delay submissions option is set to manually. The Add approvals toggle is enabled and the default workflow is set.
Rules feature enabled in the workspace.
Custom report names option is enabled and Custom name has any text.
Auto-approve compliant reports option is enabled and Auto-approve reports under option is set to any value.

Steps:

1. Navigate to https://staging.new.expensify.com/
2. Login as an employee of the workspace
3. In the workspace chat, create a manual expense with the amount under the value set in the "Auto-approve reports under" option (The goal is to have an expense that is auto-approved by workspace rules and stay in Waiting for pay status)
4. Go to the expense details
5. Submit the expense
6. Edit the Title field

Expected Result:

Only workspace admins should be able to update the report titles of approved reports (like OldDot).

Actual Result:

The report title field is editable by the member in the approved state.

Note: apparently there was an error message shown in the original bug report, but I can't repro that, though I can still edit the report title of the approved report as the member - but I shouldn't be allowed to.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021896634803332390366
• Upwork Job ID: 1896634803332390366
• Last Price Increase: 2025-05-05
• Automatic offers:
• Tony-MK | Contributor | 107225030

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

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

[nkdengineer]

🚨 Edited by proposal-police: This proposal was edited at 2025-02-25 18:00:43 UTC.

Proposal

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

The Title field is editable and an error message is displayed after committing the new Title. By going to the workspace chat and entering again to the expense details, the Title field has the new name for a little while and a message in the thread is displayed saying that the title has changed.

What is the root cause of that problem?

We always show shouldShowRightIcon and interactive as true here

App/src/components/ReportActionItem/MoneyReportView.tsx

Lines 154 to 159 in cde1841

	shouldShowRightIcon
	disabled={isFieldDisabled}
	wrapperStyle={[styles.pv2, styles.taskDescriptionMenuItem]}
	shouldGreyOutWhenDisabled={false}
	numberOfLinesTitle={0}
	interactive

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

1. We can pass transactionThreadReport as props to MoneyReportView

2. Create the condition like we did with MoneyRequestView here. We should create a new variable like canEdit and pass it to shouldShowRightIcon and interactiveand we also add || isAdmin to the condition if we want the admin can edit report title field

 const parentReportID = transactionThreadReport?.parentReportID;
    const [parentReportActions] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${parentReportID ?? CONST.DEFAULT_NUMBER_ID}`, {
        canEvict: false,
    });
    const [reportActions] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${report?.reportID ?? CONST.DEFAULT_NUMBER_ID}`, {
        canEvict: false,
    });

    const parentReportAction = transactionThreadReport?.parentReportActionID
        ? parentReportActions?.[transactionThreadReport.parentReportActionID]
        : Object.values(reportActions ?? {}).find((action) => action.actionName === CONST.REPORT.ACTIONS.TYPE.IOU);
    const linkedTransactionID = useMemo(() => {
        if (!parentReportAction) {
            return undefined;
        }
        const originalMessage = parentReportAction && isMoneyRequestAction(parentReportAction) ? getOriginalMessage(parentReportAction) : undefined;
        return originalMessage?.IOUTransactionID;
    }, [parentReportAction]);

    const [transaction] = useOnyx(`${ONYXKEYS.COLLECTION.TRANSACTION}${linkedTransactionID ?? CONST.DEFAULT_NUMBER_ID}`);
    const canUserPerformWriteAction = !!canUserPerformWriteActionReportUtils(transactionThreadReport ?? report);
    const isAdmin = policy?.role === CONST.POLICY.ROLE.ADMIN;
    const canEdit = (isMoneyRequestAction(parentReportAction) && canEditMoneyRequest(parentReportAction, transaction) && canUserPerformWriteAction) || isAdmin;

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

Lines 154 to 161 in cba89eb

	<MoneyReportView
	report={report}
	policy={policy}
	isCombinedReport
	pendingAction={action?.pendingAction}
	shouldShowTotal={transaction ? transactionCurrency !== report?.currency : false}
	shouldHideThreadDividerLine={shouldHideThreadDividerLine}
	/>

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

UI bug, don't need to create unit tests. If needed, we can render MoneyReportView with mock data , and check if the user isn't admin, item will not interactive and right icon will not show.

What alternative solutions did you explore? (Optional)

OR we can create the condition like we did with MoneyRequestView here

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 179 to 180 in cba89eb

	const canUserPerformWriteAction = !!canUserPerformWriteActionReportUtils(report) && !readonly;
	const canEdit = isMoneyRequestAction(parentReportAction) && canEditMoneyRequest(parentReportAction, transaction) && canUserPerformWriteAction;

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[twilight2294]

Proposal

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

Error message when an employee changes the report name of an approved expense

What is the root cause of that problem?

We have always set the value of shouldShowRightIcon and interactive without checking if that is allowed for approved report

App/src/components/ReportActionItem/MoneyReportView.tsx

Lines 146 to 159 in cde1841

	<MenuItemWithTopDescription
	description={Str.UCFirst(reportField.name)}
	title={fieldValue}
	onPress={() => {
	Navigation.navigate(
	ROUTES.EDIT_REPORT_FIELD_REQUEST.getRoute(report?.reportID, report?.policyID, reportField.fieldID, Navigation.getReportRHPActiveRoute()),
	);
	}}
	shouldShowRightIcon
	disabled={isFieldDisabled}
	wrapperStyle={[styles.pv2, styles.taskDescriptionMenuItem]}
	shouldGreyOutWhenDisabled={false}
	numberOfLinesTitle={0}
	interactive

This causes the name to be editable on the FE but the BE throws error and we see that error on the FE later, this is the RCA.

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

The fix would be to check if the field is indeed editable, we need to use canUserPerformWriteAction from the reportUtils:

App/src/libs/ReportUtils.ts

Line 7876 in cba89eb

function canUserPerformWriteAction(report: OnyxEntry<Report>) {

This would make sure to keep the item actionable only when it can be edited.

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

We will create a UI test here which will render the MoneyReportViewcomponent with mock Onyx data, and we will set the report status to approved, then we will get the UI component and check if the item is not interactive and editable.

What alternative solutions did you explore? (Optional)

N/A

[trjExpensify]

As the submitter, I'm not running into the error when changing the report title after the report is in the Approved state.

Though, I agree on OldDot we don't let submitters change the report title of approved reports:

So it's inconsistent here, and we have two options to consider:

1. Update OldDot to allow submitters to edit report titles of approved reports.
2. Update NewDot to only let workspace admins update the report titles of approved reports.

I vote the 2nd option at this juncture, and makes more sense in-line with their overall edit capabilities of expense reports in this status. @JmillsExpensify @garrettmknight thoughts?

[nkdengineer]

Updated proposal

[JmillsExpensify]

Agree on the second option