As designed XF 1.5 - Edit Basic User Profiles tied to target user's permissions

[Isil`Zha]

Under General Moderator permissions, this permission exists:

This allows mods to edit profiles of users. However, as of XF 1.5, it is now bound to the profile permissions of the target user. IE: The permissions on one user account affect moderator permissions on another account. I setup a ban system where members are temporarily added to a "Banned Users" group, that restricts their permissions (can view forum, can't post, make reports, edit their profile, etc.) In the past, we have had members put inflammatory/rule breaking content in their profile. A mod would temp ban them and then edit out the info.

As of 1.5, once a user is added to that Banned Users group, mods can no longer edit the profiles either. I verified this through a test account where, just on that account, I specifically started applying "Never" to various profile editing permissions, and my mod reported that it would disappear from their options as well. This makes absolutely no sense why permissions restrictions on one user would affect a different user.

@Xon dug up the problem, in XenForo_ControllerPublic_Member::actionEdit

  $user['permissions'] = XenForo_Permission::unserializePermissions($user['global_permission_cache']);
  $userCanSetCustomTitle = XenForo_Permission::hasPermission($user['permissions'], 'general', 'editCustomTitle');
  $userCanEditProfile = XenForo_Permission::hasPermission($user['permissions'], 'general', 'editProfile');
  $userCanEditSignature = (
   XenForo_Permission::hasPermission($user['permissions'], 'general', 'editSignature')
   && XenForo_Permission::hasPermission($user['permissions'], 'signature', 'maxLines') != 0
  );

Spoilers; user is the user being edited, not the actual visitor doing the edit

EDIT: This has apparently been broken since XF 1.3

 

[Xon]

I think the proper fix is to add a check for against the permission 'editBasicProfile' on the viewer when determine userCanSetCustomTitle, userCanEditProfile, userCanEditSignature are set.

Adding the following code ensures moderators retain the expected functionality for editing a user who wouldn't be able to edit their own custom title, profile or signature due to restrictions:

if ($visitor->hasPermission('general', 'editBasicProfile'))
{
    $userCanEditSignature = $userCanSetCustomTitle = $userCanEditProfile = true; 
}

 

[Mike]

This is as designed. Moderator editing is generally for removing invalid/disallowed values, rather than setting entirely new things. You'll note that these checks are only relevant when there's no value for the field in question; if there's a value, the moderator can still edit it. If the user can set the values themselves, then we give the moderator more latitude but otherwise we don't let them set entirely new stuff if the user can't do it themselves.

 

[Isil`Zha]

Wait, what? That defies logic. I thought it was broken because that is broken behavior. Why would I ever expect one user's permissions to affect another like that? Out of the blue, no less, since this (as far as I'm aware) happens no where else in XF. Who actually expects or wants this bizarre behavior that is totally inconsistent with how any rational permission system works?

In this specific instance, a user was banned for being especially vile. Part of that was slapping all over his public profile "**** this place" (I've censored it here.) But mods suddenly couldn't remove it after he was banned. This is a problem.

 

[Mike]

Part of that was slapping all over his public profile "**** this place" (I've censored it here.) But mods suddenly couldn't remove it after he was banned.

I specifically referred to when they didn't have a value in a field, so it shouldn't prevent the moderator from ever removing a value. The code checks this. For example:

if (!$userCanEditSignature && !$user['signature'])
{
unset($dwInput['signature']);
}

If the user has a signature, the moderator can edit it regardless of their permissions. If this isn't happening then that would be a bug, but I can't reproduce it, so I'd need more specific information about how to reproduce it (what fields were affected, etc).

Of course whether or not this is ideal is a separate discussion, but it shouldn't be triggering in this case anyway.

 

[Isil`Zha]

so it shouldn't prevent the moderator from ever removing a value.

Oh, I'll have to double check. We may have hit a case of multiple staff performing the same task in short time frame, where I had some reporting to me they had no options on banned users, including the example provided, so one mod had cleared it, and the others saw nothing. The other examples I was shown by my staff sound like it may have coincidentally been banned users with empty fields.

I still don't like the idea of User A's permission affecting what User B can do, and to the mods it looks like XF is broken with fields seemingly disappearing at random. I'm still not even sure why XF forces this arbitrary user management policy to us? If you have mods throwing in random things on user's profiles, you have bigger problems. If I don't want mods editing user profiles, I can revoke that permission for the mod or mods myself.