Fix missing owner details on pending join request workspace rows by NicolasBonet · Pull Request #95417 · Expensify/App

NicolasBonet · 2026-07-06T17:48:30Z

Explanation of Change

For a workspace with a pending join request, the owner is usually someone the current user has never interacted with, so their entry is missing from PERSONAL_DETAILS_LIST. The workspaces list built the owner column exclusively from that list, leaving the Owner cell empty for pending-join rows even though the join request data (policyDetailsForNonMembers) already includes the owner's email and accountID.

This PR:

Carries ownerEmail through the createWorkspaceListPoliciesSelector projection (nonMemberDetails).
Falls back to that email for the owner's login/display name when the personal details lookup misses, and renders the owner's deterministic default avatar via getDefaultAvatarURL({accountID, accountEmail}) instead of the generic fallback icon.
Fixes the default workspace icon for pending-join rows: it was generated from policy.name, which is undefined on the parent policy object for these rows — the name lives in policy.nonMemberDetails.name.

Fixed Issues

$ #94550
PROPOSAL: #94550 (comment)

Tests

Log in as User A, create a workspace, and go to Workspaces > [workspace] > Overview > Share.
Copy the invite link shown under the QR code.
In a separate browser/incognito window, log in as User B. User B must not share a chat or workspace with User A, and must be on a domain where the workspace cannot be auto-joined (e.g. a different email domain).
As User B, open the copied invite link.
Navigate to the Workspaces list (Settings > Workspaces).
Verify the pending workspace row shows the "Requested" badge.
Verify the Owner column shows User A's email and User A's default avatar (not an empty cell or generic gray placeholder).
Verify the workspace icon shows the default avatar generated from the workspace's name (correct initial letter and color).

Verify that no errors appear in the JS console

Offline tests

Complete steps 1–5 from the Tests section above.
Turn off the network connection.
Re-open the Workspaces list.
Verify the pending workspace row still shows the owner's email and default avatar from cached Onyx data.

QA Steps

Same as Tests.

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

MacOS: Chrome / Safari

The owner of a workspace the user only requested to join is usually not in the personal details list, so the owner column rendered empty. Fall back to the ownerEmail already provided by policyDetailsForNonMembers, and use the pending policy name for the default workspace avatar. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

melvin-bot · 2026-07-06T20:36:21Z

@marufsharifi 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]

marufsharifi · 2026-07-07T09:04:37Z

+        expect(screen.getByText('Pending Workspace')).toBeOnTheScreen();
+        expect(screen.getByText(new RegExp(OWNER_EMAIL))).toBeOnTheScreen();


NAB: This UI test verifies the owner email, but not the two visual fallback changes: the owner default avatar and the workspace default icon derived from nonMemberDetails.name. Since the manual steps cover this, I wouldn’t block on it, but adding an assertion for the workspace default avatar test ID would improve regression coverage.

[Nico's Agent] Added an assertion for the workspace default avatar test ID (SvgDefaultAvatar_p Icon) to the UI test; the owner default avatar is now covered by the selector unit test since it's derived there. Done in 5d98bf8.

marufsharifi · 2026-07-07T09:09:10Z

+describe('createWorkspaceListPoliciesSelector', () => {
+    it('projects owner details from policyDetailsForNonMembers for join-request-pending policies', () => {
+        const pendingPolicyID = '1';
+        const policies: OnyxCollection<Policy> = {
+            pendingPolicy: buildSelectorPolicy(1, {
+                isJoinRequestPending: true,
+                policyDetailsForNonMembers: {
+                    [pendingPolicyID]: {
+                        name: 'Pending Workspace',
+                        type: CONST.POLICY.TYPE.TEAM,


Blocking: this adds duplicate coverage for createWorkspaceListPoliciesSelector in tests/unit/selectors/PolicyTest.ts. There’s already a dedicated suite for this selector in tests/unit/PolicySelectorTest.ts, including pending join nonMemberDetails projection and the regular-policy nonMemberDetails undefined case. Could we remove this new duplicated describe block and instead update the existing pending join projection test to include ownerEmail in the fixture and expected nonMemberDetails?

[Nico's Agent] Removed the duplicated describe block from tests/unit/selectors/PolicyTest.ts and updated the existing pending join projection test in tests/unit/PolicySelectorTest.ts to cover ownerEmail (and the new derived ownerDefaultAvatar). Fixed in 5d98bf8.

marufsharifi · 2026-07-08T10:23:09Z

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 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)
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)
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.
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

Not Applicable

Android: mWeb Chrome

iOS: HybridApp

Not Applicable

iOS: mWeb Safari

MacOS: Chrome / Safari

…upe tests - Derive the pending join request owner's default avatar URL in createWorkspaceListPoliciesSelector so the email is only hashed when policy data changes, not on every page render. - Remove the duplicated createWorkspaceListPoliciesSelector suite from tests/unit/selectors/PolicyTest.ts and extend the existing projection test in tests/unit/PolicySelectorTest.ts with ownerEmail and the derived ownerDefaultAvatar. - Assert the workspace default avatar test ID in the pending join request UI test. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…uage files and update references in PolicyRulesPage components to use 'importRulesTitle' instead.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

trjExpensify

Makes sense to fix this to me. 👍

marufsharifi · 2026-07-09T03:53:15Z

@MelvinBot review

MelvinBot · 2026-07-09T03:55:41Z

🤖 Code review — this is a clean, well-scoped fix. All CI checks are green, and the change correctly addresses all three root causes described. LGTM overall; no blocking issues.

What I verified:

The owner fallback (WorkspacesListPage.tsx:108-115) only kicks in when the owner is missing from PERSONAL_DETAILS_LIST, and the guard ownerAccountID && ownerEmail is safe — both fields are required on PolicyDetailsForNonMembers, so the fallback object is always fully populated when reached.
The icon fix at WorkspacesListPage.tsx:135 is correct: the row title already read from nonMemberDetails.name (line 123), while the default icon was still keyed off the parent policy.name (undefined for these rows). This makes the two consistent.
Deriving ownerDefaultAvatar inside the selector (Policy.ts:105-106) rather than on every render is a good call, and the guard there matches the one on the page.

Minor, non-blocking observations

ownerDefaultAvatar/ownerEmail guards are technically redundant. Both ownerAccountID and ownerEmail are non-optional on PolicyDetailsForNonMembers, so the details.ownerAccountID && details.ownerEmail check in the selector and the ownerAccountID && ownerEmail check on the page can only fail on malformed/legacy Onyx data. Keeping them as defensive guards is fine — just noting they won't trip under the declared types.
Test brittleness. The SvgDefaultAvatar_p Icon assertion couples the test to the first alphanumeric character of the workspace name. It's correct and the inline comment explains it well, but a future rename of the test fixture's name would silently break the testID. Acceptable as-is.

Nice work — the selector-level memoization detail and the offline test coverage are both solid.

NicolasBonet · 2026-07-09T15:23:05Z

@marufsharifi still waiting for your final review

marufsharifi · 2026-07-09T15:26:36Z

@NicolasBonet, I will finish my testing in an hour. thanks.

marufsharifi · 2026-07-09T18:31:27Z

LGTM. thanks

melvin-bot · 2026-07-09T18:31:45Z

@stitesExpensify 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]

OSBotify · 2026-07-09T21:03:55Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

github-actions · 2026-07-09T22:13:25Z

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

github-actions · 2026-07-09T22:26:22Z

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

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-44e0f0eb8cc-aa76580-671fc1a80dee71e301dbf1f1b1c36f338be7ffd6/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-44e0f0e-aa76580-13162d9fcb35b0ead3337c4373f61c8541f819bf/index.html

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

👀 View the workflow run that generated this build 👀

OSBotify · 2026-07-10T16:19:20Z

🚀 Deployed to staging by https://github.com/stitesExpensify in version: 9.4.33-0 🚀

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

MelvinBot · 2026-07-10T16:22:42Z

🤖 Help site review — no changes required.

I reviewed the changes in this PR against the help site content under App/docs/articles. No documentation updates are needed.

Why: This is a UI bug fix that corrects how existing data is rendered — it does not add, remove, or change any user-facing feature or workflow:

Falls back to the join request's ownerEmail + deterministic default avatar so the Owner column isn't empty on pending join-request rows.
Fixes the workspace default icon for those rows (it was generated from an undefined policy.name).

Docs checked: I searched App/docs/articles for content describing the Workspaces list, join requests, and owner display. The only near matches (Invite-members-and-assign-roles.md and Create-and-Manage-Domain-Groups.md) cover invite links and pre-approving join requests, not the rendering of owner details in the Workspaces list. Neither documents the behavior this PR touches.

No draft PR was created since there's nothing to change.

@NicolasBonet, please confirm you agree no help site changes are required here. If you believe an article should be updated, let me know which behavior to document and I'll open a draft PR.

melvin-bot Bot assigned NicolasBonet Jul 6, 2026

nkdengineer mentioned this pull request Jul 6, 2026

[$250] Workspace - Pending join request workspace doesn't show the owner details #94550

Open

7 tasks

NicolasBonet marked this pull request as ready for review July 6, 2026 20:36

NicolasBonet requested review from a team as code owners July 6, 2026 20:36

melvin-bot Bot requested review from marufsharifi and trjExpensify and removed request for a team July 6, 2026 20:36

melvin-bot Bot removed the request for review from a team July 6, 2026 20:36

marufsharifi suggested changes Jul 7, 2026

View reviewed changes

NicolasBonet and others added 2 commits July 8, 2026 10:12

Merge branch 'main' into nicolas-94550-pending-join-owner-details

b9f6032

NicolasBonet requested a review from marufsharifi July 8, 2026 17:27

NicolasBonet and others added 3 commits July 8, 2026 14:24

Remove 'importRulesViaSpreadsheet' translation key from multiple lang…

def290d

…uage files and update references in PolicyRulesPage components to use 'importRulesTitle' instead.

Merge branch 'main' into nicolas-94550-pending-join-owner-details

f8215d8

Add missing getDefaultAvatarURL import

fa05104

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

trjExpensify approved these changes Jul 8, 2026

View reviewed changes

marufsharifi approved these changes Jul 9, 2026

View reviewed changes

melvin-bot Bot requested a review from stitesExpensify July 9, 2026 18:31

stitesExpensify approved these changes Jul 9, 2026

View reviewed changes

stitesExpensify merged commit 44e0f0e into main Jul 9, 2026
44 checks passed

stitesExpensify deleted the nicolas-94550-pending-join-owner-details branch July 9, 2026 20:54

OSBotify mentioned this pull request Jul 10, 2026

Deploy Checklist: New Expensify 2026-07-10 #95814

Open

72 tasks

		expect(screen.getByText('Pending Workspace')).toBeOnTheScreen();
		expect(screen.getByText(new RegExp(OWNER_EMAIL))).toBeOnTheScreen();

Uh oh!

Conversation

NicolasBonet commented Jul 6, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

melvin-bot Bot commented Jul 6, 2026

Uh oh!

Uh oh!

marufsharifi Jul 7, 2026

Choose a reason for hiding this comment

Uh oh!

NicolasBonet Jul 8, 2026

Choose a reason for hiding this comment

Uh oh!

marufsharifi Jul 7, 2026

Choose a reason for hiding this comment

Uh oh!

NicolasBonet Jul 8, 2026

Choose a reason for hiding this comment

Uh oh!

marufsharifi commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviewer Checklist

Screenshots/Videos

Uh oh!

trjExpensify left a comment

Choose a reason for hiding this comment

Uh oh!

marufsharifi commented Jul 9, 2026

Uh oh!

MelvinBot commented Jul 9, 2026

Uh oh!

NicolasBonet commented Jul 9, 2026

Uh oh!

marufsharifi commented Jul 9, 2026

Uh oh!

marufsharifi commented Jul 9, 2026

Uh oh!

melvin-bot Bot commented Jul 9, 2026

Uh oh!

Uh oh!

OSBotify commented Jul 9, 2026

Uh oh!

github-actions Bot commented Jul 9, 2026

Uh oh!

github-actions Bot commented Jul 9, 2026

Uh oh!

OSBotify commented Jul 10, 2026

Uh oh!

MelvinBot commented Jul 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

NicolasBonet commented Jul 6, 2026 •

edited by github-actions Bot

Loading

marufsharifi commented Jul 8, 2026 •

edited

Loading