[$250] Read-only Role selector is displayed at 50% opacity in Member details panel

[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: 9.4.43-0
Reproducible in staging?: Y
Reproducible in production?: Y
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: @dannymcclain
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Add a user as a Workspace Admin.
2. Sign in as the newly added admin.
3. Navigate to Workspace > Members.
4. Click on the Owner to open the member details panel.
5. Observe the Role selector.

Expected Result:

The Role field should be displayed at full opacity.
The caret should be hidden since the role cannot be changed.
The field should match the appearance of other read-only fields (e.g., the Email field).

Actual Result:

The Role selector is displayed at 50% opacity, making it appear disabled.
The read-only styling is inconsistent with other non-editable fields.

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/~022080711961980179868
• Upwork Job ID: 2080711961980179868
• Last Price Increase: 2026-07-24

Issue Owner

Current Issue Owner: @mukhrr

[MelvinBot]

Proposal

What is the root cause of that problem?

The Role row in the member details panel is rendered with a MenuItemWithTopDescription that receives disabled={isSelectedMemberOwner || isSelectedMemberCurrentUser || !canManageSelectedMemberRole}. When you're viewing the Owner, isSelectedMemberOwner is true, so disabled is true.

MenuItem defaults shouldGreyOutWhenDisabled to true, so a disabled item applies styles.buttonOpacityDisabled (opacity: 0.5) to the whole row — that's the "looks disabled" appearance.

By contrast, the read-only Email field just above it uses interactive={false} and does not set disabled, so the opacity rule never fires and it renders at full opacity. The Role item is using the wrong prop to express "read-only".

Code references (SHA ea66d53)

• Role item passing disabled — WorkspaceMemberDetailsPage.tsx:366-388
• Read-only Email field (correct read-only pattern, interactive={false}, no disabled) — WorkspaceMemberDetailsPage.tsx:359-365
• Opacity applied when disabled — MenuItem.tsx:900 (shouldGreyOutWhenDisabled && disabled && styles.buttonOpacityDisabled)
• shouldGreyOutWhenDisabled defaults to true — MenuItem.tsx:576
• buttonOpacityDisabled = opacity: 0.5 — styles/index.ts:898-900

Note the Role item already sets interactive={!isReimburser && canManageSelectedMemberRole} and shouldShowRightIcon={!isReimburser && canManageSelectedMemberRole}, so the caret is already hidden for the read-only case — the only remaining visible problem is the 0.5 opacity from disabled.

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

Stop dimming the read-only Role row. Preferred: add shouldGreyOutWhenDisabled={false} to the Role MenuItemWithTopDescription, so the disabled prop still blocks the press but no longer applies opacity: 0.5. The existing interactive/shouldShowRightIcon props already hide the caret, so the row will then match the read-only Email field (full opacity, no chevron).

This keeps disabled guarding the onPress, so the behavior for owner / current-user / no-manage-permission cases is unchanged — only the appearance is fixed.

What alternative solutions did you explore? (Optional)

Remove the disabled prop entirely and rely on the already-computed interactive={false} (which blocks the press and caret, exactly like the Email field). This is the most faithful match to the read-only pattern, but it changes which prop guards the press, so the shouldGreyOutWhenDisabled={false} option is the smaller, lower-risk change.

---

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

[mukhrr]

Proposal

What is the root cause of that problem?

WorkspaceMemberDetailsPage marks the Role MenuItemWithTopDescription as disabled when the selected member is the workspace owner, the current user, or has a role the viewer cannot manage. But interactive and shouldShowRightIcon use a different condition that ignores the owner/current-user restrictions.

App/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx

Lines 366 to 388 in 3ed0953

	<MenuItemWithTopDescription
	disabled={isSelectedMemberOwner || isSelectedMemberCurrentUser || !canManageSelectedMemberRole}
	title={translate(`workspace.common.roleName`, member?.role)}
	interactive={!isReimburser && canManageSelectedMemberRole}
	description={translate('common.role')}
	shouldShowRightIcon={!isReimburser && canManageSelectedMemberRole}
	pressableTestID="member-role-menu-item"
	onPress={() => {
	if (
	tryNavigateToSubmitWorkspaceUpgrade(
	policy,
	true,
	CONST.UPGRADE_FEATURE_INTRO_MAPPING.roles.alias,
	ROUTES.WORKSPACE_MEMBER_DETAILS.getRoute(policyID, accountID),
	)
	) {
	return;
	}
	Navigation.navigate(ROUTES.WORKSPACE_MEMBER_DETAILS_ROLE.getRoute(policyID, accountID));
	}}
	hintText={isReimburser ? translate('common.roleCannotBeChanged', workspaceWorkflowsPageURL) : undefined}
	shouldRenderHintAsHTML
	/>

MenuItem defaults shouldGreyOutWhenDisabled to true and applies styles.buttonOpacityDisabled whenever disabled is true, and it passes disabled straight to the pressable.

App/src/components/MenuItem.tsx

Lines 898 to 903 in 3ed0953

	shouldGreyOutWhenDisabled && disabled && styles.buttonOpacityDisabled,
	isHovered && interactive && !focused && !pressed && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,
	] as StyleProp<ViewStyle>
	}
	disabledStyle={shouldUseDefaultCursorWhenDisabled && [styles.cursorDefault]}
	disabled={disabled || isExecuting}

That style sets opacity: 0.5.

App/src/styles/index.ts

Lines 898 to 900 in 3ed0953

	buttonOpacityDisabled: {
	opacity: 0.5,
	},

So a read-only Role field renders at 50% opacity (and, for an admin viewing an owner who isn't the payer, the caret can still show, because that admin can otherwise assign elevated roles). By contrast the read-only Email field just above uses interactive={false} with no disabled, so it stays at full opacity — the appearance the issue asks for.

App/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx

Lines 359 to 365 in 3ed0953

	<MenuItemWithTopDescription
	title={isSMSLogin ? formatPhoneNumber(phoneNumber ?? '') : memberLogin}
	copyValue={isSMSLogin ? formatPhoneNumber(phoneNumber ?? '') : memberLogin}
	description={translate(isSMSLogin ? 'common.phoneNumber' : 'common.email')}
	interactive={false}
	copyable
	/>

I confirmed this in the browser: driving the dev build to a member details page, the Role field's pressable computed to opacity: 0.5 / cursor: not-allowed, while the Email pressable computed to opacity: 1 / cursor: default.

Disabling the Role field for the owner/current-user was a deliberate permission guard, so we must keep the field disabled while opting out of the generic "disabled" appearance.

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

Define one canEditSelectedMemberRole boolean that combines every restriction — the member is not the owner, not the current user, not the reimburser, and canManageSelectedMemberRole is true — and drive disabled, interactive, and shouldShowRightIcon from it. Keep the item disabled so onPress can't navigate, but pass shouldGreyOutWhenDisabled={false} and shouldUseDefaultCursorWhenDisabled so the read-only value stays at full opacity with the normal cursor:

+ const canEditSelectedMemberRole = !isSelectedMemberOwner && !isSelectedMemberCurrentUser && !isReimburser && canManageSelectedMemberRole;
...
  <MenuItemWithTopDescription
-     disabled={isSelectedMemberOwner || isSelectedMemberCurrentUser || !canManageSelectedMemberRole}
+     disabled={!canEditSelectedMemberRole}
      title={translate(`workspace.common.roleName`, member?.role)}
-     interactive={!isReimburser && canManageSelectedMemberRole}
+     interactive={canEditSelectedMemberRole}
      description={translate('common.role')}
-     shouldShowRightIcon={!isReimburser && canManageSelectedMemberRole}
+     shouldShowRightIcon={canEditSelectedMemberRole}
+     shouldGreyOutWhenDisabled={false}
+     shouldUseDefaultCursorWhenDisabled

This matches the pattern other read-only MenuItemWithTopDescription fields already use — disabled without being visually dimmed.

Scope: editable member roles stay fully interactive with their caret and styling; owner, self, reimburser, and permission-restricted roles stay non-editable, show no caret, use the default cursor, and render at full opacity. As a side benefit, folding !isReimburser into disabled also stops a "payer" role row from navigating to the (no-op) role page on click — previously it was disabled=false, so a click still fired onPress even though the hint says the role can't be changed.

I verified the fix in the browser with the same Playwright script used to reproduce it: after the change the Role pressable computes to opacity: 1 / cursor: default with no caret, identical to the Email field (RED→GREEN).

I also added a deterministic test at tests/ui/WorkspaceMemberDetailsPageTest.tsx (there was no existing WorkspaceMemberDetailsPageTest) that renders the page as an admin viewing the owner and asserts the Role item is disabled but does not carry the opacity: 0.5 style. It fails on the current code and passes with the fix.

What alternative solutions did you explore? (Optional)

Removing disabled and relying only on interactive={false} (like the Email field). But interactive only controls presentation/accessibility; MenuItem still passes disabled to the pressable, so without disabled the Role page could be opened through an invalid path.

App/src/components/MenuItem.tsx

Lines 898 to 905 in 3ed0953

	shouldGreyOutWhenDisabled && disabled && styles.buttonOpacityDisabled,
	isHovered && interactive && !focused && !pressed && !shouldRemoveBackground && !shouldRemoveHoverBackground && styles.hoveredComponentBG,
	] as StyleProp<ViewStyle>
	}
	disabledStyle={shouldUseDefaultCursorWhenDisabled && [styles.cursorDefault]}
	disabled={disabled || isExecuting}
	ref={mergeRefs(ref, popoverAnchor, pressableRef)}
	role={interactive ? role : undefined}

Keeping the field disabled while opting out of the generic disabled appearance preserves the permission guard and produces the requested read-only styling.

[ahmdshrif]

Proposal

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

When an admin opens the workspace Owner's member-details panel, the Role field is dimmed to 50% opacity (with the caret still visible), instead of rendering as a normal full-opacity read-only field like the Email row above it.

What is the root cause of that problem?

1. The Role row passes disabled={isSelectedMemberOwner || isSelectedMemberCurrentUser || !canManageSelectedMemberRole} to MenuItemWithTopDescription:
   

   App/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx

   Lines 366 to 372 in d2aa0f4

   	<MenuItemWithTopDescription
   	disabled={isSelectedMemberOwner || isSelectedMemberCurrentUser || !canManageSelectedMemberRole}
   	title={translate(`workspace.common.roleName`, member?.role)}
   	interactive={!isReimburser && canManageSelectedMemberRole}
   	description={translate('common.role')}
   	shouldShowRightIcon={!isReimburser && canManageSelectedMemberRole}
   	pressableTestID="member-role-menu-item"

   
   The disabled prop was added in PR #37869 (changing-owner flow) to stop the owner's role from being changed — the greying is an unintended styling side effect of that guard.

2. MenuItem dims any disabled row: shouldGreyOutWhenDisabled defaults to true, so disabled applies styles.buttonOpacityDisabled:
   

   App/src/components/MenuItem.tsx

   Line 898 in d2aa0f4

   shouldGreyOutWhenDisabled && disabled && styles.buttonOpacityDisabled,

   
   which is literally opacity: 0.5 — the exact reported symptom:
   

   App/src/styles/index.ts

   Lines 898 to 900 in d2aa0f4

   	buttonOpacityDisabled: {
   	opacity: 0.5,
   	},

3. Substituting the repro state (admin viewing the Owner): isSelectedMemberOwner is true → disabled=true. But interactive and shouldShowRightIcon check a different, narrower condition — !isReimburser && canManageSelectedMemberRole — and canMemberAssignRole returns true for any admin (they hold the assignElevatedRoles write permission):
   

   App/src/libs/PolicyUtils.ts

   Lines 213 to 231 in d2aa0f4

   	function canMemberAssignRole(policy: OnyxInputOrEntry<Policy>, login: string, role: string | undefined): boolean {
   	if (!role) {
   	return false;
   	}
   	const isCorporatePolicy = policy?.type === CONST.POLICY.TYPE.CORPORATE;
   	if (isControlPolicyOnlyRole(role) && !isCorporatePolicy) {
   	return false;
   	}
   	if (canMemberWrite(policy, login, CONST.POLICY.POLICY_FEATURE.ASSIGN_ELEVATED_ROLES)) {
   	return true;
   	}
   	// Reaching here: USER always, plus AUDITOR only on corporate policies (control-only roles are
   	// already filtered out on non-corporate policies above). Assigning USER/AUDITOR needs the
   	// MEMBERS permission, and only on corporate policies.
   	const isNonElevatedRole = role === CONST.POLICY.ROLE.USER || role === CONST.POLICY.ROLE.AUDITOR;
   	return isCorporatePolicy && canMemberWrite(policy, login, CONST.POLICY.POLICY_FEATURE.MEMBERS) && isNonElevatedRole;

   
   So the row renders dimmed and still shows the caret — matching both details of the expected result ("full opacity" and "caret should be hidden").

4. Structural cause: the page expresses "this member's role can't be changed" through disabled (styled as a greyed-out blocked action), while the page's own convention for read-only fields is interactive={false} with no disabled — see the Email row directly above (full opacity):
   

   App/src/pages/workspace/members/WorkspaceMemberDetailsPage.tsx

   Lines 359 to 365 in d2aa0f4

   	<MenuItemWithTopDescription
   	title={isSMSLogin ? formatPhoneNumber(phoneNumber ?? '') : memberLogin}
   	copyValue={isSMSLogin ? formatPhoneNumber(phoneNumber ?? '') : memberLogin}
   	description={translate(isSMSLogin ? 'common.phoneNumber' : 'common.email')}
   	interactive={false}
   	copyable
   	/>

   
   and the reimburser branch of this very row (interactive=false + hint text, full opacity, line 369/386). The three props (disabled / interactive / shouldShowRightIcon) have drifted into inconsistent conditions.

All variants hitting this bug (same mechanism):

• Admin views the Owner (reported repro): dimmed + caret shown.
• Any member views their own details (isSelectedMemberCurrentUser): dimmed.
• A viewer without role-assign permission (canMemberAssignRole false, e.g. viewing an admin on a Collect policy): dimmed even though the caret is correctly hidden.
• All platforms are affected identically — the page has no .native split and the opacity comes from a shared RN style.

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

In WorkspaceMemberDetailsPage.tsx, fold every "role is not changeable" condition into one flag, drive both interactive and the caret from it, and remove disabled:

const canChangeMemberRole = !isReimburser && canManageSelectedMemberRole && !isSelectedMemberOwner && !isSelectedMemberCurrentUser;

<MenuItemWithTopDescription
    title={translate(`workspace.common.roleName`, member?.role)}
    interactive={canChangeMemberRole}
    shouldShowRightIcon={canChangeMemberRole}
    ...
/>

This makes the read-only Role row render exactly like the Email row (full opacity, no caret, default cursor), while keeping it fully functional for members whose role can be changed. Pressing is still safely blocked without disabled: MenuItem's onPressAction early-returns when !interactive, so the owner/self rows can never navigate to the role picker:

App/src/components/MenuItem.tsx

Lines 814 to 816 in d2aa0f4

	if (disabled || !interactive) {
	return;
	}

Regression safety: the sibling rows (Email, custom fields at lines 396/406, card rows) and the shared MenuItem component are untouched, and every state that was non-pressable before remains non-pressable.

Why the obvious spot-fix does not work: adding shouldGreyOutWhenDisabled={false} (or tying it to the existing interactive condition) fails the reported repro on two counts. First, if tied to !isReimburser && canManageSelectedMemberRole, that expression is true for an admin viewing the Owner (admins pass canMemberAssignRole via assignElevatedRoles, PolicyUtils L223-224), so the grey-out stays applied and the bug is not fixed. Second, even a hard false leaves shouldShowRightIcon true — the caret stays visible, violating the issue's expected result — and disabled still applies cursorDisabled (MenuItem L929), so the row still doesn't match the Email field. The mismatch lives in three props, not one style flag.

What alternative solutions did you explore? (Optional)

1. shouldGreyOutWhenDisabled spot-fix — incomplete, as proven above (misses the repro case, the caret, and the cursor).
2. Change MenuItem itself to only grey out when interactive && disabled — a global behavior change that would alter every other disabled menu item app-wide; the localized call-site fix is safer.
3. Optional hardening (out of scope, pre-existing): WorkspaceMemberDetailsRolePage has no owner guard against direct deep links; it can't be reached from this row after the fix, but a guard there could be added in a follow-up.