Back to Paid GitHub Issues
GH
Paid Issue

[$250] Number commercial card feed default names on NewDot

Expensify/App

Key metric
USD 250.00
Match score71
Summary
USD 250.00
Repository
Expensify/App
Stars
4940
Comments
39
Platform
GitHub
Difficulty
Medium
Scam risk
Low
Status
open
TypeScriptExternalDailyHelp WantedBug

Description

## Problem Expensify Classic pulls bank names/aliases from an authoritative `bankList` that has default names for various banks. This is displayed as the default name for feeds in Domain Control Company Cards when no custom name is set. <img width="454" height="435" alt="Image" src="https://github.com/user-attachments/assets/983c4c64-fb6c-491f-a77f-06d7bc8c7f98" /> However, NewDot has it hardcoded. This is a problem when we have multiple feeds of `vcf1`, `vcf2`, etc. or `cdf1`, `cdf2`, they are not using the numbered names from the banklist, making it hard to disambiguate since all those feeds show up with a generic name. <img width="370" height="263" alt="Image" src="https://github.com/user-attachments/assets/86ec9279-8d41-4922-af4b-76ef220ab13d" /> ## Why is this important? It's confusing for users, as multiple feeds of the same bank are indistinguishable in the feed list. **Platform:** All (NewDot client-side rendering in `CardUtils.ts`) **Reproducible in staging?:** Yes **Reproducible in production?:** Yes ## Action Performed 1. On a domain/workspace with multiple commercial feeds of the same bank (e.g. `vcf`, `vcf2`). 2. Open Workspace → Company cards → feed selector (or the search card-feed filter). ## Expected Result Each feed shows a disambiguated name matching Classic's banklist numbering, e.g. "Visa cards" and "Visa 2 cards". ## Actual Result Every feed of the same bank renders the identical generic label ("Visa cards"), because NewDot hardcodes feed-type → bank name and discards the key suffix. ## Root Cause `getBankName()` ([`src/libs/CardUtils.ts:713`](https://github.com/Expensify/App/blob/main/src/libs/CardUtils.ts)) prefix-matches the feed key against a static `feedNamesMapping`, so `vcf`/`vcf2` both collapse to "Visa"; the suffix that Classic reads from the authoritative `bankList` is thrown away. ## Solution (Scope) Regenerate the number from the feed name itself (by taking off the suffix number). Note that not all suffixes are numbers, as there are entries like `cdfbmo` or `vcfcitibank2`. Scope this to **only** the numeric base families for now: - `vcf{N}`, `cdf{N}`, `gl1025{N}` Leave all other feed keys unchanged. ### Acceptance criteria (feed key → display name) | Feed key | Display name | Note | |----------------|--------------------|----------------------------------------| | `vcf` | Visa cards | no suffix → no number | | `vcf1` | Visa cards | no suffix → no number | | `vcf2` | Visa 2 cards | numeric suffix appended | |`vcfanzfav1` | ANZ NZ 1 Cards | numeric suffix appended | | `cdf` | Mastercard cards | | | `cdf2` | Mastercard 2 cards | | | `gl1025` | Amex cards | base key ends in digits, so NOT a suffix | | `gl10252` | Amex 2 cards | suffix is what follows `gl1025` | | `cdfbmo` | Mastercard cards | non-numeric suffix → leave alone | | `vcfcitibank2` | (unchanged) | out of scope for now | | custom nickname| (nickname wins) | unchanged behavior | ## Out of Scope - Reading the actual banklist strings from the backend (would need a new API payload field; deferred). - Other non-numeric feed families (`cdfbmo`, `vcfcitibank*`, etc.). ## Manual Test Steps 1. Create two Visa VCF feeds; verify "Visa cards" / "Visa 2 cards". 2. Verify `gl1025` (single Amex) still shows "Amex cards" (not "Amex 1025 cards"). 3. Verify `cdfbmo` is untouched. 4. Verify a set custom nickname still overrides the generated name. ## Automated Tests Unit tests on the new suffix helper + `getCustomOrFormattedFeedName` covering the table above. <details><summary>Upwork Automation - Do Not Edit</summary> <ul> <li>Upwork Job URL: <a href="https://www.upwork.com/jobs/~022072692048823453147">https://www.upwork.com/jobs/~022072692048823453147</a></li> <li>Upwork Job ID: 2072692048823453147</li> <li>Last Price Increase: 2026-07-09</li> </ul> </details>

Open original source