[HOLD for payment 2024-10-30] Expensify Card - Cards are not assigned in table for newly created accounts

[isagoico]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.44-8

Reproducible in staging?: Yes
Reproducible in production?: Yes

If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/cases/view/3272217
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856

Issue reported by: Applause - Internal team

Action Performed:

1. Navigate to https://staging.new.expensify.com/
2. Log in with a new Expensifail account
3. Create a workspace
4. Navigate to Workspace settings - More features
5. Enable "Expensify Card"
6. Navigate to Workspace settings - Members
7. Invite a Gmail address that doesn't have an account yet
8. Navigate to Workspace settings - Expensify Card
9. Click on the "Issue new card" button
10. Add bank account details and finish the BA flow
11. Click on the "Issue new card" button
12. Select the new member
13. Select "Virtual card"
14. Add the card with any limit type, limit and name
15. Navigate to Workspace settings - Members
16. Click on the member added in step 7

Expected Result:

After assigning the card, it should be displayed in the cards table and assigned to the member.

Actual Result:

The virtual card is missing from the "Expensify Card" page and also from the workspace member profile page. I'm also unable to add a virtual card with the Workspace Member profile - New card flow.

Workaround:

No workaround found. No way to issue Ecards to new members

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Recording.842.mp4

Bug6624360_1728044115080.Member_-_New_card.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @garrettmknight

[melvin-bot]

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

[isagoico]

Note: We're able to assign cards to existing accounts. Take the following example from a test workspace:
I'm able to assign cards to [email protected] but not to [email protected] (new account.

[twilight2294]

Proposal

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

Cards are not assigned in table for newly created accounts

What is the root cause of that problem?

The API response is not successful for new users with unvalidated account:

The card never gets assigned hence it doesn't get showed in table or member profile page.

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

We should block the action to create virtual cards for unvalidated accounts. we can do so by showing the issuer a modal or by not showing the new user in the search list at all.

(for modal, we would need the design of how the error should look) and (for not showing we can just filter the list of assignees available by filtering out the unvalidated accounts here

Same can be done for other company card page if bug exists there too:
We will return early if the account is unvalidated:

App/src/pages/workspace/expensifyCard/issueNew/AssigneeStep.tsx

Lines 80 to 84 in 10b8547

	Object.entries(policy.employeeList ?? {}).forEach(([email, policyEmployee]) => {
	if (PolicyUtils.isDeletedPolicyEmployee(policyEmployee, isOffline)) {
	return;
	}

App/src/pages/workspace/expensifyCard/issueNew/AssigneeStep.tsx

Line 74 in 10b8547

const membersDetails = useMemo(() => {

What alternative solutions did you explore? (Optional)

[cretadn22]

Proposal

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

Can't create a virtual card for an unvalidated account.

What is the root cause of that problem?

When attempting to create a virtual card for an unvalidated account, the backend returns the error message: "The assignee account has not been validated." However, this issue does not occur when creating a physical card. We should verify whether we need to prevent users from creating a physical card for an unvalidated account as well.

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

1. In the assignee step page, we should filter out all unvalidated accounts from the list
   

   App/src/pages/workspace/expensifyCard/issueNew/AssigneeStep.tsx

   Line 85 in 99f280b

   const personalDetail = PersonalDetailsUtils.getPersonalDetailByEmail(email);

            if (personalDetail?.validated === false) {
                return;
            }

I noticed that we have two files:

• src/pages/workspace/expensifyCard/issueNew/AssigneeStep.tsx
• src/pages/workspace/companyCards/assignCard/AssigneeStep.tsx

The logic for retrieving the sections list in both files is identical. I recommend creating a utility function to obtain the assignee section and using it in both files.

2. In the Member Detail Page

• We can disable the Issue Card button and show a label explaining why we can't issue a new card for this user. I believe this approach offers a better user experience by clearly communicating the reason for the restriction

• The second option is to show a modal when the user tries to issue a card to an unvalidated account

What alternative solutions did you explore? (Optional)

[twilight2294]

@cretadn22 what exactly is different in your proposal than mine? I can just see that you have elaborated on what I wrote as a brief :)) and we require that every proposal should be unique

We have that in contributor guidelines as well:

c.c. @dylanexpensify

[mountiny]

@isagoico can you please share the email used here and check if the accounts been validated or not? If you can see the response of the call that would be helpful in future too, whenever something is not happening as expected add console logs and network logs. Thanks

[cretadn22]

@mountiny I believe my proposal answers your question.

When attempting to create a virtual card for an unvalidated account, the backend returns the error message: "The assignee account has not been validated." However, this issue does not occur when creating a physical card. We should verify whether we need to prevent users from creating a physical card for an unvalidated account as well.

Should we allow assigning physical and virtual cars to unvalidated accounts?

[mountiny]

Should we allow assigning physical and virtual cars to unvalidated accounts?

I don't think we should allow that, at least that would require larger discussion. I think we can keep it this was but handle showing RBR and clear error when this happens.

I have confirmed the QA tester had the same issue.

@cretadn22 I believe the solution is to handle a failureData for creating the virtual card, I think we need to add optimistic data and failure data to the issue card flow, right now we lack feedback. @koko57 @VickyStash do you recall if there is a reason we did not add it in a first place?

[cretadn22]

I think we can keep it this was but handle showing RBR and clear error when this happens.

This would require some changes on the backend, as the BE doesn't currently return error messages to the ONYX store. @mountiny, what are your thoughts on my proposal? It's not particularly complicated to implement.

[dylanexpensify]

Agree with @mountiny on not allowing that for now.

[koko57]

@mountiny I think we haven't considered such case while working on that. I can implement this solution.

[mountiny]

@koko57 lets do it

[mountiny]

@cretadn22 we working on workspace feeds as a project and the correct solution here is to use failure data so we will handle it with expert agency

[koko57]

@mountiny tp which Onyx entry should we add the error for failureData - personalDetails?
I've also noticed one thing - when we enable Expensify Card, and before we choose a bank account go to member's details, click Issue New Card and try to issue a new card we get this error

Maybe for this one it's better not to show the Assigned Cards section and the Issue New Card button until we choose payment bank account for the card?

[mountiny]

hmm yeah the business should be provisioned once the bank account is chosen, can you add detailed steps for this flow please?

And I think the failure data would be on the card itself in the cards_ collection, then the RBR is ion the cards page

[koko57]

@mountiny steps:

1. Enable Expensify Card on a workspace.
2. Don't add the bank account, go to members page, open a member's details page
3. Click Issue New Card, go through the flow

And I think the failure data would be on the card itself in the cards_ collection, then the RBR is ion the cards page

but as the card cannot be issued we won't have the cardID for cards collection

[mountiny]

@koko57 I think in this case we are talking about the flow where the domain is correctly provisioned and you issue the card from the expensify card page.

To fix the above, I think we should just hide the new Expensify card option if the policy is not provisioned (so the expensifyCardsSettings does not exist with the required values

[koko57]

@mountiny I know - but I wanted to mention it as it was something I noticed while recreating the original issue. So ok, I will hide the section until the domain is provisioned.

[mountiny]

Perfect, thank you!

[koko57]

@mountiny but for the RBR for the original issue - i think it should be on the Member details page

[koko57]

PR ready for review #50644

[allgandalf]

Unassigning myself from this one, Dylan is reviewing the attached PR, keep the K2 cleannnn

[koko57]

I'll be ooo Monday - Tuesday (14-15 Oct) if there will be some changes required to my PR and you'd like to merge it asap - please ping Callstack team, someone might be able to take it over. Thanks!

[melvin-bot]

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

[dylanexpensify]

Reassigning as I head to parental leave next week! Thanks Garrett!

[mountiny]

Pr in review here

[melvin-bot]

@garrettmknight, @koko57, @mountiny, @DylanDylann Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[koko57]

PR is merged, this issue can be retested

[mountiny]

Asked for a retest here

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.52-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix/50248 handle card failure data #50644

If no regressions arise, payment will be issued on 2024-10-30. 🎊

For reference, here are some details about the assignees on this issue:

• @koko57 does not require payment (Contractor)
• @DylanDylann requires payment (Needs manual offer from BZ)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@DylanDylann] The PR that introduced the bug has been identified. Link to the PR:
• [@DylanDylann] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@DylanDylann] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@DylanDylann] Determine if we should create a regression test for this bug.
• [@DylanDylann] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@garrettmknight] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[mountiny]

The regression test for this was already handled as part of the workspace feeds project. The fix was in backend to ensure we return the card in the https response too so it show sup immediately.

I think we can close this one out as we have handled the payments for the project already