Migrate loginList to logins Onyx key with expensifyLoginsSelector

[MelvinBot]

Explanation of Change

Migrates all consumers of the legacy loginList Onyx key to read from the new logins key via an expensifyLoginsSelector. The new logins key stores all logins across all partners in a dictionary keyed by {partnerID}_{partnerUserID}. The selector filters to Expensify logins (partnerID === 1) and re-keys by partnerUserID, returning the same LoginList shape so downstream code changes are minimal.

Key changes:

• Added CONST.PARTNER_ID.EXPENSIFY = 1
• Created expensifyLoginsSelector in UserUtils.ts that filters LOGINS entries by partnerID and returns LoginList-compatible shape
• Migrated all 35 useOnyx(ONYXKEYS.LOGIN_LIST) call sites to useOnyx(ONYXKEYS.LOGINS, {selector: expensifyLoginsSelector})
• Migrated all write operations in User.ts to write to ONYXKEYS.LOGINS with {partnerID}_{partnerUserID} key format
• Extended the Login type in Logins.ts with validateCodeSent and contact method error/pending field keys
• Removed the LOGIN_LIST Onyx key definition and type mapping
• Updated all 12 affected test files

Fixed Issues

$ #91018

PROPOSAL: #91018 (comment)

Tests

1. View contact methods

1. Go to Settings → Profile → Contact method.
2. Verify all your contact methods (primary + any secondary emails/phones) are listed.
3. Verify the default contact method is labeled, and that any unvalidated method shows the green/info indicator.

2. Add a new contact method + magic-code validation

1. Settings → Profile → Contact method → New contact method.
2. Add a new email or phone number.
3. Verify a magic code is sent and that entering the correct code validates the method and it appears in the list as validated.
4. Add another method and enter an incorrect magic code → verify the correct error message is shown and the method stays unvalidated.

3. Set default contact method

1. Tap a validated secondary contact method → Set as default (complete the magic-code re-auth if prompted).
2. Verify it becomes the new default and the list updates.

4. Remove a contact method

1. Tap a secondary contact method → Remove.
2. Verify it disappears from the list and does not reappear after a refresh.

5. Account indicator dots (these read login data via useAccountIndicatorChecks)

1. With an unvalidated contact method, verify the green info dot appears on the Profile/Account row in Settings.
2. Validate that method and verify the green dot clears.
3. If a contact method is in an error state, verify the red dot appears.

6. Participant / search selectors (read login data)

1. Start a New chat, a money request (attendee/accountant selector), and a task (assignee selector).
2. Verify search works and results render normally with no crash.

7. Work-email verification (company / Expensify Card)

1. Go to a Workspace → Company cards or Expensify Card → the "Add work email" / "Verify work account" flow.
2. Verify the magic-code verification step still works end to end.

8. Onboarding (fresh signup only)

1. Sign up with a work email and verify the private-domain / work-email onboarding step still detects your email correctly.

• Verify that no errors appear in the JS console

Offline tests

1. Go to Settings → Profile → Contact method.
2. Turn off your network connection.
3. Add a contact method while offline:
   1. Tap New contact method and add a new email or phone number.
   2. Verify the new method appears in the list immediately (optimistic UI) with a pending (greyed-out) appearance.
4. Remove a contact method while offline:
   1. Tap a secondary contact method → Remove.
   2. Verify it shows the pending (greyed-out) state.
5. Verify the account indicator dots (green info / red error) on the Profile/Account row in Settings still render correctly while offline.
6. Turn your network connection back on.
7. Verify the offline changes sync without duplicate or stale entries, and the pending states clear.

QA Steps

Same as Tests

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

[trjExpensify]

@eVoloshchak can you progress this today, please? Thanks!

[eVoloshchak]

The code looks good and this is working on all of the platforms (there are no user-facing changes, this is a technical improvement). This already supports errorFields added in the backend update, let's wait for it then we can merge

[arosiclair]

The code looks good and this is working on all of the platforms (there are no user-facing changes, this is a technical improvement). This already supports errorFields added in the backend update, let's wait for it then we can merge

Those backend changes are live now

[trjExpensify]

@eVoloshchak can you fix up this PR and have it in review today? Thanks!

[eVoloshchak]

@MelvinBot, pull the latest main

[MelvinBot]

🤖 Merged the latest main into this branch (now up to date through 87d567f).

There were 3 import/declaration conflicts, all resolved by keeping both sides:

• src/pages/home/TimeSensitiveSection/index.tsx — combined expensifyLoginsSelector into the existing @libs/UserUtils import alongside main's new HRUtils/HomeSectionExpandToggle/CONST imports.
• src/pages/settings/Profile/ProfilePage.tsx — kept main's new scrollViewRef line and this PR's useOnyx(ONYXKEYS.LOGINS, {selector: expensifyLoginsSelector}).
• src/pages/workspace/expensifyCard/WorkspaceExpensifyCardFeedSelectorPage.tsx — kept both canMemberWrite and expensifyLoginsSelector imports.

Verified with prettier (no changes), eslint (clean), and typecheck-tsgo (clean) before pushing.

[MelvinBot]

Fixed the failing check test (job 5) — the only real failure (the other failing check, PR Author Checklist, is just the unticked author checklist).

What failed: DebugTabView › Settings tab › Debug mode enabled › Has GBR › renders DebugTabView in tests/ui/BottomTabBarTest.tsx → Unable to find an element with testID: DebugTabView.

Root cause: The green-brick-road (info) indicator only appears for an unvalidated secondary contact method — i.e. a login whose partnerUserID differs from the primary session.email (hasLoginListInfo in UserUtils.ts:44). The pre-migration test modeled this with partnerUserID: 'john.doe@mail.com' while the session email was foo@bar.com. When the test was migrated to the new LOGINS key, the login was rewritten as partnerUserID: 'foo@bar.com' — equal to the primary email — so hasLoginListInfo returned false, no info indicator rendered, and DebugTabView was never shown.

Fix: Restore the secondary-login semantics in that one test by using a distinct unvalidated login (1_john.doe@mail.com / partnerUserID: 'john.doe@mail.com'). This is a test-data correction only — no production code changed.

Why this was a test-only issue (source path is correct)

• useAccountIndicatorChecks.ts:23 reads ONYXKEYS.LOGINS through expensifyLoginsSelector, which re-keys by partnerUserID.
• useAccountIndicatorChecks.ts:67 gates the info indicator on hasLoginListInfo(loginList, session.email).
• The RBR (error) sibling test passed because hasLoginListError only checks for non-empty errorFields and doesn't depend on partnerUserID.

Note: I couldn't run the Jest suite locally in this environment, so I'm relying on CI to confirm the fix. The change restores the exact data semantics of the original pre-migration test.

[MelvinBot]

🤖 Pushed a fix for the failing test (job 8) check in 0747e08.

Root cause

All three failing tests were a side effect of migrating from ONYXKEYS.LOGIN_LIST to ONYXKEYS.LOGINS + expensifyLoginsSelector. The selector filters to partnerID === CONST.PARTNER_ID.EXPENSIFY and re-keys the logins collection by partnerUserID.

1 & 2 — tests/actions/UserTest.ts (addNewContactMethod optimistic data):
The optimistic LOGINS value omitted partnerID, so the selector would drop the optimistic login. The migrated tests correctly expect partnerID: 1. Fixed by adding partnerID: CONST.PARTNER_ID.EXPENSIFY to the optimistic data in addNewContactMethod.

3 — tests/unit/ContactMethodDetailsPageTest.tsx (...when the login data has no partnerUserID):
With partnerUserID: '', the selector re-keys the login under '', so loginList[contactMethod] is undefined and the page renders FullPageNotFoundView. That path triggers useAbsentPageSpan, which calls Navigation.getActiveRoute() — a method the test's Navigation mock didn't define, producing TypeError: getActiveRoute is not a function. Fixed by adding getActiveRoute: jest.fn(() => '') to the mock. (The other two tests supply a valid login, so they never hit the not-found path — which is why only this test crashed.)

Verification

prettier and ESLint pass locally on the changed files; the fixes target the exact asserted values / the exact crashing call. Local Jest runs are sandbox-restricted here, so I'm relying on CI to confirm test (job 8) is now green.

The remaining PR Author Checklist / checklist failure is unrelated to the code and is the standard author checklist task, not a CI test failure.

[MelvinBot]

I analyzed the failing checks — there's no code fix to push. All 26 code/CI checks pass (typecheck, ESLint, Prettier, all 8 test shards, Storybook, builds, and the perf comparison). The two red checks are both non-code:

1. CLA / CLA — transient infrastructure failure, not a code/CLA problem.
The CLA itself verified successfully — the job log shows All contributors have signed the CLA 📝 ✅. The job then failed on a post-verification step in the shared CLA Assistant action:

##[error]Unable to locate this workflow's ID in this repository, can't trigger job..

This comes from contributor-assistant/github-action (run via the shared Expensify/GitHub-Actions cla.yml), not from this PR's code, so it can't be fixed by a commit. It's isolated to this run — other open PRs (e.g. #92270, #92255) are passing CLA fine. Fix: re-run the failed job (Re-run failed jobs on the CLA run). I couldn't trigger the re-run myself (CI re-run is permission-gated for me here).

2. PR Author Checklist / checklist — author action required.
Fails only because the checklist boxes are unticked (0 out of 49). The human co-author needs to complete the checklist and fill in the Tests/QA sections; I don't tick those on a person's behalf.

Once the CLA job is re-run and the checklist is completed, the PR will be green.

[codecov]

Codecov Report

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

Files with missing lines	Coverage Δ
src/CONST/index.ts	93.79% <ø> (ø)
src/ONYXKEYS.ts	100.00% <ø> (ø)
src/components/Search/SearchAutocompleteInput.tsx	95.89% <100.00%> (ø)
src/components/Search/SearchAutocompleteList.tsx	92.67% <100.00%> (ø)
src/hooks/useAccountIndicatorChecks.ts	100.00% <100.00%> (ø)
src/hooks/useContactImport.ts	80.00% <100.00%> (ø)
src/hooks/useHasPhoneNumberLogin.ts	100.00% <100.00%> (ø)
src/hooks/usePersonalDetailSearchSelector/base.ts	95.77% <100.00%> (ø)
src/hooks/useSearchSelector/base.ts	80.61% <100.00%> (ø)
src/pages/NewChatPage/index.tsx	78.78% <100.00%> (ø)
... and 29 more
... and 10 files with indirect coverage changes

[MelvinBot]

I analyzed the two failing checks. Neither is caused by this PR's code — there's nothing to fix in the diff.

1. CLA / CLA — infrastructure glitch, not a real CLA problem.
The job log shows the CLA actually passed, then the action errored on an unrelated post-step:

All contributors have signed the CLA 📝 ✅
##[error]Unable to locate this workflow's ID in this repository, can't trigger job..

All 4 commits are authored by MelvinBot (infra+melvinbot@expensify.com), a recognized contributor whose CLA is signed. The failure comes from the contributor-assistant action's re-trigger step, not from anything in this PR. Fix: re-run the failed CLA / CLA job (run 26772947722). I don't have permission to re-run it from here, so an assignee/maintainer should click "Re-run failed jobs".

2. PR Author Checklist / checklist — author action required.
This fails only because the checklist boxes are unticked (0 out of N). It needs the human author/co-author to complete the checklist; I can't tick those boxes on your behalf.

Everything else is green — typecheck, ESLint, Prettier, all 8 test shards, Storybook, all builds, and the perf comparison all pass.

[eVoloshchak]

@MelvinBot, propose some test steps so the QA can test this

[eVoloshchak]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible 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 checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (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 verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• 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
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• 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 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.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this 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.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

video_2026-06-02_19-54-16.mp4

Android: mWeb Chrome

Screen.Recording.2026-06-02.at.19.19.37.mov

iOS: HybridApp

Screen.Recording.2026-06-02.at.19.16.33.mov

iOS: mWeb Safari

Screen.Recording.2026-06-02.at.19.13.02.mov

MacOS: Chrome / Safari

Screen.Recording.2026-06-02.at.09.39.27.mov

[MelvinBot]

This PR is a pure Onyx key migration (loginList → logins via expensifyLoginsSelector) with no intended behavior change, so QA should focus on regression-testing every surface that reads or writes contact-method / login data. The highest-risk flows are contact methods (add / validate / set default / remove) and the account indicator dots, since those both read login data and write it via User.ts.

QA Steps

1. View contact methods

1. Go to Settings → Profile → Contact method.
2. Verify all your contact methods (primary + any secondary emails/phones) are listed.
3. Verify the default contact method is labeled, and that any unvalidated method shows the green/info indicator.

2. Add a new contact method + magic-code validation

1. Settings → Profile → Contact method → New contact method.
2. Add a new email or phone number.
3. Verify a magic code is sent and that entering the correct code validates the method and it appears in the list as validated.
4. Add another method and enter an incorrect magic code → verify the correct error message is shown and the method stays unvalidated.

3. Set default contact method

1. Tap a validated secondary contact method → Set as default (complete the magic-code re-auth if prompted).
2. Verify it becomes the new default and the list updates.

4. Remove a contact method

1. Tap a secondary contact method → Remove.
2. Verify it disappears from the list and does not reappear after a refresh.

5. Account indicator dots (these read login data via useAccountIndicatorChecks)

1. With an unvalidated contact method, verify the green info dot appears on the Profile/Account row in Settings.
2. Validate that method and verify the green dot clears.
3. If a contact method is in an error state, verify the red dot appears.

6. Participant / search selectors (read login data)

1. Start a New chat, a money request (attendee/accountant selector), and a task (assignee selector).
2. Verify search works and results render normally with no crash.

7. Work-email verification (company / Expensify Card)

1. Go to a Workspace → Company cards or Expensify Card → the "Add work email" / "Verify work account" flow.
2. Verify the magic-code verification step still works end to end.

8. Onboarding (fresh signup only)

1. Sign up with a work email and verify the private-domain / work-email onboarding step still detects your email correctly.

9. Offline behavior

1. Go offline, add or remove a contact method, and verify the optimistic UI + pending (greyed) state.
2. Go back online and verify it syncs without duplicate or stale entries.

10. Console

• Throughout all of the above, verify there are no JS console errors.

---

Since behavior is meant to be identical to production, the pass criterion for each step is simply: it works exactly as it does on production today.

_{🤖 Generated by MelvinBot. Reply with @MelvinBot <feedback> to refine these steps.}

[eVoloshchak]

@MelvinBot, there is a bug present:

1. Click on FAB -> Start Chat
2. Select a couple of participants
3. Click Next -> Start Group
4. Notice the group name is not shown, it's just an endless loading skeleton
5. Press on a search icon (or precc CMD+K) to open the search window
6. Notice the newly created group item is displayed, but its name is empty

[MelvinBot]

I couldn't reproduce this on the PR branch, and the migrated code doesn't sit on the group-name code path — so I don't think this PR causes it. Evidence below.

Reproduction attempt (this branch): FAB → Start chat → selected two participants → Next → Start group. The group name rendered correctly in the report header and in Search — no loading skeleton, no empty name, and no related console errors.

Report header after creation	Search results

Why this PR is an unlikely cause: the group name is computed from the participants' display names, not from login data.

• createGroup filters to non-empty logins and passes them to navigateToAndCreateGroupChat → createGroupChat, which writes optimistic personal details with displayName: login (createGroupChat Report/index.ts:2007-2026).
• The header/LHN name comes from getGroupChatName ReportNameUtils.ts:247-289, which resolves each participant's display name by accountID.
• None of that path reads the migrated loginList/logins data. In NewChatPage the only change is the loginList source (index.tsx:57), and there loginList only feeds option filtering / current-user identification — not the participant display names that produce the group title.

An empty group title would instead mean every participant's getDisplayNameForParticipant(accountID) returned empty — i.e. the optimistic personal details weren't created or carried an empty displayName. That's a participant/personal-details data issue, independent of this migration.

To help me pin it down, could you confirm:

1. Does it also reproduce on main / staging / production (i.e. is it a pre-existing bug)?
2. What kind of participants did you select — brand-new emails/phone numbers (optimistic accounts) or existing contacts?
3. Any JS console errors at the moment of creation?
4. Is the logins Onyx key populated in your session (the migration assumes the backend returns logins)?

_{🤖 Generated by MelvinBot. Reply with @MelvinBot <feedback> to refine.}

[eVoloshchak]

@MelvinBot, pull the latest main

[MelvinBot]

🤖 Merged the latest main into this branch (the branch was 469 commits behind).

• Used git merge origin/main (no rebase, no force-push) → merge commit 2c79c7de50e
• No merge conflicts
• Sanity-checked that the 469 merged commits didn't reintroduce any ONYXKEYS.LOGIN_LIST references (the key this PR removes) — none found, so the migration is still complete.

Note: CI will re-run on the new commit. Please re-verify the test/QA steps still pass against the updated base before marking ready for review.

[MelvinBot]

⚠️ MelvinBot CI Fix Loop Detected

MelvinBot has made 5 consecutive commits trying to fix CI failures. Automatic CI fix dispatches are now paused for this PR.

Next steps: A human should review the recent commits and resolve the conflicting CI errors manually.

[eVoloshchak]

Re-testing

[eVoloshchak]

@MelvinBot, pull the latest main

[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

[eVoloshchak]

@MelvinBot, pull the latest main

[melvin-bot]

@arosiclair Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[MelvinBot]

🤖 Merged the latest main into this branch and pushed.

There were 3 conflicts, all clean additive overlaps that I resolved by keeping both sides:

• src/libs/UserUtils.ts — kept the new expensifyLoginsSelector from this branch and main's addition of CONST.PARTNER_ID.OAUTH to DEVICE_PARTNER_IDS.
• src/libs/actions/User.ts — kept getExpensifyLoginKey from this branch and main's new sessionAccountID connectWithoutView block.
• src/pages/workspace/expensifyCard/WorkspaceExpensifyCardFeedSelectorPage.tsx — kept both the canMemberWrite (main) and expensifyLoginsSelector (this branch) imports.

Prettier reported no formatting changes. Please re-run CI / verify the checks pass.

[arosiclair]

@eVoloshchak is this ready? The author checklist, test steps, and etc still need to be filled out.

[eVoloshchak]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible 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 checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (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 verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• 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
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• 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 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.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this 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.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

video_2026-06-09_08-58-25.mp4

Android: mWeb Chrome

Screen.Recording.2026-06-09.at.11.36.23.mov

iOS: HybridApp

Screen.Recording.2026-06-09.at.08.26.06.mov

iOS: mWeb Safari

Screen.Recording.2026-06-09.at.08.43.09.mov

MacOS: Chrome / Safari

Screen.Recording.2026-06-09.at.08.17.45.mov

[eVoloshchak]

@MelvinBot, fill out the tests section in PR author checklist with those steps and
check off every checkbox in the PR author checklist

[eVoloshchak]

LGTM

[github-actions]

🚧 @arosiclair 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 #91616.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-a3e233c68b7-79c0e20-6eee618cad6da24774a8c7a4d862d658bfc3f054/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-a3e233c-79c0e20-ffffd16bc5e6fe53301983f6b02d39b14d5b19b9/index.html

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

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/arosiclair in version: 9.4.2-0 🚀

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

Bundle Size Analysis (Sentry):

• Android
• iOS

[MelvinBot]

🤖 I reviewed the changes in this PR against the help site articles under docs/articles.

No help site changes are required.

This PR is a purely internal refactor: it migrates all consumers of the legacy loginList Onyx key to read from the new logins key via an expensifyLoginsSelector. The selector returns the same LoginList-compatible shape, so the user-facing behavior of contact methods, account indicators, and the various participant/search selectors is unchanged.

Specifically, the diff contains:

• Onyx key/selector wiring (ONYXKEYS.ts, UserUtils.ts, User.ts)
• Type changes (types/onyx/Logins.ts)
• A new constant (CONST.PARTNER_ID.EXPENSIFY)
• Call-site migrations across hooks/pages
• Test file updates

There are no changes to user-facing copy (src/languages/* is untouched), no new or renamed features, tabs, settings labels, or buttons, and no changes to any documented workflow. Help site articles describe product behavior, which this PR does not alter — so no draft docs PR was created.

If you believe a specific article needs updating, let me know which behavior changed and I'll take another look.

[mitarachim]

Deploy Blocker #93134 was identified to be related to this PR.

[jponikarchuk]

@trjExpensify @eVoloshchak @arosiclair Could you please confirm how should we check Test 7? We have no Add work email option. What account should we use?
We have Validate your account RHP when click on Add cards. Is it expected result?

[m-natarajan]

@arosiclair @eVoloshchak
We figured out the Add Work Email flow, but we're currently blocked from executing the offline scenarios.

When offline, the Add button is disabled, preventing us from adding a contact. Could you please confirm whether this is expected behavior or a potential issue?

[arosiclair]

When offline, the Add button is disabled, preventing us from adding a contact. Could you please confirm whether this is expected behavior or a potential issue?

@m-natarajan if that's the case, we can just skip the offline test steps listed here. Not an issue.

[m-natarajan]

@arosiclair @eVoloshchak This PR is failing because of a regression issue #90691

[OSBotify]

🚀 Deployed to staging by https://github.com/arosiclair in version: 9.4.4-1 🚀

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

Bundle Size Analysis (Sentry):

• Android
• iOS

[MelvinBot]

🤖 No help site changes required.

I reviewed the changes in this PR against the help articles under App/docs/articles. This is a purely internal data-layer refactor with no user-facing behavior change, so no documentation updates are needed.

Why no docs changes are required

What the PR does: Migrates all consumers of the legacy loginList Onyx key to read from the new logins key via an expensifyLoginsSelector. It re-keys data internally and returns the same LoginList-compatible shape so downstream code is unchanged.

Why it doesn't affect the help site:

• All 53 changed files are internal code (src/CONST, src/ONYXKEYS, hooks, libs, pages, types) or unit/UI tests — none touch docs/.
• No src/languages/* copy was changed, so no user-visible text, labels, or button names changed.
• The flows listed in the PR's Tests section (contact methods, magic-code validation, set/remove default contact method, account indicator dots, participant selectors, work-email verification, onboarding) are expected to behave identically to before — the PR explicitly migrates them to keep behavior the same.

Help articles document user-facing product behavior. Since this refactor changes only how login data is stored and read internally — not what the user sees or does — the existing articles remain accurate.

@eVoloshchak, please review the linked help site PR and confirm it reflects the current behavior. Then mark the linked help site PR Ready for review

Note: No help site PR was created because no documentation changes are required for this internal refactor. If you believe a specific article needs updating, let me know which behavior changed and I'll draft the update.

[OSBotify]

🚀 Deployed to production by https://github.com/Julesssss in version: 9.4.4-3 🚀

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