[Due for payment 2026-07-16] Workspace - Custom field editor opens not here page for people admin

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.26-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92875
Email or phone of affected tester (no customers): sidbhisdhidhisdhis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Create a Control workspace.
• Invite a member as people admin.
• Perform the steps below as people admin:

1. Go to staging.new.expensify.com
2. Go to workspace settings > Members.
3. Click on your profile.
4. Click any custom field.

Expected Result:

Custom field editor will open.

Actual Result:

Not here page opens.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7196898

Issue Owner

Current Issue Owner: @ShridharGoel

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/2a4e1b0b91254cc21c47aa949c0c39baaf93e4768eb5762c74deb9017254e284

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #92875

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

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

A People Admin who opens a workspace member's profile (Workspace Settings → Members → a member → Custom field 1/2) lands on the Not here page instead of the custom-field editor. This is a deploy blocker introduced by #92875, which added the People Admin role.

What is the root cause of that problem?

#92875 opened the member-details page to People Admins and made the custom-field rows interactive whenever the viewer has scoped MEMBERS write access — WorkspaceMemberDetailsPage.tsx:363-377 gates those rows on canWriteMembers = canMemberWrite(policy, currentUserLogin, MEMBERS), which is true for a People Admin.

But the editor page it navigates to was not updated to the scoped-access pattern. WorkspaceMemberCustomFieldPage.tsx:52-54 still wraps in AccessOrNotFoundWrapper with accessVariants={[ADMIN, CONTROL]}. The ADMIN variant resolves to canEditWorkspaceSettings (isPolicyAdmin || (isSubmitPolicy && isPolicyEditor)), which is false for a People Admin on a Control policy → the wrapper renders the Not here page.

So the row is clickable for People Admins, but the destination denies them. The analogous approval pages in the same PR were migrated to scoped access (e.g. WorkspaceWorkflowsApprovalsApproverPage.tsx:233-256); the custom-field editor was simply missed.

Why the ADMIN variant fails and how the scoped check works

AccessOrNotFoundWrapper auto-drops the ADMIN variant when a policyFeature prop is supplied and instead checks the scoped permission — AccessOrNotFoundWrapper.tsx:197-208:

const accessVariantsToCheck = policyFeature ? accessVariants.filter((variant) => variant !== CONST.POLICY.ACCESS_VARIANTS.ADMIN) : accessVariants;
...
if (policyFeature) {
    // policyFeatureAccess === WRITE ? canMemberWrite(policy, login, policyFeature) : canMemberRead(...)
}

Full Workspace Admins also hold MEMBERS write, so a scoped check keeps working for them.

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

Migrate the custom-field editor to the same scoped-access pattern the rest of the People Admin work uses. In WorkspaceMemberCustomFieldPage.tsx, add the MEMBERS write feature check to the wrapper:

<AccessOrNotFoundWrapper
    policyID={policyID}
    accessVariants={[CONST.POLICY.ACCESS_VARIANTS.ADMIN, CONST.POLICY.ACCESS_VARIANTS.CONTROL]}
    policyFeature={CONST.POLICY.POLICY_FEATURE.MEMBERS}
    policyFeatureAccess={CONST.POLICY.POLICY_FEATURE_ACCESS.WRITE}
>

With policyFeature set, the wrapper drops the ADMIN variant and instead requires canMemberWrite(policy, login, MEMBERS) — the exact permission the parent page already uses to make the rows interactive. This grants People Admins access while leaving full Admins (who also have MEMBERS write) and the CONTROL policy-type gate unchanged.

This is a small, App-only frontend fix. Given the deploy-blocker timer, reverting #92875 is the fastest fallback if a fix can't land quickly.

What alternative solutions did you explore?

Gate the custom-field rows in WorkspaceMemberDetailsPage on full-admin access instead — rejected, as the intent of #92875 is for People Admins to manage members (including custom fields), so the editor should be opened up, not the row locked down.

---

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