[Due for payment 2025-11-17] [$250] Tag Rules - Approver is not reflected when select and unselect user

[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.2.41-2
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/test-runs/TR-1594/folder/13176707/41236898/983218028
Email or phone of affected tester (no customers): kiatest.78+ck103025@gmail.com
Issue reported by: Applause Internal Team
Device used: Windows 11/Chrome, iPhone 16/iOS 18.3.1
App Component: Other

Action Performed:

Precondition:

1. User is a admin of a control workspace that has enabled rules, tags & approvals in workflows
2. Admin has invited few members to WS
3. Admin has added tags

Steps:

1. Navigate to staging.new.expensify.com
2. Navigate to workspace settings >> Tags
3. Select the added tag
4. Select approver field in tag rules
5. Select any user
6. Observe selected user is not reflected in Approver field
7. Select the approver field again & observe green checkmark displayed
8. Click back button twice
9. Select tag & observe the selected approver is now displayed
10. Unselect the user & observe user not removed below approver field

Expected Result:

On step 6 & 10 - Selected user should correctly reflected below Approver field when select & unselect users

Actual Result:

On step 6 & 10 - Selected user not reflected below Approver field when select & unselect users. Blank field is first displayed on selecting approver. Approver shown correctly only after user navigated back to tags page & revisit tag rules

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/~021984274809668811826
• Upwork Job ID: 1984274809668811826
• Last Price Increase: 2025-10-31

Issue Owner

Current Issue Owner: @NicMendonca

[melvin-bot]

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

[Nodebrute]

Proposal

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

Approver is not reflected when select and unselect user

What is the root cause of that problem?

When we come back to the tag settings page after selecting the approver, these values are undefined initially. But when we do get the data, it does not force a re-render. That's why the approver field remains empty and only gets filled once the component unmounts and mounts again.

App/src/pages/workspace/tags/TagSettingsPage.tsx

Lines 57 to 59 in 3be2823

	const tagApprover = getTagApproverRule(policyID, route.params?.tagName)?.approver ?? '';
	const approver = getPersonalDetailByEmail(tagApprover);
	const approverText = approver?.displayName ?? tagApprover;

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

We should change this

App/src/pages/workspace/tags/TagSettingsPage.tsx

Lines 57 to 59 in 3be2823

	const tagApprover = getTagApproverRule(policyID, route.params?.tagName)?.approver ?? '';
	const approver = getPersonalDetailByEmail(tagApprover);
	const approverText = approver?.displayName ?? tagApprover;

To this so when approvalrules change it gets re-rendered. This is the same thing we do here

const approverText = useMemo(() => {
        const tagApprover = getTagApproverRule(policy, route.params?.tagName)?.approver ?? '';
        const approver = getPersonalDetailByEmail(tagApprover);
        return approver?.displayName ?? tagApprover;
    }, [route.params?.tagName, policy?.rules?.approvalRules]);

What alternative solutions did you explore? (Optional)

[mukhrr]

Proposal

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

Approver is not reflected when select and unselect user

What is the root cause of that problem?

We are not changing tagApprover when route.params?.tagName changes

App/src/pages/workspace/tags/TagSettingsPage.tsx

Line 57 in 72062d4

const tagApprover = getTagApproverRule(policyID, route.params?.tagName)?.approver ?? '';

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

We can simply wrap constant above with useMemo so that is properly changes when deps get updated

    const tagApprover = useMemo(() => getTagApproverRule(policy, route.params?.tagName)?.approver ?? '', [policy, route.params?.tagName]);

And yes, we can simplify CategoryApprover logic also as we do here

What alternative solutions did you explore? (Optional)

[bernhardoj]

Proposal

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

The tag approver field is not updated dynamically.

What is the root cause of that problem?

We get the tag approver with getTagApproverRule by passing the policyID.

App/src/pages/workspace/tags/TagSettingsPage.tsx

Line 57 in 72062d4

const tagApprover = getTagApproverRule(policyID, route.params?.tagName)?.approver ?? '';

We then get the policy using getPolicy.

App/src/libs/PolicyUtils.ts

Lines 1374 to 1381 in 72062d4

	function getTagApproverRule(policyOrID: string | SearchPolicy | OnyxEntry<Policy>, tagName: string) {
	if (!policyOrID) {
	return;
	}
	// This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	const policy = typeof policyOrID === 'string' ? getPolicy(policyOrID) : policyOrID;

We also already subscribed to the policy onyx here so it should re-calculated when the policy rule changes.

App/src/pages/workspace/tags/TagSettingsPage.tsx

Line 51 in 72062d4

const policy = usePolicy(policyID);

But it doesn't happen because react-compiler automatically memoized the tagApprover, and since we pass the policyID, it will only re-calculated when either policyID or route.params?.tagName changes.

const tagApprover = useMemo(() => getTagApproverRule(policyID, route.params?.tagName)?.approver ?? '', [policyID, route.params?.tagName]);

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

We need to pass the policy object instead of the ID.

const tagApprover = getTagApproverRule(policy, route.params?.tagName)?.approver ?? '';

[melvin-bot]

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

[melvin-bot]

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

[nabi-ebrahimi]

🚨 Edited by proposal-police: This proposal was edited at 2025-11-03 12:29:26 UTC.

Proposal

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

Approver selection does not reflect immediately on Tag Settings page.

What is the root cause of that problem?

The issue happened because the TagSettingsPage used a non-reactive way to get the approver. It called getTagApproverRule, which used getPolicy(policyID) — a non-reactive method. So when the policy data changed, the component didn’t re-render, leaving the approver field empty until the page was reloaded.

App/src/pages/workspace/tags/TagSettingsPage.tsx

Line 57 in 515655a

const tagApprover = getTagApproverRule(policyID, route.params?.tagName)?.approver ?? '';

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

Use the reactive policy object from usePolicy and the current tag name to derive the approver. This ensures the approver value recomputes and re-renders when returning from the approver page.

App/src/pages/workspace/tags/TagSettingsPage.tsx

Line 51 in 515655a

const policy = usePolicy(policyID);

Removed this:

App/src/pages/workspace/tags/TagSettingsPage.tsx

Line 57 in 515655a

const tagApprover = getTagApproverRule(policyID, route.params?.tagName)?.approver ?? '';

Instead add this:

    const tagApprover = useMemo(() => getTagApproverRule(policy, currentPolicyTag?.name ?? route.params?.tagName)?.approver ?? '', [policy, currentPolicyTag?.name, route.params?.tagName]);

This makes the approver label update immediately when navigating back from the approver selection screen.

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

• After selecting a new approver in Tag Approver page and navigating back, Tag Settings shows the updated approver immediately.
• After unselecting the approver and navigating back, Tag Settings shows the field cleared immediately.
• Works in both navigation flows: Workspace routes and Settings Quick Settings routes.
• Changing the tag’s name while on the page still derives the approver from the updated tag (uses currentPolicyTag.name).

What alternative solutions did you explore? (Optional)

• Alternative 1 (Onyx subscription): Subscribe directly to the policy Onyx key for reactivity and deriving the approver from that.
  Remove:
  

  App/src/pages/workspace/tags/TagSettingsPage.tsx

  Line 57 in 515655a

  const tagApprover = getTagApproverRule(policyID, route.params?.tagName)?.approver ?? '';

  
  Add:

   const [policyOnyx] = useOnyx(`${ONYXKEYS.COLLECTION.POLICY}${policyID}`, {canBeMissing: true});
   const tagApprover = useMemo(
        () => getTagApproverRule(policyOnyx, currentPolicyTag?.name ?? route.params?.tagName)?.approver ?? '',
        [policyOnyx, currentPolicyTag?.name, route.params?.tagName],
    );

• Alternative 2 (Recompute on focus): Force recomputation when screen gains focus.

We can also add a new state to make it work

const [approverText, setApproverText] = useState('');

useFocusEffect(React.useCallback(() => { const email = getTagApproverRule(policyID, route.params?.tagName)?.approver ?? ''; const approver = getPersonalDetailByEmail(email); setApproverText(approver?.displayName ?? email); }, [policyID, route.params?.tagName]));

Remove the old synchronous approverText derivation to avoid stale values.

[suneox]

Thank you for all the proposals. I’ll take a look at this one today.