Only show "New role types for admins" window to returning Collect/Control admins

[MelvinBot]

Explanation of Change

The "New role types for admins" product marketing window was shown to any user who is an admin on any active workspace, with no check for the user's plan tier or how new they are. As a result it appeared for Submit admins and for brand-new users, neither of which should see it.

This PR adds two gates so the window is only shown to returning Collect/Control admins:

1. Collect/Control only — ProductMarketingWindowManager now filters the admin workspaces used to pick the target policy down to Collect (team) and Control (corporate) types. Submit (submit2026) admins no longer resolve a target admin policy, so they fall through to the (absent) member variant and see nothing.
2. Exclude brand-new users — the active announcement now carries a returningUserCutoffDate, and a new pure helper isBrandNewUser compares it against nvp_private_firstPolicyCreatedDate (mirroring the existing useHasTeam2025Pricing pattern). Users whose first workspace was created on or after the cutoff are treated as brand-new and skip the window. When the creation date is unknown, the user is treated as returning so established admins are never wrongly excluded.

Note for reviewers: the cutoff date is set to 2026-07-01 to match the productUpdateJuly2026 update key — please confirm the exact launch date for the role-types feature. If a backend-provided eligibility signal is preferred over the client-side date check, that can be swapped in behind the same helper.

_{🤖 Generated with MelvinBot. AI checks run locally and passing: typecheck-tsgo, lint-changed, react-compiler-compliance-check, oxfmt, and the ProductMarketingWindowUtils unit suite (15 tests). A web smoke test could not complete because the dev server wasn't serving in the CI environment (blank page, no network activity), so please validate the flows below manually before marking ready.}

Fixed Issues

$ #98951
PROPOSAL: #98951 (comment)

Tests

// TODO: The human co-author must fill out the tests they ran before marking this PR as "ready for review". Suggested coverage: (1) a returning admin of a Collect/Control workspace (first workspace created before the cutoff) sees the "New role types for admins" window on Home; (2) a Submit-only admin does NOT see it; (3) a brand-new user (first workspace created on/after the cutoff) does NOT see it.

• Verify that no errors appear in the JS console

Offline tests

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[MelvinBot]

Android testing — "New role types for admins" window

I ran the PR on the Android emulator (branch claude-roleTypesWindowReturningAdmins). Honest bottom line: only 1 of the 3 intended scenarios is testable with a fresh Melvin sign-in account. The other two require backend-seeded account state (a workspace whose creation date predates the 2026-07-01 cutoff, plus a specific plan tier) that can't be produced with a brand-new test account.

✅ Scenario 3 — Brand-new user does NOT see the window (verified)

The test account had zero workspaces before this run. Onboarding created its first workspace (type: Collect, account is Owner/admin) today, 2026-08-19 — which is on/after the 2026-07-01 cutoff. Per the PR's gating, this is a brand-new user and should see nothing.

Observed: no "New role types for admins" window (or any product marketing popup) appeared on Home — checked immediately after onboarding and again after navigating away and back. This matches the expected behavior. ✅

• Home after onboarding — no popup
• Workspaces list — single Collect workspace, created this session
• Home re-entry — still no popup

(Screenshots posted in the follow-up comment.)

⚠️ Scenario 1 — Returning Collect/Control admin SEES the window (not testable)

Requires an account whose first workspace was created before 2026-07-01 on a Collect/Control plan. A fresh Melvin session can't backdate nvp_private_firstPolicyCreatedDate, so I could not reach the state where the window is supposed to appear. This is the primary positive path and remains unverified on-device.

⚠️ Scenario 2 — Submit-only admin does NOT see the window (not testable)

Requires an admin whose only workspace(s) are Submit (submit2026) tier. Onboarding created a Collect workspace, so I couldn't put the account in a Submit-only state.

Notes

• No JS/console errors observed during the run.
• The logic itself is covered by the 15-test ProductMarketingWindowUtils unit suite (including the new isBrandNewUser cases). The gaps above are about end-to-end device verification, not the unit logic.

To fully validate on-device, scenarios 1 and 2 need pre-seeded accounts: one returning Collect/Control admin with a pre-2026-07-01 first workspace (should show the window), and one Submit-only admin (should not). If you can point me at such accounts, I can re-run and capture the positive path.

[MelvinBot]

Web testing — "New role types for admins" window

I ran the PR on web (dev NewDot, branch claude-roleTypesWindowReturningAdmins). Honest bottom line: the same constraint as the Android run applies — only a negative case is reachable with a fresh Melvin sign-in account. The core positive path (window shown to a returning Collect/Control admin) needs a pre-seeded account and can't be exercised here.

✅ Negative case — no admin workspace → no window (verified)

This web test account had zero workspaces ("No workspaces yet" in Settings → Workspaces), so it has no Collect/Control admin role and doesn't qualify for the window. As expected, no "New role types for admins" popup (or any product marketing modal) appeared on Home. ✅

• Home after sign-in — no popup
• Workspaces tab — "No workspaces yet"

(Screenshots posted in the follow-up comment.)

Note: the "Discover" feed on Home does contain a normal card item ("Scoped admin roles, plus HR & AI updates") — that's the standard in-feed content, not the gated product marketing modal this PR governs.

⚠️ Scenario 1 — Returning Collect/Control admin SEES the window (not testable)

Requires an account whose first workspace was created before 2026-07-01 on a Collect/Control plan. A fresh Melvin session can't backdate nvp_private_firstPolicyCreatedDate, so the state where the window is supposed to appear is unreachable. This is the primary positive path and remains unverified on-device.

⚠️ Scenario 2 — Submit-only admin does NOT see the window (not testable)

Requires an admin whose only workspace(s) are Submit (submit2026) tier — not producible from this fresh account (no workspaces at all).

Notes

• No JS/console errors observed during the run.
• The logic is covered by the 15-test ProductMarketingWindowUtils unit suite (including the new isBrandNewUser cases). The gaps above are about end-to-end device verification, not the unit logic.

To fully validate the positive path on both platforms, please point me at pre-seeded accounts: one returning Collect/Control admin with a pre-2026-07-01 first workspace (should show the window), and one Submit-only admin (should not). I'll re-run and capture the window rendering.