[$250] Spend - Needs approval filter disappears after approver change

[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: 9.4.15-3
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://github.com/Expensify/Expensify/issues/557436
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows Windows 11 - Chrome

Action Performed:

1. As Admin, create a workspace.
2. Invite Submitter, Approver A, and Approver B.
3. Configure workflow: Approver A approves Submitter’s expenses.
4. As Submitter, submit an expense.
5. Log in as Approver A → observe that the needs approval filter is available in the Expense report section
6. As Admin, change workflow: now Approver B approves Submitter’s expenses.
7. Log in again as Approver A and check Expense report section

Expected Result:

Needs approval filter should remain visible in the Expense reports section, allowing them to filter and approve existing expenses.

Actual Result:

Needs approval filter disappears after approver change

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7164469_1779902127448.needs_approval.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067914058094347586
• Upwork Job ID: 2067914058094347586
• Last Price Increase: 2026-07-03

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Needs approval" filter is the APPROVE suggested search in the Expense reports section. Whether it is shown is decided purely from the current approval-workflow config, not from whether any reports are actually still waiting on the user.

getSuggestedSearchesVisibility computes the flag per policy as isApprovalEnabled && (isUserApprover || isSubmittedTo), where both isUserApprover and isSubmittedTo are derived from the policy's live employeeList / approver (SearchUIUtils.ts:1081-1096). isPolicyApprover only checks policy.approver and submitsTo/forwardsTo/overLimitForwardsTo on the current workflow (PolicyUtils.ts:606-614).

When the admin reroutes the submitter so Approver B becomes the approver, Approver A is instantly no longer in any policy's workflow → isUserApprover and isSubmittedTo both go false → shouldShowApproveSuggestion is false → the menu item is never pushed (SearchUIUtils.ts:4532-4540). This happens even though reports already routed to Approver A still carry them as managerID and remain pending their approval.

Evidence & data flow

• Visibility gate: isEligibleForApproveSuggestion — SearchUIUtils.ts:1034-1037
• Per-policy flags OR'd into shouldShowApproveSuggestion: SearchUIUtils.ts:1110 → returned as visibility[APPROVE] at :1152
• "Is approver" is workflow-config only: isPolicyApprover — PolicyUtils.ts:606-614
• A report-data notion of approver (report.managerID === currentUserAccountID) already exists in ReportUtils, but it only drives per-report Approve/Pay buttons and "requires attention" — it is not consulted for this filter's visibility.
• The APPROVE search query itself is correctly scoped to the user (to: [accountID]) and the tab even defines an emptyApproveResults empty state, so the design already expects the tab to render with zero current results — confirming the disappearance is a bug, not intended gating.

Flow: admin changes approver → Onyx policy.employeeList/approver update → getSuggestedSearchesVisibility recomputes → isUserApprover=false, isSubmittedTo=false → visibility[APPROVE]=false → createTypeMenuSections omits the item.

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

Keep the APPROVE suggestion visible when the user still has reports awaiting their approval, in addition to the existing workflow-config check.

1. In getSuggestedSearchesVisibility / createTypeMenuSections (SearchUIUtils.ts:1045, :4481), additionally compute whether any expense report has the current user as managerID and is in a state that still requires their approval (open/processing, not yet approved/paid).
2. OR that signal into shouldShowApproveSuggestion (line 1110) so the tab stays for as long as there is pending work routed to the user, then naturally drops once those reports are approved/paid.

This matches the expected behavior: a former approver retains the filter only while reports are genuinely still waiting on them, and the existing to: [accountID] query already returns the correct set.

What alternative solutions did you explore? (Optional)

• Show the tab whenever the user has ever been an approver in any approvals-enabled policy — simpler, but leaves the filter visible indefinitely with no pending work.
• Backend keeps the user as a fallback approver after reassignment — out of scope for App and a larger workflow change.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94021) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

When a workspace admin changes the approval workflow so that a different approver (Approver B) now handles a submitter's expenses, the previous approver (Approver A) loses the "Needs approval" filter/tab in the Expense reports section of Search. This happens even though reports that were already routed to Approver A before the change are still assigned to them (managerID still points to A) and still require their approval, leaving A with no way to filter to and act on those reports.

What is the root cause of that problem?

The "Needs approval" entry in the Expense reports section is rendered by createTypeMenuSections in SearchUIUtils.ts, which only pushes the APPROVE menu item when its visibility flag is true:

App/src/libs/SearchUIUtils.ts

Lines 4532 to 4534 in 5b46d9a

	if (suggestedSearchesVisibility[CONST.SEARCH.SEARCH_KEYS.APPROVE]) {
	expenseReportsSection.menuItems.push({
	...suggestedSearches[CONST.SEARCH.SEARCH_KEYS.APPROVE],

That visibility flag is produced by getSuggestedSearchesVisibility, where shouldShowApproveSuggestion is driven entirely by isPolicyEligibleForApproveSuggestion. The eligibility check is computed purely from the current policy workflow config — isUserApprover (isPolicyApprover) and isSubmittedTo (whether any employee's submitsTo/forwardsTo equals the current user):

App/src/libs/SearchUIUtils.ts

Lines 1034 to 1037 in 5b46d9a

	function isEligibleForApproveSuggestion(approvalMode: string | undefined, isApprover: boolean, isSubmittedToTarget: boolean): boolean {
	const isApprovalEnabled = approvalMode ? approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL : false;
	return isApprovalEnabled && (isApprover || isSubmittedToTarget);
	}

const isUserApprover = !!currentUserEmail && isPolicyApprover(policy, currentUserEmail);
const isSubmittedTo = ...employee.submitsTo === currentUserEmail || employee.forwardsTo === currentUserEmail;
const isPolicyEligibleForApproveSuggestion = isPaidPolicy && isEligibleForApproveSuggestion(policy.approvalMode, isUserApprover, isSubmittedTo);

When the admin reassigns the submitter from Approver A to Approver B, the policy's employeeList[submitter].submitsTo is rewritten to B and A is dropped from the policy's approver/forwardsTo entries. After that write, isPolicyApprover(policy, A) and isSubmittedTo both return false for A, so isEligibleForApproveSuggestion returns false and the APPROVE tab is removed. The gating signal is "is the user currently an approver in the workflow," not "does the user have reports currently awaiting their approval." Those diverge precisely in this scenario: the existing expense report keeps managerID = A (a workflow change does not retroactively reassign already-submitted reports), so A still has a real report to approve. This is exactly the report set the app already computes as reportsToApprove in the TODOS derived value via isApproveAction, which keys off report.managerID === currentUserAccountID — independent of the policy membership check that gates the tab.

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

Keep the tab visible whenever the user still has reports awaiting their action, by OR-ing the already-computed TODO counts into the APPROVE/SUBMIT/PAY visibility inside createTypeMenuSections. The reportsToApprove count from ONYXKEYS.DERIVED.TODOS (todosReportCountsSelector) is already read by both SearchTypeMenuWide and SearchTypeMenuNarrow and passed down for the section badge, so it is available at the call site with no new Onyx plumbing — we just thread it into createTypeMenuSections (via TypeMenuSectionsParams) and use it as a fallback. The APPROVE push condition becomes:

if (suggestedSearchesVisibility[CONST.SEARCH.SEARCH_KEYS.APPROVE] || (reportCounts[CONST.SEARCH.SEARCH_KEYS.APPROVE] ?? 0) > 0) {
    expenseReportsSection.menuItems.push({...suggestedSearches[CONST.SEARCH.SEARCH_KEYS.APPROVE], emptyState: {...}});
}

This is safe and minimal: reportsToApprove is already gated by isApproveAction (current-manager, approval-enabled, non-held, processing report), so we only surface the tab when there is a concrete report the user can approve. It does not affect users who never had a report routed to them (count stays 0), and it does not change the badge or query logic. Applying the same fallback to SUBMIT and PAY closes the identical class of bug for "Drafts" and "Ready to pay" when reimburser/forwarding roles are reshuffled.

What alternative solutions did you explore? (Optional)

Broadening isPolicyApprover to also treat anyone listed as a report's managerID as an approver was rejected — getSuggestedSearchesVisibility only receives policies, not reports/transactions, so it cannot see managerID without adding new dependencies, and isPolicyApprover is a widely-used helper whose semantics ("is configured in the workflow") should not be overloaded with "has a stale assignment."

What specific scenarios should we cover in automated/manual tests to prevent this regression?

Unit-test createTypeMenuSections/getSuggestedSearchesVisibility for a user who is not an approver in the current workflow but has reportCounts[APPROVE] > 0, asserting the APPROVE menu item is present; and the inverse (no workflow role, zero count) asserting it is absent. Manual: reproduce the issue steps and confirm Approver A still sees "Needs approval" after the workflow is reassigned to Approver B while a previously-submitted report remains assigned to A, and that the tab disappears once A approves/that report leaves their queue.

[lorretheboy]

Proposal

What is the root cause of that problem?

The "Needs approval" item in the Expense reports section is the APPROVE suggested search. It only renders when getSuggestedSearchesVisibility sets shouldShowApproveSuggestion, which comes from isEligibleForApproveSuggestion:

App/src/libs/SearchUIUtils.ts

Lines 1034 to 1037 in 5b46d9a

	function isEligibleForApproveSuggestion(approvalMode: string | undefined, isApprover: boolean, isSubmittedToTarget: boolean): boolean {
	const isApprovalEnabled = approvalMode ? approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL : false;
	return isApprovalEnabled && (isApprover || isSubmittedToTarget);
	}

Its two relevant inputs, isUserApprover and isSubmittedTo, are derived purely from the policy's current workflow configuration:

App/src/libs/SearchUIUtils.ts

Lines 1081 to 1096 in 5b46d9a

	const isSubmittedTo =
	!!currentUserEmail && Object.values(policy.employeeList ?? {}).some((employee) => employee.submitsTo === currentUserEmail || employee.forwardsTo === currentUserEmail);
	const isUserApprover = !!currentUserEmail && isPolicyApprover(policy, currentUserEmail);
	const isApprovalEnabled = policy.approvalMode ? policy.approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL : false;
	const hasExportError = (Object.keys(policy.connections ?? {}) as ConnectionName[]).some((connection) => {
	return hasSynchronizationErrorMessage(policy, connection, false);
	});
	const isPaymentEnabled = arePaymentsEnabled(policy);
	const hasVBBA = !!policy.achAccount?.bankAccountID && policy.achAccount.state === CONST.BANK_ACCOUNT.STATE.OPEN;
	const hasReimburser = !!policy.achAccount?.reimburser;
	const isECardEnabled = !!policy.areExpensifyCardsEnabled;
	const isEligibleForSubmitSuggestion = isGroupPolicyEligible;
	const isEligibleForPaySuggestion = isPaidPolicy && isPayer;
	const isPolicyEligibleForApproveSuggestion = isPaidPolicy && isEligibleForApproveSuggestion(policy.approvalMode, isUserApprover, isSubmittedTo);

isUserApprover calls isPolicyApprover, which matches only against policy.approver and the live employeeList (submitsTo/forwardsTo/overLimitForwardsTo):

App/src/libs/PolicyUtils.ts

Lines 607 to 614 in 5b46d9a

	function isPolicyApprover(policy: OnyxEntry<Policy>, employeeLogin: string) {
	if (policy?.approver === employeeLogin) {
	return true;
	}
	return Object.values(policy?.employeeList ?? {}).some(
	(employee) => employee?.submitsTo === employeeLogin || employee?.forwardsTo === employeeLogin || employee?.overLimitForwardsTo === employeeLogin,
	);
	}

Causal chain: Admin reassigns the submitter from Approver A to Approver B → Approver A is no longer referenced anywhere in the current workflow config → isUserApprover and isSubmittedTo both become false for Approver A → shouldShowApproveSuggestion is false → the "Needs approval" filter is removed. But reports the Submitter already submitted while Approver A was the approver still sit in Approver A's approval queue, so the filter that lets them act on those reports vanishes even though work remains.

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

Visibility of the Approve suggestion shouldn't depend solely on the live workflow config; it should also account for reports actually awaiting the current user's approval. In getSuggestedSearchesVisibility, additionally mark the Approve suggestion visible when the current user is the manager/approver on at least one open report still pending approval (state/status submitted or processing), regardless of whether they are still in the workflow.

The cleanest convergence point is the eligibility computed here, where we OR in a "has reports awaiting my approval" signal alongside the existing config-based check:

App/src/libs/SearchUIUtils.ts

Lines 1108 to 1119 in 5b46d9a

	shouldShowSubmitSuggestion ||= isEligibleForSubmitSuggestion;
	shouldShowPaySuggestion ||= isEligibleForPaySuggestion;
	shouldShowApproveSuggestion ||= isPolicyEligibleForApproveSuggestion;
	shouldShowExportSuggestion ||= isEligibleForExportSuggestion;
	shouldShowStatementsSuggestion ||= isEligibleForStatementsSuggestion;
	shouldShowUnapprovedCashSuggestion ||= isEligibleForUnapprovedCashSuggestion;
	shouldShowUnapprovedCardSuggestion ||= isEligibleForUnapprovedCardSuggestion;
	shouldShowExpensifyCardSuggestion ||= isEligibleForExpensifyCardSuggestion;
	shouldShowReimbursementsSuggestion ||= isEligibleForReimbursementsSuggestion;
	shouldShowTopSpendersSuggestion ||= isEligibleForTopSpendersSuggestion;
	shouldShowTopCategoriesSuggestion ||= isEligibleForTopCategoriesSuggestion;
	shouldShowTopMerchantsSuggestion ||= isEligibleForTopMerchantsSuggestion;

This keeps the suggestion available to a former approver until their outstanding queue is cleared, and naturally hides it again once those reports are approved or reassigned.

What alternative solutions did you explore? (Optional)

Persist former approvers (e.g. keep prior approver entries until their open reports are resolved) so isPolicyApprover still matches them. This is broader and risks side effects in other approval-driven UI, so the targeted visibility check above is preferable.

[dilshodmackbook-sketch]

Proposal

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

The "Needs approval" suggested search (Approve filter) disappears from the Expense reports section for an approver after the admin reassigns the workflow approver to someone else, even though that approver still has reports actually pending their approval.

What is the root cause of that problem?

The visibility of the Approve suggested search is computed purely from the policy's current approval-workflow configuration, not from whether the user actually has reports awaiting their approval.

In getSuggestedSearchesVisibility, the Approve item is shown only when isPolicyEligibleForApproveSuggestion is true:

App/src/libs/SearchUIUtils.ts

Lines 1081 to 1096 in 7dbf6a5

	const isSubmittedTo =
	!!currentUserEmail && Object.values(policy.employeeList ?? {}).some((employee) => employee.submitsTo === currentUserEmail || employee.forwardsTo === currentUserEmail);
	const isUserApprover = !!currentUserEmail && isPolicyApprover(policy, currentUserEmail);
	const isApprovalEnabled = policy.approvalMode ? policy.approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL : false;
	const hasExportError = (Object.keys(policy.connections ?? {}) as ConnectionName[]).some((connection) => {
	return hasSynchronizationErrorMessage(policy, connection, false);
	});
	const isPaymentEnabled = arePaymentsEnabled(policy);
	const hasVBBA = !!policy.achAccount?.bankAccountID && policy.achAccount.state === CONST.BANK_ACCOUNT.STATE.OPEN;
	const hasReimburser = !!policy.achAccount?.reimburser;
	const isECardEnabled = !!policy.areExpensifyCardsEnabled;
	const isEligibleForSubmitSuggestion = isGroupPolicyEligible;
	const isEligibleForPaySuggestion = isPaidPolicy && isPayer;
	const isPolicyEligibleForApproveSuggestion = isPaidPolicy && isEligibleForApproveSuggestion(policy.approvalMode, isUserApprover, isSubmittedTo);

which is driven by isEligibleForApproveSuggestion → isApprover || isSubmittedToTarget:

App/src/libs/SearchUIUtils.ts

Lines 1034 to 1037 in 7dbf6a5

	function isEligibleForApproveSuggestion(approvalMode: string | undefined, isApprover: boolean, isSubmittedToTarget: boolean): boolean {
	const isApprovalEnabled = approvalMode ? approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL : false;
	return isApprovalEnabled && (isApprover || isSubmittedToTarget);
	}

Both signals come from the static config: isUserApprover is isPolicyApprover(policy, currentUserEmail), which only checks policy.approver and the submitsTo/forwardsTo/overLimitForwardsTo fields of employeeList:

App/src/libs/PolicyUtils.ts

Lines 606 to 613 in 7dbf6a5

	function isPolicyApprover(policy: OnyxEntry<Policy>, employeeLogin: string) {
	if (policy?.approver === employeeLogin) {
	return true;
	}
	return Object.values(policy?.employeeList ?? {}).some(
	(employee) => employee?.submitsTo === employeeLogin || employee?.forwardsTo === employeeLogin || employee?.overLimitForwardsTo === employeeLogin,
	);
	}

and isSubmittedTo similarly scans submitsTo/forwardsTo:

App/src/libs/SearchUIUtils.ts

Lines 1081 to 1083 in 7dbf6a5

	const isSubmittedTo =
	!!currentUserEmail && Object.values(policy.employeeList ?? {}).some((employee) => employee.submitsTo === currentUserEmail || employee.forwardsTo === currentUserEmail);
	const isUserApprover = !!currentUserEmail && isPolicyApprover(policy, currentUserEmail);

When the admin moves the approver from Approver A to Approver B, A is no longer referenced anywhere in the workflow config, so both isUserApprover and isSubmittedTo flip to false and suggestedSearchesVisibility[APPROVE] becomes false, removing the item here:

App/src/libs/SearchUIUtils.ts

Lines 4532 to 4540 in 7dbf6a5

	if (suggestedSearchesVisibility[CONST.SEARCH.SEARCH_KEYS.APPROVE]) {
	expenseReportsSection.menuItems.push({
	...suggestedSearches[CONST.SEARCH.SEARCH_KEYS.APPROVE],
	emptyState: {
	title: 'search.searchResults.emptyApproveResults.title',
	subtitle: 'search.searchResults.emptyApproveResults.subtitle',
	},
	});
	}

But changing the workflow does not retroactively reassign reports that were already submitted to A — those reports keep A as their current approver (managerID), so A still legitimately needs to approve them. The TODOS derived value already captures exactly these reports via isApproveAction (a per-report check based on the report's actual approver, not the config):

App/src/libs/actions/OnyxDerived/configs/todos.ts

Lines 65 to 67 in 7dbf6a5

	if (isApproveAction(report, reportTransactions, currentUserAccountID, reportMetadata, policy) && !allExpensesHeld) {
	reportsToApprove.push(report);
	}

So reportsToApprove is non-empty for A, yet the filter that would let A act on them is hidden.

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

We should keep the Approve suggestion visible whenever the user actually has at least one report awaiting their approval, by OR-ing the actual approve count into the config-based check.

useSearchTypeMenuSections already has the count available pattern (the same ONYXKEYS.DERIVED.TODOS selector is read in SearchTypeMenuWide). We read it in the hook and thread it through createTypeMenuSections into getSuggestedSearchesVisibility:

const [reportCounts = CONST.EMPTY_TODOS_REPORT_COUNTS] = useOnyx(ONYXKEYS.DERIVED.TODOS, {selector: todosReportCountsSelector});

Then in getSuggestedSearchesVisibility, after computing isPolicyEligibleForApproveSuggestion, fold in the real count so the item survives a workflow change while reports are still pending:

const hasReportsAwaitingApproval = (reportCounts?.[CONST.SEARCH.SEARCH_KEYS.APPROVE] ?? 0) > 0;
shouldShowApproveSuggestion ||= isPolicyEligibleForApproveSuggestion || hasReportsAwaitingApproval;

App/src/libs/SearchUIUtils.ts

Lines 1096 to 1110 in 7dbf6a5

	const isPolicyEligibleForApproveSuggestion = isPaidPolicy && isEligibleForApproveSuggestion(policy.approvalMode, isUserApprover, isSubmittedTo);
	const isEligibleForExportSuggestion = isExporter && !hasExportError;
	const isEligibleForStatementsSuggestion = isPaidPolicy && !!policy.areCompanyCardsEnabled && hasCardFeed;
	const isEligibleForUnapprovedCashSuggestion = isPaidPolicy && (isAdmin || isAuditor) && isApprovalEnabled && isPaymentEnabled;
	const isEligibleForUnapprovedCardSuggestion = isPaidPolicy && (isAdmin || isAuditor) && isApprovalEnabled && (hasCardFeed || !!defaultExpensifyCard);
	const isEligibleForExpensifyCardSuggestion = isPaidPolicy && (isAdmin || isAuditor) && isECardEnabled;
	const isEligibleForReimbursementsSuggestion = isPaidPolicy && (isAdmin || isAuditor) && isPaymentEnabled && hasVBBA && hasReimburser;
	const memberCount = Object.keys(policy.employeeList ?? {}).length;
	const isEligibleForTopSpendersSuggestion = isGroupPolicyEligible && (isAdmin || isAuditor || isUserApprover) && memberCount >= 2;
	const isEligibleForTopCategoriesSuggestion = isGroupPolicyEligible && policy.areCategoriesEnabled === true;
	const isEligibleForTopMerchantsSuggestion = isGroupPolicyEligible;
	shouldShowSubmitSuggestion ||= isEligibleForSubmitSuggestion;
	shouldShowPaySuggestion ||= isEligibleForPaySuggestion;
	shouldShowApproveSuggestion ||= isPolicyEligibleForApproveSuggestion;

Note: the approve count is per-user across policies, so we can fold it in once outside the per-policy loop rather than per policy. This reuses the already-derived reportsToApprove (no new data source) and naturally clears the filter once A approves or the reports leave their queue, since the TODOS count drops back to 0.

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

Add a unit test for getSuggestedSearchesVisibility/createTypeMenuSections: given a user who is no longer an approver in the policy config (isPolicyApprover returns false and no submitsTo/forwardsTo references them) but who has reportsToApprove.length > 0, assert visibility[APPROVE] is true; and assert it is false when both the config check fails and the approve count is 0.

What alternative solutions did you explore? (Optional)

Instead of using the TODOS count, we could scan allReports directly inside getSuggestedSearchesVisibility for any expense report whose current approver is the user (e.g. via canApproveIOU, already imported in SearchUIUtils). This is more self-contained but re-derives data the TODOS config already computes, so reusing the existing count is cheaper and keeps a single source of truth for "reports awaiting my approval".

[dostonbunyodov0006]

Proposal

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

After an admin reassigns the approver (Approver A тЖТ Approver B), the "Needs approval" filter vanishes for Approver A in Expense reports тАФ even though reports submitted before the change are still routed to A and still await A's approval. A is left unable to filter or approve the in-flight reports they are still responsible for.

What is the root cause of that problem?

The "Needs approval" filter is shown based on the current workflow configuration, not on whether the user actually has anything to approve. Approver status is resolved by isPolicyApprover:

function isPolicyApprover(policy: OnyxEntry<Policy>, employeeLogin: string) {
    if (policy?.approver === employeeLogin) {
        return true;
    }
    return Object.values(policy?.employeeList ?? {}).some(
        (employee) => employee?.submitsTo === employeeLogin ||
                       employee?.forwardsTo === employeeLogin ||
                       employee?.overLimitForwardsTo === employeeLogin,
    );
}

This reads the live policy.employeeList. When the admin reassigns approval to B, A no longer appears in anyone's submitsTo/forwardsTo chain, so isPolicyApprover(policy, A) becomes false and the filter is hidden.

But approvals already in flight are not retroactively reassigned тАФ the existing reports still have A as their manager/approver and are still in an awaiting-approval state. So the config says "A is not an approver" while the data says "A has reports to approve." The filter trusts the config (a prediction about future routing) instead of the data (what is actually pending now).

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

Derive the filter's visibility from the data it filters, not from the workflow config. Show "Needs approval" exactly when there is at least one report currently awaiting this user's approval тАФ i.e. when the filter would actually return results:

-    const canShowNeedsApprovalFilter = isPolicyApprover(policy, currentUserEmail);
+    // Show the filter when the user actually has something to approve right now,
+    // not when the *current* workflow config lists them as an approver. Approvals
+    // already routed to a user survive a workflow reassignment, so visibility must
+    // come from the reports, not from policy.employeeList.
+    const canShowNeedsApprovalFilter = reports.some(
+        (report) => report?.managerID === currentUserAccountID && isAwaitingApproval(report),
+    );

isAwaitingApproval(report) is the same awaiting-approval predicate the filter itself uses (report is in the submitted/processing state and the current user is its manager). This makes filter visibility and filter results read from one source of truth, so the chip is shown precisely when it is actionable тАФ and hidden only once the user has genuinely cleared every report assigned to them.

Why this is the right direction:

• Self-correcting. No reliance on the config staying consistent with in-flight approvals. The filter appears while there is work and disappears when there is none, regardless of how the workflow is edited afterward.
• Covers the whole class. It also fixes forwarded / over-limit / multi-level approvals and any future routing change тАФ anything that leaves a report pending for a user now keeps that user's filter, because visibility is tied to the report, not the chain config.
• No stale/illegal state. "A filter that returns rows but isn't shown" can't happen, because the same predicate decides both.

What alternative solutions did you explore?

• Keep isPolicyApprover but also OR-in past approver assignments from the workflow history (rejected): requires tracking previous approvers and reconstructing old chains тАФ extra state that drifts, and still config-driven. The data already knows the truth (the report's managerID), so deriving from it is both simpler and complete.

• Always show the filter for anyone who has ever been an approver (rejected): leaves a dead, always-empty filter for users with nothing pending. Tying visibility to actual pending reports keeps the UI honest.

---

Note: isPolicyApprover is verified against PolicyUtils. The filter call site identifiers (canShowNeedsApprovalFilter, the reports collection, and isAwaitingApproval) are illustrative of the existing config-based check тАФ please confirm the exact names/predicate at the "Needs approval" filter's visibility site before submitting.

[melvin-bot]

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

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

[$250] Spend - Needs approval filter disappears after approver change

What is the root cause of that problem?

I traced this to the path that handles expense report:

• src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsExpensesFromPage.tsx:222 (includes): (!policy?.preventSelfApproval || !approversEmail?.includes(member.login)) &&
• src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsExpensesFromPage.tsx:292 (confirmedMembers): const confirmedMembers = stagedMembers.filter((m) => !!policy?.employeeList?.[normalizeLogin(m.email)]);
• src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsExpensesFromPage.tsx:475 (existingApproverEmail): const existingApproverEmail = newMember?.login ? membersInExistingWorkflows.get(newMember.login) : undefined;
• The local evidence matches this recurring failure shape: shared workspace list builds options without the same eligibility filter as another workspace surface. Here, src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsExpensesFromPage.tsx:222 and src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsExpensesFromPage.tsx:292 do not agree on the same expense report value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsExpensesFromPage.tsx:222 to derive expense report from the workspace setup and policy state that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsExpensesFromPage.tsx:292; that follows the safer family move to move the rule into the shared selector/helper, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Workspace, Policy, Categories, Tags, Rules surface and avoid changing account/admin permission surfaces, policy owner/current-user exceptions.

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

1. Add or update a regression in tests/unit/Policy*.ts for the exact issue flow: [$250] Spend - Needs approval filter disappears after approver change.
2. Cover the counter-case near src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsExpensesFromPage.tsx:222 so valid existing expense report behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep expense report consistent at the first read/write boundary shown above.