Assigned company card is named using the admin's account instead of the employee's account

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @quinthar
Slack conversation (hyperlinked to channel name): #Migrate

Action Performed:

1. Sign in as a workspace admin.
2. Navigate to Workspace > Company Cards > CSV feed.
3. Assign an unassigned company card to another employee.
4. Observe the generated card name in the Assign card RHP.

Expected Result:

The card name should be named using the employee's account, since the card belongs to that employee.

Actual Result:

The card name is named using the admin's account that performed the assignment

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022084277784406682899
• Upwork Job ID: 2084277784406682899
• Last Price Increase: 2026-08-03

[MelvinBot]

Proposal

What is the root cause of that problem?

The assign-card flow bakes the admin's name into customCardName before the admin ever picks the real cardholder, and then a set of guards refuse to recompute it once it's set. Two cooperating defects:

1. The single-employee shortcut pre-fills the card name from the wrong member. In useAssignCard.ts:200-212, when the workspace resolves to a single non-deleted employee the flow skips the Assignee step and jumps straight to Confirmation, pre-setting both email and customCardName. On a fresh CSV-feed workspace that single member is typically the admin, so the card is named "<admin>'s card". There's also a filtered/unfiltered mismatch: the length === 1 check runs on the filtered (non-deleted) list, but userEmail = Object.keys(policy.employeeList).at(0) reads the unfiltered first key — so it can pick the wrong (admin) email even when the counted employee is someone else.

2. Stale guards never recompute the name when the assignee changes. AssigneeStep.tsx:92 only sets the name ...(!assignCard?.cardToAssign?.customCardName ? {customCardName: defaultCardName} : {}), and lines 103/139 use customCardName ?? defaultCardName. So once the admin's name is stored, editing the assignee to another employee leaves the admin's name in place. The Confirmation RHP renders that stored value (ConfirmationStep.tsx:211) and it's sent to the backend as cardName (CompanyCards.ts:469).

Evidence & data flow

• The name generator: CardUtils.ts:1154-1159 → `${cardholder}'s card`. memberName falls back to the raw login/email when firstName is empty, which is why the symptom reads as the admin's account/email.
• Flow: click Assign → useAssignCard.assignCard() → getInitialAssignCardStep(). Single-member → auto-fills email+customCardName, routes to CONFIRMATION. Multi-member → routes to ASSIGNEE, where the name is correctly derived from the selected assignee (AssigneeStep.tsx:87-89) — that path alone is fine.
• The bug fires when customCardName is already populated (admin) and the admin then selects/changes the assignee: the guards refuse to recompute.
• Related/secondary: InviteNewMemberStep.tsx:62 passes an email (invitingMemberEmail) into getDefaultCardName, producing "<email>'s card" instead of "<Name>'s card" — inconsistent with AssigneeStep, worth fixing in the same pass.

Note: I confirmed this by static code analysis (deterministic front-end Onyx state — no server logs involved). I did not spin up a live CSV feed to reproduce, since that requires specific workspace/feed provisioning. Confidence is medium-high.

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

1. Fix the member selection in the single-employee shortcut (useAssignCard.ts:200-212): derive userEmail from the same filtered list used for the length === 1 check (e.g. filter Object.entries(policy.employeeList) and take the surviving entry's email) so the auto-assign always targets the single active member, not the unfiltered first key.

2. Make the card name follow the current assignee in AssigneeStep.tsx: recompute customCardName from the newly-selected assignee instead of keeping the previously-stored value (drop/adjust the guards at lines 92, 103, 139). To avoid clobbering a name the user manually typed in CardNameStep, track whether the name was user-edited and only skip the recompute in that case.

What alternative solutions did you explore? (Optional)

Only recomputing at the Confirmation/submit step (from cardToAssign.email) instead of touching the Assignee guards — this centralizes the fix but doesn't correct the name the user sees in the intermediate steps, so fixing it at the source (assignee selection) is preferable.

---

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

[melvin-bot]

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

[melvin-bot]

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

[j3ffffff]

VERDICT: POST
ROOT_CAUSE_ONELINER: In useInitialAssignCardStep (src/hooks/useAssignCard.ts ~line 202), when only one non-deleted employee remains, Object.keys(policy?.employeeList).at(0) fetches the first key of the unfiltered list (the admin, who was inserted first) instead of the one remaining active employee, so getDefaultCardName is called with the admin's name and the CONFIRMATION step is rendered showing "Admin's card".
PROPOSAL_TYPE: FIRST
AUTOPOST_SAFE: YES