Expense - Itemized violation is cleared only after opening the expense.

[jponikarchuk]

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.3.11-17
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #78410
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: User Settings

Action Performed:

1. Launch app
2. Create a workspace
3. Tap more features and enable rules
4. Create a manual expense with amount greater than ₹75 without category
5. Open the expense and note itemized violation is shown
6. Go to reports - expense and note itemized violation is displayed
7. Go to workspace settings and downgrade to collect workspace
8. Go to reports - expense and note itemized violation is still displayed
9. Go to inbox and open the expense
10. Go back to report and note violation is cleared

Expected Result:

Itemized violation must be auto cleared without opening the expense.

Actual Result:

Itemized violation is cleared only after opening the expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

[daledah]

Proposal

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

Itemized violation must be auto cleared without opening the expense when downgrading workspace from Control to Collect/Team.

What is the root cause of that problem?

When downgradeToTeam function is called, it only updates the policy type to TEAM but does not recalculate the violations for transactions in that workspace.

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

Lines 5095 to 5136 in e8e0bf3

	function downgradeToTeam(policyID: string) {
	// This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	const policy = getPolicy(policyID);
	const optimisticData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `policy_${policyID}`,
	value: {
	isPendingDowngrade: true,
	type: CONST.POLICY.TYPE.TEAM,
	isAttendeeTrackingEnabled: null,
	},
	},
	];
	const successData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `policy_${policyID}`,
	value: {
	isPendingDowngrade: false,
	},
	},
	];
	const failureData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `policy_${policyID}`,
	value: {
	isPendingDowngrade: false,
	type: policy?.type,
	isAttendeeTrackingEnabled: policy?.isAttendeeTrackingEnabled,
	},
	},
	];
	const parameters: DowngradeToTeamParams = {policyID};
	API.write(WRITE_COMMANDS.DOWNGRADE_TO_TEAM, parameters, {optimisticData, successData, failureData});
	}

The itemized receipt required violation (CONST.VIOLATIONS.ITEMIZED_RECEIPT_REQUIRED) is only applicable for Control policies (checked via isControlPolicy in ViolationsUtils.getViolationsOnyxData). When downgrading, the policy type changes but violations are not recalculated, so stale violations remain until the user opens the expense (which triggers the server to return updated violations).

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

We should use pushTransactionViolationsOnyxData in downgradeToTeam function to recalculate violations for all transactions in the workspace with the updated policy type. This is the same pattern used in other policy actions like enablePolicyTags, setPolicyRequiresTag, deleteWorkspaceCategories, etc.

--- a/src/libs/actions/Policy/Policy.ts
+++ b/src/libs/actions/Policy/Policy.ts
@@ -5095,6 +5095,10 @@ function downgradeToTeam(policyID: string) {
     // This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
     // eslint-disable-next-line @typescript-eslint/no-deprecated
     const policy = getPolicy(policyID);
+    const policyData = getPolicyDataForPushTransactionViolations(policyID);
+    if (!policyData) {
+        return;
+    }
     const optimisticData: OnyxUpdate[] = [
         {
             onyxMethod: Onyx.METHOD.MERGE,
@@ -5130,6 +5134,13 @@ function downgradeToTeam(policyID: string) {
         },
     ];

+    const onyxData = {optimisticData, successData, failureData};
+
+    pushTransactionViolationsOnyxData(onyxData, policyData, {
+        type: CONST.POLICY.TYPE.TEAM,
+        isAttendeeTrackingEnabled: null,
+    });
+
     const parameters: DowngradeToTeamParams = {policyID};

     API.write(WRITE_COMMANDS.DOWNGRADE_TO_TEAM, parameters, {optimisticData, successData, failureData});

What alternative solutions did you explore? (Optional)

1. Clear all violations when downgrading - This would be too aggressive as some violations may still be valid on Team workspaces.
2. Add a specific cleanup for itemized receipt violations only - This would be less maintainable as we'd need to add more cleanup logic for each Control-only violation type.

[annaweber830]

Proposal

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

When a workspace is downgraded from Control to Collect/Team, Control-only expense violations (like the itemized receipt required violation) should clear automatically in the report UI, without requiring the user to open the expense to refresh it.

What is the root cause of that problem?

downgradeToTeam() optimistically updates the policy type to TEAM, but it does not recalculate / push updated transaction violations to Onyx for the transactions in that workspace, so the UI keeps showing stale TRANSACTION_VIOLATIONS until some other flow (opening the expense) triggers a refresh/recalculation.

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

Lines 5095 to 5136 in 9618ba6

	function downgradeToTeam(policyID: string) {
	// This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	const policy = getPolicy(policyID);
	const optimisticData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `policy_${policyID}`,
	value: {
	isPendingDowngrade: true,
	type: CONST.POLICY.TYPE.TEAM,
	isAttendeeTrackingEnabled: null,
	},
	},
	];
	const successData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `policy_${policyID}`,
	value: {
	isPendingDowngrade: false,
	},
	},
	];
	const failureData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `policy_${policyID}`,
	value: {
	isPendingDowngrade: false,
	type: policy?.type,
	isAttendeeTrackingEnabled: policy?.isAttendeeTrackingEnabled,
	},
	},
	];
	const parameters: DowngradeToTeamParams = {policyID};
	API.write(WRITE_COMMANDS.DOWNGRADE_TO_TEAM, parameters, {optimisticData, successData, failureData});
	}

This becomes user-visible because the itemized receipt required violation is calculated client-side only for Control workspaces (policy type CORPORATE). After downgrade, the policy becomes TEAM, so the violation is no longer eligible, but the stored violations aren’t recomputed until later.

App/src/libs/Violations/ViolationsUtils.ts

Lines 384 to 522 in 9618ba6

	const isControlPolicy = policy.type === CONST.POLICY.TYPE.CORPORATE;
	const inputDate = new Date(updatedTransaction.modifiedCreated ?? updatedTransaction.created);
	const shouldDisplayFutureDateViolation = !isInvoiceTransaction && DateUtils.isFutureDay(inputDate) && isControlPolicy;
	const hasReceiptRequiredViolation = transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.RECEIPT_REQUIRED && violation.data);
	const hasCategoryReceiptRequiredViolation = transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.RECEIPT_REQUIRED && !violation.data);
	const hasItemizedReceiptRequiredViolation = transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.ITEMIZED_RECEIPT_REQUIRED);
	const hasOverLimitViolation = transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.OVER_LIMIT);
	// TODO: Uncomment when the OVER_TRIP_LIMIT violation is implemented
	// const hasOverTripLimitViolation = transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.OVER_TRIP_LIMIT);
	const hasCategoryOverLimitViolation = transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.OVER_CATEGORY_LIMIT);
	const hasMissingCommentViolation = transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.MISSING_COMMENT);
	const hasMissingAttendeesViolation = transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.MISSING_ATTENDEES);
	const hasTaxOutOfPolicyViolation = transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.TAX_OUT_OF_POLICY);
	const isDistanceRequest = TransactionUtils.isDistanceRequest(updatedTransaction);
	const isPerDiemRequest = TransactionUtils.isPerDiemRequest(updatedTransaction);
	const isTimeRequest = TransactionUtils.isTimeRequest(updatedTransaction);
	const isPolicyTrackTaxEnabled = isTaxTrackingEnabled(true, policy, isDistanceRequest, isPerDiemRequest, isTimeRequest);
	const isTaxInPolicy = Object.keys(policy.taxRates?.taxes ?? {}).some((key) => key === updatedTransaction.taxCode);
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const amount = hasValidModifiedAmount(updatedTransaction) ? Number(updatedTransaction.modifiedAmount) : updatedTransaction.amount;
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	const currency = updatedTransaction.modifiedCurrency || updatedTransaction.currency;
	const canCalculateAmountViolations = policy.outputCurrency === currency;
	const categoryName = updatedTransaction.category;
	const categoryMaxAmountNoReceipt = policyCategories[categoryName ?? '']?.maxAmountNoReceipt;
	const categoryMaxAmountNoItemizedReceipt = policyCategories[categoryName ?? '']?.maxAmountNoItemizedReceipt;
	const maxAmountNoReceipt = policy.maxExpenseAmountNoReceipt;
	const maxAmountNoItemizedReceipt = policy.maxExpenseAmountNoItemizedReceipt;
	// Amount is stored with opposite sign (negative for expenses), so we negate it to get the actual expense amount
	const expenseAmount = -amount;
	// The category maxExpenseAmountNoReceipt and maxExpenseAmount settings override the respective policy settings.
	const shouldShowReceiptRequiredViolation =
	canCalculateAmountViolations &&
	!isInvoiceTransaction &&
	typeof categoryMaxAmountNoReceipt !== 'number' &&
	typeof maxAmountNoReceipt === 'number' &&
	expenseAmount > maxAmountNoReceipt &&
	!TransactionUtils.hasReceipt(updatedTransaction) &&
	isControlPolicy;
	const shouldShowCategoryReceiptRequiredViolation =
	canCalculateAmountViolations &&
	!isInvoiceTransaction &&
	typeof categoryMaxAmountNoReceipt === 'number' &&
	expenseAmount > categoryMaxAmountNoReceipt &&
	!TransactionUtils.hasReceipt(updatedTransaction) &&
	isControlPolicy;
	const isEligibleForItemizedReceiptViolation = canCalculateAmountViolations && !isInvoiceTransaction && !TransactionUtils.hasReceipt(updatedTransaction) && isControlPolicy;
	// Check for itemized receipt requirement - policy level
	const shouldShowItemizedReceiptRequiredViolation =
	isEligibleForItemizedReceiptViolation &&
	typeof categoryMaxAmountNoItemizedReceipt !== 'number' &&
	typeof maxAmountNoItemizedReceipt === 'number' &&
	expenseAmount > maxAmountNoItemizedReceipt;
	// Check for itemized receipt requirement - category level override
	const shouldShowCategoryItemizedReceiptRequiredViolation =
	isEligibleForItemizedReceiptViolation && typeof categoryMaxAmountNoItemizedReceipt === 'number' && expenseAmount > categoryMaxAmountNoItemizedReceipt;
	const overLimitAmount = policy.maxExpenseAmount;
	const categoryOverLimit = policyCategories[categoryName ?? '']?.maxExpenseAmount;
	const shouldShowOverLimitViolation =
	canCalculateAmountViolations &&
	!isInvoiceTransaction &&
	typeof categoryOverLimit !== 'number' &&
	typeof overLimitAmount === 'number' &&
	expenseAmount > overLimitAmount &&
	isControlPolicy;
	const shouldCategoryShowOverLimitViolation =
	canCalculateAmountViolations && !isInvoiceTransaction && typeof categoryOverLimit === 'number' && expenseAmount > categoryOverLimit && isControlPolicy;
	const shouldShowMissingComment = !isInvoiceTransaction && policyCategories?.[categoryName ?? '']?.areCommentsRequired && !updatedTransaction.comment?.comment && isControlPolicy;
	const attendees = updatedTransaction.modifiedAttendees ?? updatedTransaction.comment?.attendees ?? [];
	const isAttendeeTrackingEnabled = policy.isAttendeeTrackingEnabled ?? false;
	// Filter out the owner/creator when checking attendance count - expense is valid if at least one non-owner attendee is present
	const ownerAccountID = iouReport?.ownerAccountID;
	// Calculate attendees minus owner. When ownerAccountID is known, filter by accountID.
	// When ownerAccountID is undefined (offline split where iouReport is unavailable),
	// fallback to using login/email to identify the owner (similar to AttendeeUtils approach).
	let attendeesMinusOwnerCount: number;
	if (ownerAccountID !== undefined) {
	// Normal case: filter by accountID
	attendeesMinusOwnerCount = attendees.filter((a) => a?.accountID !== ownerAccountID).length;
	} else {
	// Offline scenario: ownerAccountID unavailable, use login/email as fallback
	const currentUserEmail = getCurrentUserEmail();
	if (currentUserEmail) {
	// Filter by login or email to identify owner
	attendeesMinusOwnerCount = attendees.filter((a) => {
	const attendeeIdentifier = a?.login ?? a?.email;
	return attendeeIdentifier !== currentUserEmail;
	}).length;
	} else {
	// Can't identify owner at all - if there are attendees, assume owner is one of them
	// This means we need at least 2 attendees to have a non-owner attendee
	attendeesMinusOwnerCount = Math.max(0, attendees.length - 1);
	}
	}
	const shouldShowMissingAttendees =
	!isInvoiceTransaction &&
	isAttendeeTrackingEnabled &&
	!!policyCategories?.[categoryName ?? '']?.areAttendeesRequired &&
	isControlPolicy &&
	(attendees.length === 0 || attendeesMinusOwnerCount === 0);
	const hasFutureDateViolation = transactionViolations.some((violation) => violation.name === 'futureDate');
	// Add 'futureDate' violation if transaction date is in the future and policy type is corporate
	if (!hasFutureDateViolation && shouldDisplayFutureDateViolation) {
	newTransactionViolations.push({name: CONST.VIOLATIONS.FUTURE_DATE, type: CONST.VIOLATION_TYPES.VIOLATION, showInReview: true});
	}
	// Remove 'futureDate' violation if transaction date is not in the future
	if (hasFutureDateViolation && !shouldDisplayFutureDateViolation) {
	newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.FUTURE_DATE});
	}
	// Remove itemized receipt required violation if conditions are no longer met
	if (canCalculateAmountViolations && hasItemizedReceiptRequiredViolation && !shouldShowItemizedReceiptRequiredViolation && !shouldShowCategoryItemizedReceiptRequiredViolation) {
	newTransactionViolations = reject(newTransactionViolations, {name: CONST.VIOLATIONS.ITEMIZED_RECEIPT_REQUIRED});
	}
	// Add itemized receipt required violation if conditions are met (policy or category level)
	if (canCalculateAmountViolations && !hasItemizedReceiptRequiredViolation && (shouldShowItemizedReceiptRequiredViolation || shouldShowCategoryItemizedReceiptRequiredViolation)) {
	newTransactionViolations.push({
	name: CONST.VIOLATIONS.ITEMIZED_RECEIPT_REQUIRED,
	data:
	shouldShowCategoryItemizedReceiptRequiredViolation || !policy.maxExpenseAmountNoItemizedReceipt
	? undefined
	: {
	formattedLimit: CurrencyUtils.convertToDisplayString(policy.maxExpenseAmountNoItemizedReceipt, policy.outputCurrency, true),
	},
	type: CONST.VIOLATION_TYPES.VIOLATION,
	showInReview: true,
	});
	}

The existing pattern for updating violations when policy settings change is pushTransactionViolationsOnyxData(), which recalculates violations for all transactions in the policy’s reports and updates ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS optimistically.

App/src/libs/ReportUtils.ts

Lines 2065 to 2184 in 9618ba6

	function pushTransactionViolationsOnyxData(
	onyxData: OnyxData<
	typeof ONYXKEYS.COLLECTION.POLICY_CATEGORIES | typeof ONYXKEYS.COLLECTION.POLICY | typeof ONYXKEYS.COLLECTION.POLICY_TAGS | typeof ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS
	>,
	policyData: PolicyData,
	policyUpdate: Partial<Policy> = {},
	categoriesUpdate: Record<string, Partial<PolicyCategory>> = {},
	tagListsUpdate: Record<string, Partial<PolicyTagList>> = {},
	) {
	const nonInvoiceReportTransactionsAndViolations = policyData.reports.reduce<ReportTransactionsAndViolations[]>((acc, report) => {
	// Skipping invoice reports since they should not have any category or tag violations
	if (isInvoiceReport(report)) {
	return acc;
	}
	const reportTransactionsAndViolations = policyData.transactionsAndViolations[report.reportID];
	if (!isEmptyObject(reportTransactionsAndViolations) && !isEmptyObject(reportTransactionsAndViolations.transactions)) {
	acc.push(reportTransactionsAndViolations);
	}
	return acc;
	}, []);
	if (nonInvoiceReportTransactionsAndViolations.length === 0) {
	return;
	}
	const updatedTagListsNames = Object.keys(tagListsUpdate);
	const updatedCategoriesNames = Object.keys(categoriesUpdate);
	// If there are no updates to policy, categories or tags, return early
	const isPolicyUpdateEmpty = isEmptyObject(policyUpdate);
	const isTagListsUpdateEmpty = updatedTagListsNames.length === 0;
	const isCategoriesUpdateEmpty = updatedCategoriesNames.length === 0;
	if (isPolicyUpdateEmpty && isTagListsUpdateEmpty && isCategoriesUpdateEmpty) {
	return;
	}
	// Merge the existing policy with the optimistic updates
	const optimisticPolicy = isPolicyUpdateEmpty ? policyData.policy : {...policyData.policy, ...policyUpdate};
	// Merge the existing categories with the optimistic updates
	const optimisticCategories = isCategoriesUpdateEmpty
	? policyData.categories
	: {
	...Object.fromEntries(Object.entries(policyData.categories).filter(([categoryName]) => !(categoryName in categoriesUpdate) || !!categoriesUpdate[categoryName])),
	...Object.entries(categoriesUpdate).reduce<PolicyCategories>((acc, [categoryName, categoryUpdate]) => {
	if (!categoryUpdate) {
	return acc;
	}
	acc[categoryName] = {
	...(policyData.categories?.[categoryName] ?? {}),
	...categoryUpdate,
	};
	return acc;
	}, {}),
	};
	// Merge the existing tag lists with the optimistic updates
	const optimisticTagLists = isTagListsUpdateEmpty
	? policyData.tags
	: {
	...Object.fromEntries(Object.entries(policyData.tags ?? {}).filter(([tagListName]) => !(tagListName in tagListsUpdate) || !!tagListsUpdate[tagListName])),
	...Object.entries(tagListsUpdate).reduce<PolicyTagLists>((acc, [tagListName, tagListUpdate]) => {
	if (!tagListUpdate) {
	return acc;
	}
	const tagList = policyData.tags?.[tagListName];
	const tags = tagList?.tags ?? {};
	const tagsUpdate = tagListUpdate?.tags ?? {};
	acc[tagListName] = {
	...tagList,
	...tagListUpdate,
	tags: {
	...((): PolicyTags => {
	const optimisticTags: PolicyTags = Object.fromEntries(Object.entries(tags).filter(([tagName]) => !(tagName in tagsUpdate) || !!tagsUpdate[tagName]));
	for (const [tagName, tagUpdate] of Object.entries(tagsUpdate)) {
	if (!tagUpdate) {
	continue;
	}
	optimisticTags[tagName] = {
	...(tags[tagName] ?? {}),
	...tagUpdate,
	};
	}
	return optimisticTags;
	})(),
	},
	};
	return acc;
	}, {}),
	};
	const hasDependentTags = hasDependentTagsPolicyUtils(optimisticPolicy, optimisticTagLists);
	// Iterate through all policy reports to find transactions that need optimistic violations
	for (const {transactions, violations} of nonInvoiceReportTransactionsAndViolations) {
	for (const transaction of Object.values(transactions)) {
	const existingViolations = violations[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`];
	const optimisticViolations = ViolationsUtils.getViolationsOnyxData(
	transaction,
	existingViolations ?? [],
	optimisticPolicy,
	optimisticTagLists,
	optimisticCategories,
	hasDependentTags,
	false,
	);
	if (!isEmptyObject(optimisticViolations)) {
	onyxData.optimisticData?.push(optimisticViolations);
	onyxData.failureData?.push({
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`,
	value: existingViolations ?? null,
	});
	}
	}
	}
	}

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

Update the downgrade flow to follow the same “policy change → push updated optimistic violations” pattern used by other workspace rule actions:

• Change downgradeToTeam() to accept policyData (from usePolicyData) so it has access to the policy’s reports + transactions/violations.
• Create an onyxData object and call ReportUtils.pushTransactionViolationsOnyxData() with a policyUpdate of {type: CONST.POLICY.TYPE.TEAM, isAttendeeTrackingEnabled: null} before calling API.write(...).
• Update WorkspaceDowngradePage to call usePolicyData(policyID) and pass that to downgradeToTeam(...) instead of only passing policy.id.

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

Lines 5095 to 5136 in 9618ba6

	function downgradeToTeam(policyID: string) {
	// This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	const policy = getPolicy(policyID);
	const optimisticData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `policy_${policyID}`,
	value: {
	isPendingDowngrade: true,
	type: CONST.POLICY.TYPE.TEAM,
	isAttendeeTrackingEnabled: null,
	},
	},
	];
	const successData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `policy_${policyID}`,
	value: {
	isPendingDowngrade: false,
	},
	},
	];
	const failureData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `policy_${policyID}`,
	value: {
	isPendingDowngrade: false,
	type: policy?.type,
	isAttendeeTrackingEnabled: policy?.isAttendeeTrackingEnabled,
	},
	},
	];
	const parameters: DowngradeToTeamParams = {policyID};
	API.write(WRITE_COMMANDS.DOWNGRADE_TO_TEAM, parameters, {optimisticData, successData, failureData});
	}

function downgradeToTeam(policyData: PolicyData) {
    const policyID = policyData.policy?.id;
    if (!policyID) {
        return;
    }

    const optimisticData: OnyxUpdate[] = [
        {
            onyxMethod: Onyx.METHOD.MERGE,
            key: `policy_${policyID}`,
            value: {
                isPendingDowngrade: true,
                type: CONST.POLICY.TYPE.TEAM,
                isAttendeeTrackingEnabled: null,
            },
        },
    ];

    const successData: OnyxUpdate[] = [
        {
            onyxMethod: Onyx.METHOD.MERGE,
            key: `policy_${policyID}`,
            value: {
                isPendingDowngrade: false,
            },
        },
    ];

    const failureData: OnyxUpdate[] = [
        {
            onyxMethod: Onyx.METHOD.MERGE,
            key: `policy_${policyID}`,
            value: {
                isPendingDowngrade: false,
                type: policyData.policy?.type,
                isAttendeeTrackingEnabled: policyData.policy?.isAttendeeTrackingEnabled,
            },
        },
    ];

    const onyxData: OnyxData<typeof ONYXKEYS.COLLECTION.POLICY> = {optimisticData, successData, failureData};
    ReportUtils.pushTransactionViolationsOnyxData(onyxData, policyData, {type: CONST.POLICY.TYPE.TEAM, isAttendeeTrackingEnabled: null});

    const parameters: DowngradeToTeamParams = {policyID};
    API.write(WRITE_COMMANDS.DOWNGRADE_TO_TEAM, parameters, onyxData);
}

What alternative solutions did you explore? (Optional)

• Clear CONST.VIOLATIONS.ITEMIZED_RECEIPT_REQUIRED directly in TRANSACTION_VIOLATIONS on downgrade. This is narrower but risks missing other Control-only violations that also become invalid on downgrade, and duplicates logic already encapsulated in pushTransactionViolationsOnyxData().
• Trigger a global “recompute violations on policy type change” listener. This would be more automatic, but it’s a larger behavioral change than updating the single downgrade action to follow existing patterns.