[NoQA] Show feed even if no linkedPolicyIDs or preferredPolicy

[madmax330]

Explanation of Change

Fixed Issues

$ #91765
PROPOSAL: N/A

Tests

• Verify that no errors appear in the JS console

• Log into an account with an expensify card feed that has no preferredPolicyID set and no linkedPolicyIDs

• Enable expensify cards on the workspace

• Click on issue cards and make sure you see that feed in the "From other worksapces" section like below:

Offline tests

N/A

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 any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • 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 shown in the product is localized by adding it to src/languages/* files and using the translation method
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • 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)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• 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)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• 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.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• 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

[madmax330]

Can you also do the same thing for corporate card feeds?

[madmax330]

@MelvinBot can you address the review comments?

[MelvinBot]

Updated getCardFeedsForDisplayPerPolicy in CardFeedUtils.ts to apply the same orphan feed handling for corporate card feeds:

1. Feeds with linkedPolicyIDs are now indexed under each linked policy ID (not just preferredPolicy)
2. Feeds with only preferredPolicy use existing behavior
3. Orphan feeds (no linkedPolicyIDs or preferredPolicy) are matched to policies via workspaceAccountID === fundID

Callers in useCardFeedsForActivePolicies.ts and useCardFeedsForDisplay.ts now pass the policies collection. Test updated accordingly.

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
src/hooks/useCardFeedsForDisplay.ts	96.42% <100.00%> (+0.13%)	⬆️
src/hooks/useExpensifyCardFeedsForFeedSelector.ts	100.00% <100.00%> (ø)
src/libs/CardFeedUtils.ts	92.63% <100.00%> (+0.40%)	⬆️
src/libs/CardUtils.ts	82.29% <90.00%> (+0.09%)	⬆️
src/libs/ExpensifyCardFeedSelectorUtils.ts	95.45% <93.33%> (+14.60%)	⬆️
...ifyCard/WorkspaceExpensifyCardFeedSelectorPage.tsx	0.00% <0.00%> (ø)
...e/expensifyCard/WorkspaceExpensifyCardListPage.tsx	0.00% <0.00%> (ø)
src/hooks/useCardFeedsForActivePolicies.ts	0.00% <0.00%> (ø)
... and 304 files with indirect coverage changes

[madmax330]

@MelvinBot can you fix the conflicts?

[MelvinBot]

🤖 Conflicts resolved and merged main into the branch.

There was one conflict in src/pages/workspace/expensifyCard/WorkspaceExpensifyCardFeedSelectorPage.tsx. Both sides added independent variable declarations, so I kept both:

• This branch: domains and cardList (used in getExpensifyCardFeedDescription)
• main: policy and canWriteExpensifyCard (used for the issue-card/other-feeds footer)

npm run typecheck-tsgo passes (exit code 0). The PR is no longer conflicting — please re-check the test steps once CI finishes.

[madmax330]

@MelvinBot can you find a way to simplify this PR so that it doesn't add so many helper methods? Or is there no way to simplify it?

[MelvinBot]

⏱️ Ran out of time before I could finish. This usually means the task was too complex or I got stuck exploring. Please try again with a more specific request or post in #melvinbot-ai.

Run details

[MelvinBot]

Yes, this can be simplified. The helper sprawl is all in the feed-description path — not the visibility path — and it can drop from 4 new helpers to 2.

The 4 new helpers (getDomainNameFromExpensifyCardSettings, getDomainNameFromExpensifyCardFeed, getDomainNameFromFundID, getDomainNameFromWorkspaceFundID) all answer one question — "what domain name describes this feed?" — from different sources, and they're only consumed by getExpensifyCardFeedDescription.

Proposed change: merge the three orphan-feed fallback resolvers (getDomainNameFromFundID + getDomainNameFromExpensifyCardFeed + getDomainNameFromWorkspaceFundID) into a single private getOrphanFeedDomainName. Keep getDomainNameFromExpensifyCardSettings separate — it has to run before the policy-name branch (settings domain outranks the policy name, but the orphan fallbacks rank below it). This drops getExpensifyCardFeedDescription from 5 branches to 3, and getDomainNameFromExpensifyCardFeed no longer needs to be exported from CardUtils.

The visibility changes (isExpensifyCardFeedVisibleToAdmin, getCardFeedsForDisplayPerPolicy) don't add helpers — they just gained fallback branches and params — so they're inherent to the feature and don't need touching.

Before → after (illustrative)

After — one consolidated fallback helper:

/** Best-effort domain name for an orphan feed (no linkedPolicyIDs / preferredPolicy). */
function getOrphanFeedDomainName(
    fundID: number | undefined,
    domains: OnyxCollection<Domain> | undefined,
    cardList: CardList | undefined,
    policies: OnyxCollection<Policy> | undefined,
): string {
    if (!fundID) {
        return '';
    }
    const domainEmail = domains?.[`${ONYXKEYS.COLLECTION.DOMAIN}${fundID}`]?.email ?? Object.values(domains ?? {}).find((domain) => domain?.accountID === fundID && !!domain.email)?.email;
    if (domainEmail) {
        return Str.extractEmailDomain(domainEmail);
    }
    const cardDomainName = getDomainNameFromExpensifyCardFeed(fundID, cardList);
    if (cardDomainName) {
        return cardDomainName;
    }
    const workspaceOwner = Object.values(policies ?? {}).find((policy) => policy?.workspaceAccountID === fundID)?.owner;
    return workspaceOwner ? Str.extractEmailDomain(workspaceOwner) : '';
}

After — the description function collapses to 3 branches:

function getExpensifyCardFeedDescription(
    cardSettings: OnyxEntry<ExpensifyCardSettings>,
    policies: OnyxCollection<Policy>,
    domains?: OnyxCollection<Domain>,
    fundID?: number,
    cardList?: CardList,
): string {
    // 1. Explicit domain name on the settings.
    const settingsDomainName = getDomainNameFromExpensifyCardSettings(cardSettings);
    if (settingsDomainName) {
        return getDescriptionForPolicyDomainCard(settingsDomainName, policies);
    }

    // 2. Linked / preferred policy name.
    const linkedPolicyIDs = getLinkedPolicyIDsFromExpensifyCardSettings(cardSettings);
    const preferredPolicyID = getPreferredPolicyFromExpensifyCardSettings(cardSettings);
    const policyIDForName = linkedPolicyIDs?.length ? linkedPolicyIDs.at(0) : preferredPolicyID;
    const policyName = policyIDForName && policies?.[`${ONYXKEYS.COLLECTION.POLICY}${policyIDForName.toUpperCase()}`]?.name;
    if (policyName) {
        return policyName;
    }

    // 3. Orphan feed fallback (fund domain -> its cards -> backing workspace owner).
    const orphanDomainName = getOrphanFeedDomainName(fundID, domains, cardList, policies);
    return orphanDomainName ? getDescriptionForPolicyDomainCard(orphanDomainName, policies) : '';
}

Net: 4 new helpers → 2, three repeated getDescriptionForPolicyDomainCard(...) wraps → two, and behavior is preserved (same fallback order).

If you want to trim further, the deeper question is whether all those orphan fallback sources (domain email -> card list -> workspace owner) are needed, or whether one authoritative source covers the real-world data — that would cut the helper to a couple of lines. Happy to dig into that if you tell me which source is reliable in practice.

---

Next Steps: Reply with @MelvinBot implement this to apply the consolidation above, or @MelvinBot <feedback> to adjust the approach.

[madmax330]

@MelvinBot implement this: #91764 (comment)
And fix the typecheck and spell check errors please

[MelvinBot]

🤖 Pushed a fix for the failing typecheck and spellcheck checks (commit 5ac1be3).

The simplify commit had already done the helper consolidation by inlining the orphan-feed fallback chain, which surfaced a few latent issues. Fixes:

Typecheck

• Policy has no workspaceAccountID field — replaced with policyAccountID (the field that holds the workspace account ID, per useWorkspaceAccountID's selector) in:
  • src/libs/ExpensifyCardFeedSelectorUtils.ts (admin-visibility check + owner-domain fallback)
  • src/libs/CardFeedUtils.ts (getCardFeedsForDisplayPerPolicy orphan match)
• Card.fundID is a string, so the orphan card lookup in getExpensifyCardFeedDescription now compares against fundID.toString().

Spellcheck

• Replaced the unknown word maxence in tests/unit/ExpensifyCardFeedSelectorUtilsTest.ts with a dictionary word.

Tests

• Updated the affected mocks (workspaceAccountID → policyAccountID) so the orphan-feed test in useExpensifyCardFeedsForFeedSelector.test.ts and the description test still pass.

Verified locally: prettier, cspell (spell-changed), eslint (lint-changed), typecheck-tsgo, and the 4 related Jest suites (ExpensifyCardFeedSelectorUtilsTest, CardFeedUtilsTest, useHasAnyAdminExpensifyCardFeed, useExpensifyCardFeedsForFeedSelector) all pass.

[Copilot]

Pull request overview

This PR updates Expensify Card feed selection and Company Card feed grouping so feeds still surface even when linkedPolicyIDs and preferredPolicy are missing (via domain-admin and policyAccountID fallback logic).

Changes:

• Expand Expensify Card feed visibility rules to include “orphan” feeds when the user is a domain admin (or when policyAccountID matches the feed’s fundID).
• Improve feed label/description resolution with additional fallbacks (domain email, card list domainName, workspace owner email domain).
• Update Company Card feed grouping per policy to index feeds by linkedPolicyIDs, with a policyAccountID fallback for orphan feeds, plus added/updated unit tests.

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tests/unit/hooks/useHasAnyAdminExpensifyCardFeed.test.ts	Adds coverage for domain-admin visibility when preferredPolicy is missing.
tests/unit/hooks/useExpensifyCardFeedsForFeedSelector.test.ts	Adds coverage for orphan feed inclusion/exclusion rules.
tests/unit/ExpensifyCardFeedSelectorUtilsTest.ts	Adds unit tests for the new description fallback chain.
tests/unit/CardFeedUtilsTest.ts	Updates expectations for linkedPolicyIDs indexing across multiple policies.
src/pages/workspace/expensifyCard/WorkspaceExpensifyCardListPage.tsx	Passes additional data to feed description (domains, card list).
src/pages/workspace/expensifyCard/WorkspaceExpensifyCardFeedSelectorPage.tsx	Uses enhanced feed descriptions in selector items.
src/libs/ExpensifyCardFeedSelectorUtils.ts	Implements orphan-feed visibility and richer description resolution.
src/libs/CardUtils.ts	Adds helper to read domainName from root or nested program blocks.
src/libs/CardFeedUtils.ts	Groups company card feeds per policy using linkedPolicyIDs / policyAccountID fallbacks.
src/hooks/useHasAnyAdminExpensifyCardFeed.ts	Includes domain collection + current user accountID in admin-feed detection.
src/hooks/useExpensifyCardFeedsForFeedSelector.ts	Includes domains + current user accountID to compute visible feeds.
src/hooks/useCardFeedsForDisplay.ts	Passes policies into company feed grouping (but introduces redundant policy subscriptions).
src/hooks/useCardFeedsForActivePolicies.ts	Passes policies into company feed grouping (but introduces redundant policy subscriptions).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[madmax330]

@MelvinBot can you address the PR review feedback?

[MelvinBot]

Addressed the outstanding review feedback in 83562b2 (pushed).

The only unresolved feedback was the two Copilot comments about the duplicate ONYXKEYS.COLLECTION.POLICY subscription in the card feed hooks. Both hooks subscribed to the policy collection twice — once for the full collection (allPolicies) and again with a selector. Since allPolicies is already subscribed and drives re-renders, I now compute eligiblePoliciesIDsArray directly from it and dropped the redundant selector subscription:

• src/hooks/useCardFeedsForDisplay.ts:61
• src/hooks/useCardFeedsForActivePolicies.ts:30

Behavior is unchanged (same data, same re-render triggers) with one fewer Onyx listener per hook.

Checks run locally

• ESLint (changed files): pass
• React Compiler compliance (both hooks): compiled
• Typecheck (tsgo): no errors in changed files (3 pre-existing, unrelated errors in HighlightableMenuItem.tsx, MenuItemWithTopDescription.tsx, BaseVideoPlayer.tsx)
• Jest: getDefaultCardFeedTest, CardFeedUtilsTest, useExpensifyCardFeedsForFeedSelector, useHasAnyAdminExpensifyCardFeed, useCardFeeds — 65 tests pass

The earlier inline comments (JSDoc requests on ExpensifyCardFeedSelectorUtils.ts and CardFeedUtils.ts) and the "do the same for corporate card feeds" review were already handled in prior rounds.

[madmax330]

@MelvinBot can you fix the conflicts?

[puneetlath]

@madmax330 eslint check is failing.

[madmax330]

@MelvinBot can you fix the typescript and eslint checks?

[MelvinBot]

⏱️ Ran out of time before I could finish. This usually means the task was too complex or I got stuck exploring. Please try again with a more specific request or post in #melvinbot-ai.

Run details

[madmax330]

Hmm the typescript failures look unrelated, a lot of the ESlint ones as well 😕
I think it's due to https://expensify.slack.com/archives/C01GTK53T8Q/p1780945507720319

[puneetlath]

@madmax330 should merging main fix that? Looks like Jest tests are failing now too.

[madmax330]

Yeah looks like they were fixed on main. The jest test was flakey so I fixed that also

[puneetlath]

ESLint check is still failing for some reason. @MelvinBot any idea why?

[MelvinBot]

The failure is from eslint-seatbelt, not a normal lint rule. It's failing on tests/unit/CardFeedUtilsTest.ts:

tests/unit/CardFeedUtilsTest.ts
  69:22  error  Unsafe type assertion: type 'CardList' is more narrow than the original type.
[eslint-seatbelt]: There are 18 errors of this type, but only 16 are allowed.
Remove 2 to turn these errors into warnings   @typescript-eslint/no-unsafe-type-assertion

Root cause: This PR added new as-style type assertions to CardFeedUtilsTest.ts, bumping its @typescript-eslint/no-unsafe-type-assertion count from 16 → 18. The seatbelt baseline still records 16 for that file (config/eslint/eslint.seatbelt.tsv:1745), and the baseline file was not updated in this PR. Seatbelt is read-only in CI, so it can't auto-update the count and fails instead.

How to fix — pick one:

1. Remove the 2 new assertions (preferred — keeps the count at 16). The new violations are on lines flagged in the log (e.g. 69, 84, plus the 317–369 block). Replacing value as SomeType with a properly-typed value or a helper avoids adding new debt.
2. Update the seatbelt baseline if the assertions are genuinely needed: run npm run lint locally (it regenerates eslint.seatbelt.tsv with the new count of 18) and commit the updated .tsv.

The other failing run (checklist) is just the PR-author checklist and is unrelated.

[madmax330]

Alright @puneetlath the lint errors are fixed

[github-actions]

🚧 @puneetlath has triggered a test Expensify/App build. You can view the workflow run here.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #91764.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-e0a5b2f5fdf-49430a6-7394aa30275ac16f251e58ef8ad1123076a6c80c/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-e0a5b2f-49430a6-f74ab784ca08e49c89a68db67f1d07da0970c250/index.html

Web 🕸️
https://91764.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/puneetlath in version: 9.4.5-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android
• iOS

[MelvinBot]

🤖 Help site review: no changes required

I reviewed the changes in this PR against the help articles under App/docs/articles and no documentation updates are needed.

Why: This PR is an internal bug fix to the Expensify Card feed selector visibility logic. It makes an admin's card feed surface under the From other workspaces section even when the feed has no preferredPolicy and no linkedPolicyIDs set (falling back to a policyAccountID / domain-admin / issued-card match). This restores the expected behavior rather than introducing or changing any user-facing concept.

The change does not:

• Add, rename, or remove any feature, tab, settings label, or button
• Change any documented setup or usage workflow
• Alter pricing, billing, or policy behavior described in the help site

The help articles that mention "card feeds" (e.g. Set-Up-and-Manage-the-Expensify-Card.md, the Connect Credit Cards section) describe the customer-facing setup flows, which are unchanged by this edge-case display fix. The "From other workspaces" grouping in the feed selector is a UI detail that isn't (and doesn't need to be) documented.

No draft PR was created since there is nothing to update. @madmax330, please confirm you agree with this assessment — if you'd like docs added for the "From other workspaces" behavior anyway, let me know and I'll draft a PR.

[OSBotify]

🚀 Deployed to production by https://github.com/Julesssss in version: 9.4.5-6 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅