[HOLD for payment 2025-08-07] [$250] Invoices - Archived invoice report change to original amount when edit second time

[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: v9.1.74-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: n/a
Email or phone of affected tester (no customers): gocemate+b2153614@gmail.com
Issue reported by: Applause Internal Team
Device used: Lenovo 80ES / Windows 10 Pro
App Component: Other

Action Performed:

1. Create workspace> Enable Invoices option
2. Create invoice with $20
3. Change the invoice amount to $21
4. Delete the workspace
5. Go to archived invoice report> Change the amount to $22
6. Dismiss the error

Expected Result:

Invoice amount should remain to the edited amount ($21) before workspace delete

Actual Result:

Invoice amount switch to the originally added amount ($20) before edit steps

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• 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/~021940488817860792996
• Upwork Job ID: 1940488817860792996
• Last Price Increase: 2025-07-16
• Automatic offers:
• FitseTLT | Contributor | 108137929

Issue Owner

Current Issue Owner: @Gonals

[melvin-bot]

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

Invoices - Archived invoice report change to original amount when edit second time

What is the root cause of that problem?

The only archived reports we can edit is expense reports and we already disallowing editing archived non-expense reports here

App/src/libs/ReportUtils.ts

Lines 8872 to 8874 in 39f3cf4

	const reportNameValuePairs = getReportNameValuePairs(report?.reportID);
	return (
	!isArchivedNonExpenseReport(report, !!reportNameValuePairs?.private_isArchived) &&

but the problem is the BE only populates reportNameValuePairs of the invoice room with privateIsArchived not the the invoice report or invoice transactionThreadReport so the codition in the above doesn't prevent editing because it depends on the transactionThreadReport of the invoice report

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 197 to 198 in 39f3cf4

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

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

For invoices can fallback to the invoice room's (which the parent report of the invoice report) reportNameValuePairs to calculate if it is archived

App/src/libs/ReportUtils.ts

Line 8872 in 39f3cf4

const reportNameValuePairs = getReportNameValuePairs(report?.reportID);

 const reportNameValuePairs =
        getReportNameValuePairs(report?.reportID) ??
        (isOneTransactionReport(report) && isInvoiceReport(getParentReport(report)) ? getReportNameValuePairs(getParentReport(report)?.parentReportID) : undefined);
   
    

But if we also want to prevent adding comment in archived invoice report we will need to implement similarly if a report is invoiceReport getReportNameValuePairs of the parent report(which would be the invoice room) but currently the BE doesn't disallow commenting on archived invoice report.
Or we can put the logic in canEditMoneyRequest if we don't want to affect other logics affected by canUserPerformWriteAction.

App/src/libs/ReportUtils.ts

Lines 4070 to 4072 in 39f3cf4

	if (isInvoiceReport(moneyRequestReport) && isManager) {
	return false;
	}

if (isInvoiceReport(moneyRequestReport) && (isManager || isArchivedReport(getReportNameValuePairs(moneyRequestReport?.chatReportID)))) {
        return false;
    }

I used isArchivedReport for demo we will use the proper flow of passing isArchived as a param as the above approach is not a recommended pattern and we are avoiding it.
Alternative solution is to archive invoice reports and invoice transactionThreadReports reportNameValuePairs when a workspace is deleted so in the FE we will need to include invoice reports and transactionThreadReports (as needed, maybe only the transaction thread becuase now the BE allows commenting on the invoice reports) into reportsTobeArchived here

App/src/libs/actions/Policy/Policy.ts

Lines 377 to 378 in 39f3cf4

	const reportsToArchive = Object.values(allReports ?? {}).filter(
	(report) => ReportUtils.isPolicyRelatedReport(report, policyID) && (ReportUtils.isChatRoom(report) || ReportUtils.isPolicyExpenseChat(report) || ReportUtils.isTaskReport(report)),

 ReportUtils.isInvoiceReport(report) ||
                (isOneTransactionReport(report) &&ReportUtils.isInvoiceReport(ReportUtils.getParentReport(report))) ||
               

then we will need to update the BE similarly to archive on the linked reports.

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

We can test canUserPerformWriteAction returns false for invoice transaction threads of an archived invoice room.

What alternative solutions did you explore? (Optional)

[dmkt9]

Proposal

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

Archived invoice report change to original amount when edit second time

What is the root cause of that problem?

• When changing the amount failed, the transaction's amount is reverted here:
  

  App/src/components/ReportActionItem/MoneyRequestView.tsx

  Line 543 in 2a8b75d

  revert(transaction?.transactionID ?? linkedTransactionID, getLastModifiedExpense(report?.reportID));

• The getLastModifiedExpense(report?.reportID) function retrieves the originalMessage of the most recent MODIFIEDEXPENSE action, regardless of whether it succeeded or failed.
  

  App/src/libs/actions/Transaction.ts

  Lines 499 to 503 in 2a8b75d

  	function getLastModifiedExpense(reportID?: string): OriginalMessageModifiedExpense | undefined {
  	const modifiedExpenseActions = Object.values(getAllReportActions(reportID)).filter(isModifiedExpenseAction);
  	modifiedExpenseActions.sort((a, b) => Number(a.reportActionID) - Number(b.reportActionID));
  	return getOriginalMessage(modifiedExpenseActions.at(-1));
  	}

• The revert function then uses oldAmount and oldCurrency to reset the modifiedAmount and modifiedCurrency of the transaction.
  

  App/src/libs/actions/Transaction.ts

  Lines 509 to 518 in 2a8b75d

  	Onyx.merge(`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {
  	modifiedAmount: transaction?.amount && transaction?.amount < 0 ? -Math.abs(originalMessage.oldAmount) : originalMessage.oldAmount,
  	modifiedCurrency: originalMessage.oldCurrency,
  	});
  	}
  	}
  	function markAsCash(transactionID: string | undefined, transactionThreadReportID: string | undefined) {
  	if (!transactionID || !transactionThreadReportID) {
  	return;

  • This leads to a potential issue: if the user dismisses the comment error first, the failed MODIFIEDEXPENSE action is removed from the data. As a result, getLastModifiedExpense returns the most recent successful MODIFIEDEXPENSE action, which causes the current bug.

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

Refactor the getLastModifiedExpense and revert helpers:

1. getLastModifiedExpense: Ensure it only returns the most recent successful MODIFIEDEXPENSE action.
   

   App/src/libs/actions/Transaction.ts

   Line 500 in 2a8b75d

   const modifiedExpenseActions = Object.values(getAllReportActions(reportID)).filter(isModifiedExpenseAction);

const modifiedExpenseActions = Object.values(getAllReportActions(reportID)).filter((action) => isModifiedExpenseAction(action) && !action.pendingAction);

2. revert: Since the latest successful action's originalMessage is used, the values to revert should come from the amount and currency fields of that originalMessage.
   

   App/src/libs/actions/Transaction.ts

   Lines 505 to 514 in 2a8b75d

   	function revert(transactionID?: string, originalMessage?: OriginalMessageModifiedExpense | undefined) {
   	const transaction = allTransactions?.[`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`] ?? ({} as Transaction);
   	if (transaction && originalMessage?.oldAmount && originalMessage.oldCurrency && 'amount' in originalMessage && 'currency' in originalMessage) {
   	Onyx.merge(`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {
   	modifiedAmount: transaction?.amount && transaction?.amount < 0 ? -Math.abs(originalMessage.oldAmount) : originalMessage.oldAmount,
   	modifiedCurrency: originalMessage.oldCurrency,
   	});
   	}
   	}

function revert(transactionID?: string, originalMessage?: OriginalMessageModifiedExpense | undefined) {
    const transaction = allTransactions?.[`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`] ?? ({} as Transaction);

    if (transaction && originalMessage && 'amount' in originalMessage && 'currency' in originalMessage && originalMessage?.amount && originalMessage.currency) {
        Onyx.merge(`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {
            modifiedAmount: transaction?.amount && transaction?.amount < 0 ? -Math.abs(originalMessage.amount) : originalMessage.amount,
            modifiedCurrency: originalMessage.currency,
        });
    }
}

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

NA

What alternative solutions did you explore? (Optional)

1. Option 1:
   Remove the revert function here, since after a failure, the data will already be reverted using the failureData from the Onyx API response.

2. Option 2: Refactor the revert function to no longer rely on the originalMessage passed via parameters. Instead, it should accept a reportID and internally filter for the appropriate MODIFIEDEXPENSE action—effectively combining the logic of both getLastModifiedExpense and revert for more flexible and accurate data retrieval.

function revert(transactionID?: string, reportID?: string) {
    const transaction = allTransactions?.[`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`] ?? ({} as Transaction);
    if (!transaction) {
        return;
    }
    const modifiedExpenseActions = Object.values(getAllReportActions(reportID)).filter(isModifiedExpenseAction);
    modifiedExpenseActions.sort((a, b) => Number(a.reportActionID) - Number(b.reportActionID));
    const latestModifiedExpenseActions = modifiedExpenseActions.at(-1);
    const originalMessage = getOriginalMessage(latestModifiedExpenseActions);
    const isReportActionPending = !!latestModifiedExpenseActions?.pendingAction;

    if (originalMessage?.oldAmount && originalMessage.oldCurrency && 'amount' in originalMessage && 'currency' in originalMessage) {
        const revertedAmount = (isReportActionPending ? originalMessage?.oldAmount : originalMessage?.amount) ?? transaction.amount;
        const revertedCurrency = (isReportActionPending ? originalMessage?.oldCurrency : originalMessage?.currency) ?? transaction.currency;
        Onyx.merge(`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {
            modifiedAmount: transaction.amount < 0 ? -Math.abs(revertedAmount) : revertedAmount,
            modifiedCurrency: revertedCurrency,
        });
    }
}

3. Option 3: Disable editing if the report is archived

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.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@alitoshmatov Eep! 4 days overdue now. Issues have feelings too...