[Due for payment 2026-06-09] [$250] Expense-Rejected expense moved to original report shows rejected expense violation

[nlemma]

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.2.88-5
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/27754595/test-cases/69505292?q=Reject+
Email or phone of affected tester (no customers): dreamnitethedragon+yydyd373@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redminote 10S Android 13
App Component: Money Requests

Action Performed:

1. Launch app
2. Open workspace chat
3. Create 3 manual expense
4. Open the expense report
5. Tap submit
6. Select 2 expenses and Reject option from dropdown
7. Enter reason and complete the flow
8. Navigate to rejected expense
9. Open the rejected expense
10. Select both expense and select "Move" from dropdown
11. Select the report where expense created
12. Note expense preview shows reject expense violation message
13. Open the expense - More
14. Note Reject option is shown
15. Reject the expense and comple the flow

Expected Result:

Rejected expense moved to original report must not show rejected expense violation

Actual Result:

Rejected expense moved to original report shows rejected expense violation and " Reject" in more option.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7039132_1767086419400.Screenrecorder-2025-12-30-14-49-07-51.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022006649158407191442
• Upwork Job ID: 2006649158407191442
• Last Price Increase: 2026-03-31

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

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

[truph01]

🚨 Edited by proposal-police: This proposal was edited at 2026-02-18 11:06:46 UTC.

Proposal

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

• The “Reject” option is still shown in the More menu for transactions that have already been rejected.

What is the root cause of that problem?

• The function at

  App/src/libs/ReportUtils.ts

  Line 12713 in 6aacf44

  function canRejectReportAction(currentUserLogin: string, report: Report, policy?: Policy): boolean {

  does not check whether the transaction has already been rejected.

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

• We can introduce new 11th param in this function

  App/src/libs/Violations/ViolationsUtils.ts

  Line 287 in c835e8d

  getViolationsOnyxData(

        shouldRemoveRejectedExpenseViolation?: boolean,

then use it in

App/src/libs/Violations/ViolationsUtils.ts

Line 313 in c835e8d

if (iouReport && isFromExpenseReport && isCurrentUserSubmitter(iouReport)) {

as

        // Remove AUTO_REPORTED_REJECTED_EXPENSE violation when the submitter edits the expense or when the transaction is moved to a different report
        if (shouldRemoveRejectedExpenseViolation || (iouReport && isFromExpenseReport && isCurrentUserSubmitter(iouReport))) {

• Finally, in here
  

  App/src/libs/actions/Transaction.ts

  Lines 1027 to 1029 in c835e8d

  	// 2. Calculate transaction violations if moving transaction to a workspace
  	if (isPaidGroupPolicy(policy) && policy?.id) {
  	const violationData = ViolationsUtils.getViolationsOnyxData(

  , pass that 11th param as true.

• This also needs the fix in BE side so that it will always clean up the rejected violation once the transaction is moving to another report.

What alternative solutions did you explore? (Optional)

• In the violation calculation step at

  App/src/libs/actions/Transaction.ts

  Lines 923 to 970 in 6aacf44

  	// 2. Calculate transaction violations if moving transaction to a workspace
  	if (isPaidGroupPolicy(policy) && policy?.id) {
  	const violationData = ViolationsUtils.getViolationsOnyxData(
  	transaction,
  	currentTransactionViolations[transaction.transactionID] ?? [],
  	policy,
  	policyTagList,
  	policyCategories ?? {},
  	policyHasDependentTags,
  	false,
  	);
  	optimisticData.push(violationData);
  	// @ts-expect-error - will be solved in https://github.com/Expensify/App/issues/73830
  	failureData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`,
  	value: allTransactionViolation?.[transaction.transactionID],
  	});
  	const transactionHasViolations = Array.isArray(violationData.value) && violationData.value.length > 0;
  	const hasOtherViolationsBesideDuplicates =
  	Array.isArray(violationData.value) &&
  	!violationData.value.every((violation) => {
  	if (!isViolationWithName(violation)) {
  	return false;
  	}
  	return violation.name === CONST.VIOLATIONS.DUPLICATED_TRANSACTION;
  	});
  	if (transactionHasViolations && hasOtherViolationsBesideDuplicates) {
  	shouldFixViolations = true;
  	}
  	if (policy?.disabledFields?.reimbursable) {
  	transactionReimbursable = policy?.defaultReimbursable;
  	optimisticData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transaction.transactionID}`,
  	value: {
  	reimbursable: transactionReimbursable,
  	},
  	});
  	failureData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transaction.transactionID}`,
  	value: {
  	reimbursable: transaction?.reimbursable,
  	},
  	});
  	}
  	}

  , we could remove all autoReportedRejectedExpense violations associated with the relevant transactionIDs.

• This removal could be done either unconditionally, or conditionally only when the transaction is being moved to a processing (or otherwise non-draft) report.

• The removal logic could be implemented either inside or outside of getViolationsOnyxData.

• The code changes themselves would be relatively simple: use hasTransactionBeenRejected to check whether the transaction has already been rejected, and isProcessingReport to determine whether the target report is in a processing state.

[melvin-bot]

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

[melvin-bot]

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

[garrettmknight]

This is expected behavior, the user hasn't changed any details of the expense or marked the rejection as resolved.

[garrettmknight]

Just checked the linked test case and it doesn't describe this flow, closing.