fix: allow admins to edit other users' settings

[GaryJones]

Description

bp_core_can_edit_settings() has a logic error that prevents administrators from editing other users' settings on the front end. The elseif ( bp_is_user() && ! bp_is_my_profile() ) branch catches all "other user" cases, setting $status = false before the bp_moderate / edit_users capability check is ever reached.

This branch is also redundant — $status is already initialised to false, so non-admin users viewing other profiles already get false without needing an explicit branch.

Removing the branch restores the logic to match upstream BuddyPress.

Fixes #4933

Steps to reproduce (before fix)

1. Log in as an administrator
2. Navigate to /members/other-user/profile/edit/
3. Observe redirect to the member's profile with "You do not have access to this page"

Expected behaviour (after fix)

Administrators with bp_moderate or edit_users capability can edit other members' profile fields on the front end, as intended by the capability check that was previously unreachable.

[chetansatasiya]

@claude Review the PR

[claude]

Claude finished @chetansatasiya's task in 1m 29s —— View job

---

PR Review: fix: allow admins to edit other users' settings

• Gather context and understand the request
• Read changed file and surrounding code
• Analyze the logic fix
• Post review feedback

---

Summary

This is a clean, correct fix. The removed branch introduced a subtle logic bug that silently short-circuited the if/elseif chain, making the admin capability checks unreachable.

Logic Analysis

Before (buggy):

$status = false;

if ( bp_is_my_profile() ) {
    $status = true;
} elseif ( bp_is_user() && ! bp_is_my_profile() ) {
    $status = false;           // ← catches ALL "other user" cases here
} elseif ( is_super_admin( bp_displayed_user_id() ) && ! is_super_admin() ) {
    $status = false;           // ← UNREACHABLE when on another user's profile
} elseif ( bp_current_user_can( 'bp_moderate' ) || current_user_can( 'edit_users' ) ) {
    $status = true;            // ← UNREACHABLE when on another user's profile
}

When an admin visits /members/other-user/settings/:

• bp_is_my_profile() → false (different user)
• bp_is_user() && ! bp_is_my_profile() → true — chain stops, returns false
• The bp_moderate / edit_users capability check is never evaluated

After (fixed):

$status = false;

if ( bp_is_my_profile() ) {
    $status = true;
} elseif ( is_super_admin( bp_displayed_user_id() ) && ! is_super_admin() ) {
    $status = false;           // Prevent non-super-admins from editing super admins
} elseif ( bp_current_user_can( 'bp_moderate' ) || current_user_can( 'edit_users' ) ) {
    $status = true;            // ← Now reachable for admins on other users' profiles
}

Correctness of All Cases

Scenario	Before	After
User views own settings	true ✓	true ✓
Regular user views another user's settings	false ✓	false ✓ (default)
Admin (bp_moderate/edit_users) views another user's settings	false ✗	true ✓
Admin views super admin settings	false (wrong branch)	false ✓ (super admin guard)
Super admin views another super admin's settings	false (wrong branch)	true ✓ (capability check)

Redundancy of the Removed Branch

The removed branch was also logically redundant. $status is initialized to false on line 1506. Non-admin users viewing another profile already receive false without any explicit elseif — the removed branch was dead code in that sense too.

Scope of Impact

bp_core_can_edit_settings() is used in 13 call sites across components (bp-settings, bp-xprofile, bp-messages, bp-notifications, bp-friends, bp-groups, bp-invites, templates, REST API, LearnDash integration). All these will now correctly allow admins to edit other users' settings.

Verdict

Approve. The fix is minimal, correct, and matches the description. The PR author correctly identifies both the bug cause (premature elseif catch) and the redundancy. No issues found.

One minor observation — not a blocker: the is_super_admin( bp_displayed_user_id() ) && ! is_super_admin() branch can also now only be reached when bp_is_my_profile() is false (i.e., an admin viewing someone else's page), which is the correct context for that guard. The logic reads more naturally after the removal.